軟件體系架構閱讀筆記十四

在服務化系統或者微服務架構中，咱們如何拆分服務纔是最合理的？服務拆分到什麼樣的粒度最合適？

按照微服務的初衷，服務要按照業務的功能進行拆分，直到每一個服務的功能和職責單一，甚至不可再拆分爲止，以致於每一個服務都能獨立部署，擴容和縮容方便，可以有效地提升利用率。拆得越細，服務的耦合度越小，內聚性越好，越適合敏捷發佈和上線。

然而，拆得太細會致使系統的服務數量較多，相互依賴的關係較複雜，更重要的是根據康威定律，團隊要響應系統的架構，每一個微服務都要有相應的獨立、自治的團隊來維護，這也是一個不切實際的想法。

所以，這裏倡導對微服務的拆分適可而止，原則是拆分到可讓使用方自由地編排底層的子服務來得到相應的組合服務便可，同時要考慮團隊的建設及人員的數量和分配等。

有的公司把每一個接口包裝成一個工程，或者把每一次JDBC調用包裝成一個工程，而後號稱是「微服務」，最後有成百上千的微服務項目，這是不合理的。固然，有的公司把一套接口完成的一個粗粒度的流程耦合在一個項目中，致使上層服務想要使用這套接口中某個單獨的服務時，因爲這個服務與其餘邏輯耦合在一塊兒，因此須要在流程中作定製化才能實現使用方使用部分服務的需求，這也是不合理的，緣由是服務粒度太粗。

總之，拆分的粒度太細和太粗都是不合理的，根據業務須要，可以知足上層服務對底層服務自由編排並得到更多的業務功能便可，並須要適合團隊的建設和佈局。

 轉載博客：https://blog.csdn.net/kwame211/article/details/78015601