微服務拆分是做微服務架構很重要也很難的話題，很多時候，幾個服務是合還是拆在設計團隊內也很難達成共識。
當你糾結應該拆分和合并時我建議就先合并，等后面版本迭代需要時有必要再去做拆分。從系統發展的角度說，很多平臺也都是從單體大應用、逐步拆分演化而來的，就像有位大牛說的那樣，一開始就拆分的很好的微服務實踐往往是失敗的，成功的微服務平臺都是在演化中迭代而來的。因為微服務拆分看似單個服務明確簡單了，但服務間調用管理就麻煩很多，原來進程內函數調用、單數據庫表查詢連接及事務處理都不能用了，要用各種方法處理數據一致性問題。
微服務的拆分一般是從業務角度入手，然后考慮功能復用及團隊成員情況做適合粒度的劃分。評價拆分好壞的重要指標是拆分前開發維護成本<拆分后的開發維護成本，并且每個服務應該有3-10個人的團隊來負責，人數太多容易指責不清，人數太少如果負責人有事請假不在出問題就找不到人了。
?
)
)
