架構之:微服務和單體服務之争

目錄

• 簡介
• 先單體再微服務
• 直接從微服務開始
• 總結

微服務和單體服務的各自好處之前的文章中已經講的很明白了。本篇文章不是探讨到底應該用哪種服務架構。而是假設項目最終會采用微服務架構，那麼就會有兩種情況，第一種情況下項目一開始的時候，是先使用單體服務然後在項目發展過程中逐漸轉換成微服務，另外一種就是一開始就采用微服務的架構。

本文将會讨論一下采用這兩種方式的原因。

微服務是一種有用的架構，但即使是他們的擁護者也表示，使用微服務隻對更複雜的系統有用。

因為使用微服務本身是有一個管理上的服務成本，這個成本會減慢團隊的開發速度。是以對于更簡單的應用程式來說，使用單體服務更加簡單。是以該方式的支援者認為應該在最初将新應用程式建構為單體應用，即使最後很有可能轉換為微服務。

第一個原因是在系統的初期，我們并不知道它到底會有多少使用者，并且在軟體的第一個階段，我們通常考慮的是軟體開發的速度，是以大家可能更加傾向于使用單體應用。如果使用了微服務，如果該微服務的設計比較糟糕，那麼會導緻後續系統無法擴充，隻能重新設計。

第二個原因是，隻有在服務之間提出良好、穩定的邊界時，它們才能很好地工作，服務之間的任何功能重構都比單體應用困難得多。但即使是在熟悉領域工作的經驗豐富的架構師，在一開始就很難确定邊界。通過首先建構一個單體服務，您可以弄清楚正确的邊界是什麼，進而在邊界之上再進行微服務的轉換。

一種将單體服務轉換為微服務的做法是，将單體服務經過合理的設計，比如注意軟體内部的子產品化，包括 API 邊界和資料存儲方式。如果能夠做好這一點，那麼後續轉向微服務是一件相對簡單的事情。

另一種方法是從單體應用開始，逐漸剝離邊緣的微服務。這種方法可以在微服務架構的核心留下一個龐大的單體，但大多數新的開發使用微服務，而單體應用不再進行擴充。

還有一種是完全替代單體應用。這樣可以完全抛棄單體帶來的架構負擔，重新開始。代價就是需要多花人力和時間。

是以，如果你不能建構一個結構良好的單體應用，那麼是什麼讓你認為你可以建構一組結構良好的微服務？

當然，也有人持有不同的意見，因為他們認為：

如果你确實能夠建構結構良好的單體應用，那麼您可能一開始就不需要微服務。

也就是說，不管是單體服務還是微服務，在建構之前都需要進行詳細的需求分析，經過了透徹的分析，那麼是否需要使用微服務一鍵很了解了，各個服務的邊界也被界定出來了，那麼為什麼不直接使用微服務呢？

微服務的主要好處就是在不同的服務之間建立了一個邊界。這樣我們很難弄錯一些事情，比如連接配接不應該連接配接的部分，并耦合那些不應該被耦合的部分。

在理論上，如果你的程式遵循了特定的規則，并在整體應用程式中建立明确的界限，那麼您不需要微服務，但是在實際的工作中，這個界限總是會被跨域。

你可能會假設有許多可以被很好地分離的微服務隐藏在你的單個項目中，等待被提取。但實際上，很難進行這樣的劃分。

如果你從一個整體開始，各個部分将變得非常緊密地互相耦合。這就是單體應用的定義。這些部件将依賴于它們都使用的平台的特性。它們将基于共享的抽象進行通信，因為它們都使用相同的庫。他們将使用僅當它們托管在同一程序中時才可用的方式進行通信。更糟糕的是，這些部分将（幾乎）自由地共享域對象，依賴相同的共享持久性模型，假設資料庫事務随時可用，是以無需補償……進而使得再次分割事務變得非常困難。是以将現有的單體拆分成單獨的部分非常困難。

是以當你開始時，就應該考慮你建構的子系統，并盡可能獨立地建構它們。當然，隻有在您認為您的系統大到足以保證這一點時才應該這樣做。如果隻有您和您的一位同僚在幾周内建構了一些東西，那麼您完全不需要使用微服務。

軟體架構的世界總是很有趣，我們在探索的過程中也會學到很多不一樣的視角。

本文已收錄于 http://www.flydean.com/10-microservices-monolith/

最通俗的解讀，最深刻的幹貨，最簡潔的教程，衆多你不知道的小技巧等你來發現！