2016.8.8, 深圳, Ken Fang

微服務設計是架構設計。

所以, 微服務設計不應是一個講求標準答案, 簡單粗暴的設計過程。而應該是一個考量各方因素下的一個決策的過程。

所以, 在探討微服務架構前, 我們先來探討下, 所謂的微服務具體應包含哪些核心的概念?

I.        分散式 (Distributed):

微服務與微服務間分散式呼叫最主要的概念便是: protocol-aware heterogeneous interoperability; 各微服務可各自擁有自身的 platform (Java,C＃, Scala…等等), 但, 各微服務間卻只能藉由單一共同的協議 (protocol); 如: REST; 進行分散式的呼叫。

II.      分別部署 (Separately Deploy):

微服務架構的產品或許會有數百甚至數千個微服務所構成。所以, 部署微服務時, 便很難經由手工來完成, 而必須相當程度的依賴自動化的 DevOps 工具。

III.    服務元件 (Service Component):

微服務是以服務元件, 而不是以類或模組的方式體現; 每個服務元件會包含一個或多個類或元件。

微服務共分為兩大類:

A.      Infrastructure Services:

    如: login service 便是一Infrastructure Services 的例子; 主要是為產品中其他的微服務提供產品登入的服務。

所以, Infrastructure Services 對產品外部的使用者介面、系統、裝置都是不可見的, 也就是說, 產品外部的使用者介面、系統、裝置是無法經由 api layer 來找到 Infrastructure Services 的。

B.      Functional Services: 主要是為產品外部的使用者介面、系統、裝置提供某一端到端業務場景的服務。

所以, 相對於 Infrastructure Services, Functional Services 對產品外部的使用者介面、系統、裝置而言, 都是可見的。也就是說, 產品外部的使用者介面、系統、裝置是經由 api layer 來找到 Functional Services 的。

IV.    邊界上下文 (Bounded Context):

微服務的邊界上下文包含:

A.   某一端到端業務場景 (功能) 。

B.   資料 (資料庫) 。

微服務的邊界上下文, 使得每一個微服務擁有各自的某一端到端業務場景 (功能)與資料 (資料庫) 。

更重要的是: 當微服務X需呼叫微服務Y, 則微服務X 與微服務Y的邊界上下文, 將可避免或降低發生, 當微服務Y 運作失敗時, 會影響到微服務 X。

所以, 微服務的邊界上下文提供了一個很重要的微服務概念：微服務應能獨立各自的開發、測試, 並且當釋出、部署後, 亦不致影響到其他微服務的功能或運作。

V.      不共享任何事物 (Share Nothing):

因為, 微服務間共享任何的事物, 將會造成微服務間的依賴。

所以, 微服務間應避免共享任何的事物; 如:繼承結構下的抽象介面, 服務, 模組, utility, 類, 資料 (資料庫)…等等。

VI.    api layer:

api layer 主要是在微服務與微服務外部的使用者介面、系統或裝置之間構建:

A.      endpoint proxy: 隱藏各微服務的 endpoint。

當某個新增的場景在某個新的微服務上開發完後, 這個新的微服務便會有了新的 endpoint。 而api layer 便可將此微服務外部的使用者介面、系統或裝置導向此新的微服務上的 endpoint。使得微服務外部的使用者介面、系統或裝置可在不需要有任何修改的情況下, 便可以使用此新的微服務。而當微服務外部的使用者介面、系統或裝置發現此新的微服務不適用時, api layer 便可將微服務外部的使用者介面、系統或裝置導向舊的微服務上的 endpoint, 而使得新的微服務, 對微服務外部的使用者介面、系統或裝置而言, 變得不可見。

B.      load balancer: 多節點間的負載均衡。

VII.  開發新的微服務優於在既有的微服務上不斷的加新的場景或功能:

當某個微服務開發完後, 便應避免不要再在此微服務上, 不斷的加新的場景或功能; 新的場景或功能應該是屬於另一個新的微服務。