簡介
微服務和單體服務的各自好處之前的文章中已經講的很明白了。本篇文章不是探討到底應該用哪種服務架構。而是假設專案最終會採用微服務架構，那麼就會有兩種情況，第一種情況下專案一開始的時候，是先使用單體服務然後在專案發展過程中逐漸轉換成微服務，另外一種就是一開始就採用微服務的架構。
本文將會討論一下采用這兩種方式的原因。
先單體再微服務
微服務是一種有用的架構，但即使是他們的擁護者也表示，使用微服務只對更復雜的系統有用。
因為使用微服務本身是有一個管理上的服務成本，這個成本會減慢團隊的開發速度。所以對於更簡單的應用程式來說，使用單體服務更加簡單。所以該方式的支持者認為應該在最初將新應用程式構建為單體應用，即使最後很有可能轉換為微服務。
第一個原因是在系統的初期，我們並不知道它到底會有多少使用者，並且在軟體的第一個階段，我們通常考慮的是軟體開發的速度，所以大家可能更加傾向於使用單體應用。如果使用了微服務，如果該微服務的設計比較糟糕，那麼會導致後續系統無法擴充套件，只能重新設計。
第二個原因是，只有在服務之間提出良好、穩定的邊界時，它們才能很好地工作，服務之間的任何功能重構都比單體應用困難得多。但即使是在熟悉領域工作的經驗豐富的架構師，在一開始就很難確定邊界。通過首先構建一個單體服務，您可以弄清楚正確的邊界是什麼，從而在邊界之上再進行微服務的轉換。
一種將單體服務轉換為微服務的做法是，將單體服務經過合理的設計，比如注意軟體內部的模組化，包括 API 邊界和資料儲存方式。如果能夠做好這一點，那麼後續轉向微服務是一件相對簡單的事情。
另一種方法是從單體應用開始，逐漸剝離邊緣的微服務。這種方法可以在微服務架構的核心留下一個龐大的單體，但大多數新的開發使用微服務，而單體應用不再進行擴充套件。
還有一種是完全替代單體應用。這樣可以完全拋棄單體帶來的架構負擔，重新開始。代價就是需要多花人力和時間。
所以，如果你不能構建一個結構良好的單體應用，那麼是什麼讓你認為你可以構建一組結構良好的微服務？
直接從微服務開始
當然，也有人持有不同的意見，因為他們認為：
如果你確實能夠構建結構良好的單體應用，那麼您可能一開始就不需要微服務。
也就是說，不管是單體服務還是微服務，在構建之前都需要進行詳細的需求分析，經過了透徹的分析，那麼是否需要使用微服務一鍵很瞭解了，各個服務的邊界也被界定出來了，那麼為什麼不直接使用微服務呢？
微服務的主要好處就是在不同的服務之間建立了一個邊界。這樣我們很難弄錯一些事情，比如連線不應該連線的部分，並耦合那些不應該被耦合的部分。
在理論上，如果你的程式遵循了特定的規則，並在整體應用程式中建立明確的界限，那麼您不需要微服務，但是在實際的工作中，這個界限總是會被跨域。
你可能會假設有許多可以被很好地分離的微服務隱藏在你的單個專案中，等待被提取。但實際上，很難進行這樣的劃分。
如果你從一個整體開始，各個部分將變得非常緊密地相互耦合。這就是單體應用的定義。這些部件將依賴於它們都使用的平臺的特性。它們將基於共享的抽象進行通訊，因為它們都使用相同的庫。他們將使用僅當它們託管在同一程式中時才可用的方式進行通訊。更糟糕的是，這些部分將（幾乎）自由地共享域物件，依賴相同的共享永續性模型，假設資料庫事務隨時可用，因此無需補償……從而使得再次分割事務變得非常困難。所以將現有的單體拆分成單獨的部分非常困難。
所以當你開始時，就應該考慮你構建的子系統，並儘可能獨立地構建它們。當然，只有在您認為您的系統大到足以保證這一點時才應該這樣做。如果只有您和您的一位同事在幾周內構建了一些東西，那麼您完全不需要使用微服務。
總結
軟體架構的世界總是很有趣，我們在探索的過程中也會學到很多不一樣的視角。
本文已收錄於 http://www.flydean.com/10-microservices-monolith/
最通俗的解讀，最深刻的乾貨，最簡潔的教程，眾多你不知道的小技巧等你來發現！