在服務化系統或者微服務架構中，我們如何拆分服務才是最合理的？服務拆分到什麼樣的粒度最合適？
按照微服務的初衷，服務要按照業務的功能進行拆分，直到每個服務的功能和職責單一，甚至不可再拆分為止，以至於每個服務都能獨立部署，擴容和縮容方便，能夠有效地提高利用率。拆得越細，服務的耦合度越小，內聚性越好，越適合敏捷發布和上線。
然而，拆得太細會導致系統的服務數量較多，相互依賴的關係較複雜，更重要的是根據康威定律，團隊要響應系統的架構，每個微服務都要有相應的獨立、自治的團隊來維護，這也是乙個不切實際的想法。
因此，這裡倡導對微服務的拆分適可而止，原則是拆分到可以讓使用方自由地編排底層的子服務來獲得相應的組合服務即可，同時要考慮團隊的建設及人員的數量和分配等。
有的公司把每個介面包裝成乙個工程，或者把每一次jdbc呼叫包裝成乙個工程，然後號稱是「微服務」，最後有成百上千的微服務專案，這是不合理的。當然，有的公司把一套介面完成的乙個粗粒度的流程耦合在乙個專案中，導致上層服務想要使用這套介面中某個單獨的服務時，由於這個服務與其他邏輯耦合在一起，所以需要在流程中做定製化才能實現使用方使用部分服務的需求，這也是不合理的，原因是服務粒度太粗。
總之，拆分的粒度太細和太粗都是不合理的，根據業務需要，能夠滿足上層服務對底層服務自由編排並獲得更多的業務功能即可，並需要適合團隊的建設和布局。
**部落格：
軟體體系架構閱讀筆記十三
3.限流模式 服務的容量和效能是有限的，在第3章中會介紹如何在架構設計過程中評估服務的最大效能和容量，然而，即使我們在設計階段考慮到了效能壓力的問題，並從設計和部署上解決了這些問題，但是業務量是隨著時間的推移而增長的，突然上量對於乙個飛速發展的平台來說是很常見的事情。針對服務突然上量，我們必須有限流...
軟體體系架構閱讀筆記九
微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。如果你閱讀了fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有元件組合到一...
軟體架構閱讀筆記01
進行軟體架構的學習，先粗略的讀一遍 大型 架構 了解軟體架構。大致明白了幾點，首先利用軟體架構 解決問題，解決業務問題，進行優化，然而架構不能夠解決所有問題。其次，軟體架構只有親身經歷從低到高才能夠了解架構，我只能夠粗略理解，沒有實際進行，不能深入解讀。軟體架構主要講的內容之一就是 分類。也就是軟體...