微服務架構 (六): 微服務間的共享的管理

在微服務的架構下, 產品或許會有上百個或上千個微服務。因此, 當這些上百個或上千個微服務, 同時都依賴於某個庫 (Library) 時, 則當此共享的庫, 即便只是針對某個微服務作些不多量的修改, 也可能會對其餘上百個或上千個微服務, 形成不可預期的影響。

但在實際的項目中, 產品中的微服務又沒法避免的會對某些庫 (Library) 產生依賴; 共享某些庫 (Library)。

因此, 架構師必須要知道要如何管理微服務間的共享?

微服務會造成共享的緣由, 主要是來自於:

1.       微服務共同繼承於某個抽象的接口。

2.       微服務同時依賴於某個共享的庫 (Library)。

架構師可採用如下的四種方案, 管理微服務間的共享:

A.      Compile Binding: 將多個微服務會共享的代碼, 置入在一共享的項目中。在編譯的時候, 共享的代碼便與特定的微服務的代碼編譯在一塊兒。此種方案, 從開發的角度, 其好處是顯而易見的: 不需重啓運維中的微服務, 而是在編譯, 單元測試的時候, 特定的微服務即可當即知道, 在共享項目中的任何的修改或變動, 對微服務自身的影響爲什麼? 然而, Compile Binding 卻存在著個嚴重的問題: 當共享的項目與數十個、上百個微服務是 Compile Binding 時, 則有的微服務可編譯, 可測試經過, 可發佈、有的微服務卻發生了沒法編譯, 或測試不經過、有的微服務則發生了沒法發佈....; 真的是一場災難。更糟糕的是, 當災難發生時, 各個微服務也無法對所共享的項目, 有任何的選擇權或控制權; 各個微服務沒法選擇自身所要的共享項目的版本。

B.      JAR File/ Shared Library: 各微服務間共享著編譯, 構建後的包 (Shared Library) ; 如: JAR包。

此方案最大的好處即是: 各個微服務間對其所共享的 Shared Library 擁有所謂的選擇權; 也就是說, 某個微服務可選擇 1.0 版的 JAR, 另外一個微服務則能夠選擇 1.5 版的 JAR。固然, 缺點是: 當有數十個、上百個, 甚至是上千個微服務共享某個發生變動的 Shared Library 時, 則這些爲數衆多的微服務便得一一的從新啓動後, 才能執行測試, 才能得知 Shared Library 的改變, 對各個微服務的影響。Share Library 應儘可能的能細分到某一特殊功能的粒度; 如: 某一龐大的 Backend.jar 應細分爲 Persistence.jar, SQL.jar, Security.jar。某一大而全的 Utility.jar 亦應細分爲Calculator.jar, MaxTime.jar。這樣的細分粒度, 將有利於能更精確的分析出, Shared Library 在每一個版本中到底變動些了什麼? 各微服務針對這些變動, 所應採起的相對應的措施爲什麼?

C.      Replication:將各微服務都會用到模塊 (代碼) , Copy-Paste 到各個微服務中。

此方案雖然違背了DRY (Do not RepeatYourself.), 但卻使得每一個微服務維持了自身的邊界上下文 (Bounded Context), 而使得產品中的數百個或甚至數千個微服務間的依賴下降; 產品中的數百個或甚至數千個微服務間的依賴越少, 各微服務便得以更高效的方式進行開發、測試、發佈。

固然, 架構師必須要確保: Copy-Paste 到各個微服務中的模塊 (代碼) 的質量是穩定的與變動的頻率是不高的。由於, 任何一個質量上的缺陷或任意的變動, 將會形成數百個或甚至數千個微服務維護的工做量。  

D.      Service Consolidation: 當某個SharedLibrary; 如: 某個.jar; 被多個微服務所共用時, 則當此 Shared Library 有變動時, 多個共用此 Shared Library 的微服務, 將必需再次的被測試, 再次的被髮布。架構師此時應從新的思考: 這些共用 Shared Library 的微服務, 那些或所有可與 Shared Library 合併爲一單一的微服務; 合併後, 將可減化 Shared Library 變動後的測試與發佈的複雜度與工做量。