微服務的粒度
我們如何在服務化系統或者微服務架構中，做合理的拆分服務，服務拆分到什么粒度才算合適？
依照微服務的初衷，服務要按照業務的功能進行拆分，直到每個服務的功能和職責單一，甚至不可再拆分為止，以至於每個服務都能獨立部署，擴容和縮容方便，能夠有效地提高利用率。拆得越細，服務的耦合度越小，內聚性越好，越適合敏捷發布和上線。
然而，拆得太細會導致系統的服務數量較多，相互依賴的關系較復雜，更重要的是根據康威定律，團隊要響應系統的架構，每個微服務都要有相應的獨立、自治的團隊來維護，這也是一個不切實際的想法。
因此，這里倡導對微服務的拆分適可而止，原則是拆分到可以讓使用方自由地編排底層的子服務來獲得相應的組合服務即可，同時要考慮團隊的建設及人員的數量和分配等。
有的公司會把每個接口包裝成一個工程，或者把每一次JDBC調用包裝成一個工程，然后號稱是“微服務”，最后有成百上千的微服務項目，這是不合理的。當然，有的公司把一套接口完成的一個粗粒度的流程耦合在一個項目中，導致上層服務想要使用這套接口中某個單獨的服務時，由於這個服務與其他邏輯耦合在一起，所以需要在流程中做定制化才能實現使用方使用部分服務的需求，這也是不合理的，原因是服務粒度太粗。
總之，拆分的粒度太細和太粗都是不合理的，根據業務需要，能夠滿足上層服務對底層服務自由編排並獲得更多的業務功能即可，並需要適合團隊的建設和布局。