原文地址：From Monolith to Microservices in 5 Minutes

原文做者：Daniel Rusnok

譯文出自：掘金翻譯計劃

本文永久連接：github.com/xitu/gold-m…

譯者：YueYong

校對者：zenblo，NieZhuZhu

5 分鐘內從單體架構遷移到微服務架構

「微服務架構是一種將單體應用程序開發爲一套小型服務的方法。」——馬丁 · 福勒。html

首先，咱們須要明白什麼是單體架構。而後我將向你展現如何修改它的域，以便爲微服務架構作好準備。最後，我將會簡要地告訴你微服務架構的基礎知識，並討論其優缺點。前端

單體架構

每一種非垂直拆分的架構都是單體架構。軟件設計中的垂直拆分意味着將應用程序劃分爲更多可部署的單元。這並不意味着單體架構不能水平劃分。android

單體這個詞指的是軟件的體系結構是由一個後端單元組成。我之因此說後端，是由於我認爲單體架構能夠在具備多個 UI（如 Web 和移動設備）的同時，仍然能夠被看做爲一個總體。ios

組件之間的通訊主要經過方法的調用。若是你的前端和後端是在物理上隔離的，可是它們仍然是一個總體，例如 API 和 Web 客戶端。git

除非你將後端劃分爲更多部署單元，不然在我看來你依舊是在使用單體架構。github

「域是計算機程序的目標主題領域。形式上，它表明特定編程項目的目標主題。」—— 維基百科web

用個人話說，域就是軟件存在的緣由和目的。我在 3 Domain-Centric Architectures Every Software Developer should Know 這篇文章中寫了有關域的幾個觀點。編程

下圖是一個將在線商城域可視化的結果。後端

Sales 和 Catalog 子域包含單個的 Product 實體。這種作法是不可取的，由於這將致使一個地方出現更多的問題。這違反了關注點分離原則。markdown

強迫一個實體承擔更多的責任，顯然是不合理的。實體在這兩種上下文中都包含未使用的屬性。Sales 不須要知道產品的類別，而且對於 Catalog 來講，知道 Product 是如何將信息傳遞給客戶並無任何用處。

爲了不這個問題，咱們須要找到 Sales 和 Catalog 上下文的邊界來將它們分開。這就引出接下來要說的限界上下文。

限界上下文是上下文的邊界，參考 Idapwiki.com

要指定限界上下文，咱們須要識別出一個模型仍然有效的上下文範圍。

咱們能夠經過對域中的每一個實體問一個簡單的問題來驗證模型，即：這個實體對於哪一個上下文有效？

當一個實體對多個上下文有效時，那麼它應該被劃分到多個上下文中。每一個實體都具備與上下文相對應的屬性。這一步結束後，你的應用就準備好遷移到微服務架構了。

下圖是從在線商城域中對 Product 分離的實體類的可視化結果。

微服務架構是由於微服務從而聞名。它是不斷細分的單體。微服務將大型系統劃分爲較小的部分。

限界上下文幫助咱們找到一個微服務的最佳大小。微服務的模型應當儘量小，以最大程度減小與外部世界的通訊；但也不能過於小而失去存在的必要性。

微服務架構使項目具備獨立性。該架構支持分離的開發團隊、不一樣的操做系統、不一樣的編程語言以及不一樣的業務層架構，例如 [CQRS](levelup.gitconnected.com/3-cqrs-arch… -know-a7f69aae8b6c)。

每個微服務對外都有一個明肯定義的接口，主要經過 HTTP 傳輸，並以 JSON 的形式實現，例如 REST API。對於微服務之間的通訊，推薦的解決方案是經過 RabitMQ 或 Azure 服務總線之類的消息平臺。

若是沒有適當的消息傳遞工具，那麼微服務必須知道其餘微服務的位置，而且這個位置是會被隨意更改的。

在大型應用程序中，微服務體系結構的開發成本曲線較好。小型應用程序沒法從微服務中受益，所以應保持單體架構。

微服務會有分佈式系統的成本，好比負載平衡和網絡延遲。這些問題經過任務編排器能夠很好的解決，常見的有 Kubernetes 和 Azure Service Fabric。

有了對以上這些內容的理解，接下來我推薦你去閱讀 Pluralsight course from Mark Heath — Microservices Fundamentals。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到掘金翻譯計劃對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

掘金翻譯計劃是一個翻譯優質互聯網技術文章的社區，文章來源爲掘金上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注掘金翻譯計劃、官方微博、知乎專欄。