2016.8.19, 深圳, Ken Fang

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

微服務 “外部的世界” 遠比 “內部的世界” 重要。

微服務外部與內部的世界是以微服務邊界上下文 (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)。而使微服持續部署的速度, 獲得絕對的提升; 但, 絕對不是現在….