大話微服務：（二）對于業務如何劃分微服務，即微服務的顆粒度，又稱業務邊界

寫在前面的一句話：使用微服務架構的大型軟體公司，都是從使用一體化應用程式開始的。一旦它們達到了可擴充性和可維護性的極限，它們就會将一體化機器分解為獨立的部件或服務。

微服務的劃分是一個難點，如何處理好：(1)微服務不能太大，也不能太小 (2) 緊密耦合程度如何把握？

微服務顆粒度劃分與設計原則：

一、業務原則：

1. 這個微服務不會與其他的服務共享資料庫表，注意是表，不是庫,即避免多個微服務引用同一個表的服務，如果有他們均屬于同一個微服務。

2.這個微服務具有最少量的資料庫表：這個表盡量少，這個可能要看業務需求，不是絕對。

3.這個微服務可能是有狀态（即和資料庫有關），或者無狀态（即非資料庫）的。

4.單一責任原則，又稱這是一個真理的單一來源，即這個服務是系統中某一件事的唯一真理來源，即這個微服務在整個系統中代表功能的唯一性，它具有時空不變性的特質，同時滿足有限業務範圍内進行設計，進而實作傳遞的靈活。

5.微服務顆粒度與2個披薩的關系：你有幾個2 pizza團隊，最好就拆成幾個微服務，隻有一個開發人員時盡量做單體應用，不要沒事找事找刺激拆成10個微服務，最終這個開發人員還會把他合成一個。

   微服務的本質就是團隊的分工，微服務要求縱向的2 pizza團隊（7，8個人以内）（無數個小團隊，包含開發、測試、運維）。

  堅持以康威定律作為指導思想。

6.微服務從業務層面分為核心業務和非核心業務，要緊持業務與技術分離後，把參與者與一個或者多個業務原子行為組合在一起就形成了微服務。

7.适當的邊界：關注微服務的功能範圍，一個服務的大小應該等于滿足某個特定業務能力所需要的大小；

8.非唯一性依賴：至少被2個以上其它微服務依賴的功能子產品，才有必要獨立成一個微服務

總結：拆分的粒度太細和太粗都是不合理的，根據業務需要，能夠滿足上層服務對底層服務自由編排并獲得更多的業務功能即可，并需要适合團隊的建設和布局。是以，這裡倡導對微服務的拆分适可而止，原則是拆分到可以讓使用方自由地編排底層的子服務來獲得相應的組合服務即可，同時要考慮團隊的建設及人員的數量和配置設定等。

二、技術原則：

  1.部署獨立性

  2.動态擴充、

  3.避免産生頻敏的跨庫查詢

  4.避免産生頻繁的分布式事務。

三、治理原則：

 1.在業務分層的基礎上，根據業務細分規則，對微服務分組；

 2.各個分組之間通過API網關內建；

 3.通過API網關實作級輕量級消息路由，鑒權；

 4.運作時管理，如服務降級，限流，監控等可在API網關實作，讓微服務功能純粹；

  5.避免通過資料庫內建；

  6.避免部署多個版本來相容。

四、微服務設計發展的一個思想趨勢：

前台UI遵循以使用者為中心的設計思想。以使用者為中心的設計就是完全站在使用者的角度來思考前台UI的設計，使用清晰合理的界面邏輯來幫助使用者達成目标。前台UI應該盡可能的輕，這樣才能夠快速地去适配不同使用者的不同需求。

背景微服務遵循以業務為中心的設計思想。以業務為中心的設計就是完全站在業務處理的角度來思考微服務的設計，需要考慮業務處理的各種場景，使用合理的設計達到微服務之間的隔離性高，擴充性好等目标。因為業務領域的東西不會經常變化，并且随着市場的發展對于服務的需求量可能會呈現指數級的增加，是以背景服務應該盡可能地保持穩定和維持很好的擴充性，這樣整個微服務叢集才能夠向外穩定地提供服務。