微服務架構 (七): 微服務粒度設計上的核心設計原則與思考的面向

架構師在設計微服務時, 需把握一個核心的設計原則:

微服務 「外部的世界」 遠比 「內部的世界」 重要。

微服務外部與內部的世界是以微服務邊界上下文 (Bounded Context) 做劃分的。而微服務的接口; 例如: REST 接口; 即是拉通了微服務外部與內部的世界。

微服務外部的世界包括:

A.       微服務外部的 Client; 微服務外部的使用者 (介面), 系統, 設備。

B.       微服務之間外部的數據交易 (Transaction)。

C.       微服務之間外部的遠程調用; 在網絡上所傳遞的信息。

微服務內部的世界包括:

A.       微服務內部需處理、運算的業務場景或功能。

B.       微服務內部所需擁有的資源; 例如: 庫 (Library), 數據庫, 應用伺服器, 網絡IP 地址, 網絡 Port, 操做系統等等。

架構師設計微服務的粒度; 邊界上下文 (Bounded Context); 時, 便需僅記微服務 「外部的世界」 遠比 「內部的世界」 要來得重要。也就是說, 架構師應從微服務 「外部的世界」 來界定微服務的粒度; 微服務的邊界上下文 (Bounded Context)。

架構師設計微服務的粒度; 邊界上下文 (Bounded Context); 時的主要思考的面向即是:

A.       先從微服務外部的 Client, 分析、識別微服務的主要目的、主要需處理、運算的業務場景或功能爲什麼? 而造成微服務的 Pre-Bounded Context。

B.       各微服務的 Pre-Bounded Context 識別後, 即可得知微服務之間外部的數據交易 (Transaction) 是否會由於開發上技術難度的增大, 而對於總體產品架構的可靠性; 例如: 數據的一致性; 產生負面的影響?

假如, 所設計出的微服務的 Pre-Bounded Context 會由於開發上技術難度的增大, 而對於總體產品架構的可靠性; 例如: 數據的一致性; 產生負面的影響, 則架構師便應從新的思考: 將會因微服務之間外部的數據交易 (Transaction) , 而會對總體產品架構的可靠性, 產生負面影響的數個微服務, 「合併」 爲一個微服務。

C.       各微服務的 Pre-Bounded Context 識別後, 即可得知是否會由於過多的微服務之間外部的遠程調用, 所造成的大量網絡的延遲, 而使總體產品架構的性能, 產生負面的影響？

假如, 所設計出的微服務的 Pre-Bounded Context 會造成大量網絡的延遲, 而使總體產品架構的性能, 產生負面的影響, 則架構師便應從新的思考: 將會因微服務之間外部的遠程調用, 而會對總體產品架構的性能, 產生負面影響的數個微服務, 「合併」 爲一個微服務。

以微服務 「外部的世界」 遠比 「內部的世界」 重要的思惟的模式, 主要是將總體微服務 (產品) 的可靠性、性能的重要性要高於總體微服務 (產品) 持續部署的速度。

這樣的思惟最主要的目的即是: 微服務外部的世界, 仍舊是十分的脆弱與不可預期的; 例如:網絡的中斷、網絡的安全性 (犯罪)、網絡的延遲等等; 因此, 架構師應從微服務 「外部的世界」 界定微服務的粒度; 微服務的邊界上下文 (Bounded Context)。

固然, 假若有一天, 微服務外部的世界已經是十分的強壯, 則架構師即可從微服務 「內部的世界」 來界定微服務的粒度; 微服務的邊界上下文 (Bounded Context)。而使微服持續部署的速度, 得到絕對的提高; 但, 絕對不是如今….