在微服務的架構下, 產品或許會有上百個或上千個微服務。所以, 當這些上百個或上千個微服務, 同時都依賴於某個庫 (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 變更後的測試與發佈的複雜度與工作量。