微服務拆分

微服務拆分是做微服務架構很重要也很難的話題，很多時候，幾個服務是合還是拆在設計團隊內也很難達成共識。

當你糾結應該拆分和合併時我建議就先合併，等後面版本迭代需要時有必要再去做拆分。從系統發展的角度說，很多平台也都是從單體大應用、逐步拆分演化而來的，就像有位大牛說的那樣，一開始就拆分的很好的微服務實踐往往是失敗的，成功的微服務平台都是在演化中迭代而來的。因為微服務拆分看似單個服務明確簡單了，但服務間呼叫管理就麻煩很多，原來程序內函式呼叫、單資料庫表查詢連線及事務處理都不能用了，要用各種方法處理資料一致性問題。

微服務的拆分一般是從業務角度入手，然後考慮功能復用及團隊成員情況做適合粒度的劃分。評價拆分好壞的重要指標是拆分前開發維護成本《拆分後的開發維護成本，並且每個服務應該有3-10個人的團隊來負責，人數太多容易指責不清，人數太少如果負責人有事請假不在出問題就找不到人了。