將系統分解為微服務的策略是什么

今天就跟大家聊聊有關將系統分解為微服務的策略是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

幾年前，Vladik Khononov和他的團隊決定開始使用微服務，但是幾個月后他們發現自己陷入了巨大的混亂之中。他在最近于倫敦Skills Matter舉行的DDD eXchange 2018會議上指出，造成這一現象的原因在于，他們只專注于采用酷炫的新技術，而沒有關注更加基礎的東西，比如模塊化以及如何實現模塊化。他們在serverless框架、平臺和消息機制上投入了精力，但是在 思考如何將系統分解為微服務方面卻思考很少，換句話說，也就是如何尋找邊界并將不同的功能按照邊界進行劃分。

Khononov是Internovus的CTO，對他和他的團隊來說，起始的信條就是服務越小，它就會越好。這直接導致他們構建了一個分布式單體結構（distributed monolith），在接下來的幾年中，他們一直試圖擺脫這些微小的服務并且評估了不同的分解策略。

限界上下文（Bounded context）

Khononov指出通用語言（ubiquitous language）在領域驅動設計（Domain-Driven Design，DDD）中是基礎實踐，該實踐的一種實現方式就是以領域專家的語言與他們進行對話。有時候，你會發現對于相同的業務概念，他們會有不同的心智模型，或者使用相同的術語描述不同的理念，如果這樣的話，就預示著這些理念屬于不同的限界上下文。從一開始，Khononov和他的團隊就使用這些方法來發現定義服務的邊界，每個邊界內都會成為一個服務。他指出，這些服務代表了很廣泛的業務領域，有時候會導致一個限界上下文涵蓋多個業務子域。

業務子域

下一步，他們使用這些業務子域作為邊界，然后為每個業務子域創建一個服務。在Khononov的經驗中，子域和服務之間建立一對一的關系是DDD社區非常常見的方式，但是他們并沒有滿足于此，而是繼續努力實現更小的服務。

業務實體

深入研究子域，他們發現了業務實體和流程，然后他們將其抽取到單獨的服務中。開始的時候，這種終極方式失敗得很慘，但是Khononov指出在隨后的項目中，它取得了更大的成功。

就這三種策略來說，Khononov指出，使用限界上下文能夠幫助他們找到最大的有效單體邊界，然而，盡管它是一個可行的工作模型，但是他認為這種方式并沒有很好地匹配微服務的理念。在業務子域和實體間選擇的時候，他認為最好的分解等級依賴于正在構建的系統及其用例。他強調，微服務的理念實際上并不是關于單個服務內部如何實現的，而是關于服務之間如何交合和耦合的。

系統分解為微服務的閾值是由微服務所屬的用例來定義的。

Khononov還沒有找到一種簡單的方式來評估一個系統的設計，但是他相信現在已經有了足夠多的啟發式設計準則，幫助我們將系統分解為微服務。他認為最有用的幾項包括：

• 始終分解至限界上下文等級。除非你有充分的理由，否則不要進一步分解。分布式系統有它們自己所面臨的挑戰。

• 核心子域是公司掙錢的區域。在進行分解時，確保獲取領域的知識并具有恰當的子域。

• 購買或采用通用子域。它們已經解決了一些問題了，如果自己實現的話，是沒有競爭優勢的。

• 為了支持核心域，我們需要支持子域，但是這不會增加任何的競爭性優勢。它們通常非常穩定和簡單，在早期階段就可以進行進一步的分解，直至使其成為實體服務。

• 采用一致性的需求，幫助我們尋找必須放到同一個服務中的函數或方法。

• 確保事件是顯式和自描述的。考慮在一個服務中，使用私有事件作為實現細節，而將更為嚴格的公共事件作為服務的公開接口。

• 尋找按照相同頻率進行變化的服務，它們可能能夠進行合并以減低復雜性。

• 評估每個服務的接口。如果覺得服務范圍太廣的話，那么它可能能夠拆分為更小的服務，主要站在集成方面，重新考慮評估邊界以簡化整個系統的設計。

Khononov在總結中指出，隨著系統中服務的平均規模變得越來越小，你將會從一個大泥球般的單體系統，通過限界上下文實現相對較大的服務，進而轉化為微服務。但是，他強調，如果你繼續讓服務變得更小的話，那么最終將會形成一個分布式的大泥球。

看完上述內容，你們對將系統分解為微服務的策略是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。