微服務之劃分原則

演進原則

任何產品的演進都無法一蹴而就，在架構演進過程中需遵循以下幾方面的原則。

  1. 漸進性原則，滿足當前及未來一定範圍的技術要求，可做到平臺的平滑過渡升級。

  2. 獨立性原則，逐漸拆分的微服務要具有一定的獨立性，以能力方式對上層應用服務提供特定的業務能力支持，要與其他服務保持相對無關性。比如獨立的文件服務、licence 授權服務、工作流服務等等。

  3. 無狀態原則，微服務要保證基本無狀態，便於微服務自身的集羣構建及獨立迭代優化。

劃分原則

把一個大系統劃分爲多個微服務，使模塊間結構更加清晰，模塊間更低耦合高內聚，有更好的擴展性和穩定性。微服務劃分務必遵守以下原則：

  1. 按功能模塊劃分微服務，儘量做到一個功能模塊一個微服務。

  2. 微服務之間減少互相調用，做到低耦合高內聚。

項目劃分

  1. mes-base 共有基礎模塊，抽出共用實體，共用工具類等

  2. mes-discovery-nacos 服務註冊中心

  3. mes-api-gateway 網關

  4. mes-config 配置中心

  5. mes-user 用戶模塊

  6. mes-equipment 設備管理模塊

等等，具體根據業務做具體劃分。

“萬能模板” 是什麼

在雲原生技術實踐聯盟（CNBPA）2021 年初的調研中顯示，國內 72.7% 的企業已經採用 Kubernetes 作爲容器編排技術，佔據了絕對的優勢地位。這也與 CNCF 最新發布的中國區雲原生調查報告中，72% 的受訪者已經在生產環境當中使用 Kubernetes 的數據保持相當高的一致性，同期全球調查報告的數字是 78%。

在雲計算建設和技術引入時，建議考慮基於以 Kubernetes 爲核心的雲原生平臺來做，Kubernetes 作爲雲的操作系統，可以屏蔽下面各種各樣不同的雲環境、雲基礎設施，它自身是一個可移植層，這樣在做混合雲和多雲管理時，對應用遷移以及其他工作負載非常有好處，可以做到跨環境的兼容。由於 Kubernetes 的可擴展性，本身平臺之平臺的屬性，導致它天生適合用來作爲整個混合雲的控制面板，用它去編排不同類型的雲環境以及雲基礎設施和各類雲服務。

在建設路線上應該以應用爲中心，覆蓋應用全生命週期爲目標進行雲計算的建設方向。充分考慮平臺融合基礎設施、微服務框架、數據服務、DevOps 工具等模塊作爲平臺組件，以建設具備全棧能力的雲平臺爲發展方向。

應用轉型的相關規範

建議可以參考以下 15 個要素，這些要素幾乎涵蓋了雲原生架構下應用轉型的各個方面。

要素 1：基準代碼（Codebase）——一份基準代碼，多份部署。

要素 2：依賴（Dependencies）——顯式地聲明依賴關係。

要素 3：配置（Config）——在環境中存儲配置。

要素 4：後端服務（Backing Services）——把後端服務當作附加資源。

要素 5：構建、發佈、運行（Build、Release、Run）——嚴格分離構建、發佈、運行。

要素 6：進程（Processes）——以一個或多個無狀態進程運行應用。

要素 7：端口綁定（Port Binding）——通過端口綁定提供服務。

要素 8：併發（Concurrency）——通過進程模型進行擴展。

要素 9：易處理（Disposability）——快速啓動和優雅終止可最大化健壯性。

要素 10：開發環境與線上環境等價（Dev and Prod Parity）——儘可能保持開發、預發佈、線上環境相同。

要素 11：日誌（Logs）——將日誌當作事件流。

要素 12：管理進程（Admin Processes）——將後臺管理任務作爲一次性進程運行。

要素 13：優先考慮 API 設計（API First）。

要素 14：通過遙測感知系統狀態（Telemetry）。

要素 15：認證和授權（Authentication and Authorization）

領域劃分的規則或者原則

單一抽象層次原則

這個原則其實要求做領域劃分的時候不可以抽象出多個相似的領域，比如營銷和優惠，這兩個可能就是相似的領域，或者說優惠是在營銷領域下的一個層次的抽象，那這樣的話我們可以用這個原則來檢查一下劃分的領域有沒有可能存在相似和重複。當然另外一方面也可以保障我們可以識別大多數的重要領域。

奧卡姆剃刀原理

這裏說的意思是在劃分上下文的時候不要做的太細，太細的話就存在多個層次的內容反而無法更好的切分上下文，那麼在領域層也類似，說白了，通過這個原理可以讓主觀的劃分更有能動性，也更能給出劃分的理由。即使是拍腦袋劃分的，能從中取出核心的領域名稱並給出具有說服力的理由也算一種劃分方案。

最小驚訝原則

這個原則說的是在真正懂行的專家裏或者有經驗的大佬面前如果你的劃分挺合理的話那麼他們不會感到驚訝，可能會會心一笑。反之就會覺得有需要改進的地方，或者再討論討論。所以在領域和上下文的劃分上來看，如果劃分的比較合理那麼就沒有太多爭論的必要了。

正交原則

這個正交原則其實可能有點不太理解或者不容易應用，在領域劃分方案出來之後可以通過一些業務流程來看一下領域內的聚合實體服務等是否跟別的領域內做的事情相似或者一樣，如果存在的話說明還可以繼續優化。直到每個領域做的事情都足夠唯一或者職責單一，到合適的正交維度即可。如果過度的追求正交和職責單一可能會出現單一抽象層次不清晰的情況。

多數派原則

簡單解釋一下，就是可以從統一語言或者領域名稱中找一些線索，比如我們有很多業務流程，有很多用例或者用戶故事，那麼這些文檔和業務中哪些出現的名詞或者動名詞最多這個就可以作爲一個領域。目前看這是一種最簡單的領域劃分原則了，也就是說你可以從腦海中過一遍所有業務流程，接口流程，調用時序，從統一語言上去統計哪些詞語是最常出現的，這些詞語代表了哪個維度的領域，是核心領域還是通用領域，還是依賴領域等等。那麼可以把這些詞語單獨摘出來去劃分，當然也可能有最多的排序，比如出現詞語最多的有 20 個，但是裏面可能有重複的，不夠正交也不夠單一抽象，那麼可以用排除法一一去舍掉看是否是最好的領域劃分方案，類似於手動尋找最優解。

微服務微信交流羣添加微信，備註微服務進羣交流

關注公衆號 soft 張三丰

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/UVS_tSNjVYuhfFqfdAXWVg

猜你喜歡