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

實體服務有時被稱為反模式，參見Michael Nygard和Stefan Tilkov的觀點。

原文地址：http://www.infoq.com/cn/news/2018/07/decomposing-system-microservices

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的将系统分解为微服务的策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。