無限合並

最近工作上接到一個需求模塊：關於賬號自動合並的問題。簡化來講，手機1和郵箱1是一個賬號，手機1和郵箱2請求過來創建賬號時，由於手機號相同，自動合並為一個賬號。手機3和郵箱2再過來請求創建賬號，由於郵箱相同，自動合並為一個賬號。手機3和郵箱4過來請求創建賬號時，又因為手機號相同，再次合並為一個賬號……假如是個訪問量很大並且又這麽巧的時候，就類似於無限合並了。實際上可能僅會出現幾筆，不會這樣無限循環下去。但我是一個容易多想的人。賬號合並，又關聯著和賬號相關的數據的遷移，從我個人的角度來說，這樣沒有邊界防禦的需求，我內心是拒絕的，但還沒想好更好的辦法，暫且如此了。

這個話題聯想到微服務，微服務能解決這種問題麽？很遺憾，微服務並不是想象中的那麽強大。賬號合並本質上可以做成一個微服務，但微服務並不能解決這種業務問題。

我認識的微服務是為了方便水平擴展，方便使用體驗異構技術，方便快速試錯，方便部署，能最終實現高可用高並發。你了解再多的微服務知識，也不是用於解決此類業務問題。

對於此類業務問題，一般方式是判斷需求是否合理？不合理的需求可以適當拒絕掉。

再著看是誰提的？如果是普通客戶，盡量用其他更簡便容易維護的方式代替。如果是金主或上層領導派發需求，那就只能在總結風險的基礎上，一步一步往前看吧。

第三看需求是否通用，通用化的解決方案一般是更易理解，更適合推廣。定制化得需求是耗時耗力的。

第四判斷影響範圍，如果是個高風險，又耗時又要牽扯很多舊業務，你敢動麽？謹慎謹慎再謹慎。

需求判斷階段完畢，下面說說規避風險

第一，清晰的標註需求影響邊界

第二，不要盲目動刀，一定要分析需求。對需求茫然的情況下，盲目碼磚，你會很累的。更有甚者，需求本身只是顯示了冰山一角，還有廣大的未知冰山底層埋藏。如果不能提前發現，你的時間會越來越短，要做的事反而越來越多。這是一種失控。有時候失控是可預知但必須迎難而上的。有時候又可以輕易靠幾句話輕易甩鍋的。這本來也是一種修煉。

第三，人員分配。對合作的項目成員要有必要的了解，擅長的人做擅長的事。

第四，會議紀要。有時候頻繁地會議是少不了的，有營養的思路應該記錄下來方便實踐。有疑問應及時去討論，不要想當然。想當然是最浪費時間的事情。

這些事情和微服務無關。但這些功能最終可以稱為一個微服務。這可以理解為微服務開發過程如何識別需求，開發需求的思路。

微服務來源於生活高於生活。

首發簡書:https://www.jianshu.com/p/ab4f11fb4e77

我來悟微服務(3)-需求管理