糾結了，微服務和單體你選擇哪一個？

banq發表於2018-08-10
微服務
本文是一篇微服務和單體架構比較文章，這類文章很多，但是比較的現象背後其實已經假設了一種先驗的判斷標準，這篇文章的言下之意是微服務比單體高階，對人員素質要求高，其實這是一種誤解，微服務正是首先承認人理性設計能力不夠，才用行動替代設計，先分成兩三人的突擊隊上前線摸清敵情，相比單體的總體規劃，然後再切分上下文來說，對人員的設計能力要求不高，以上只是banq個人意見，看看原文大意：

“微服務”正成為是行業的流行語，現在除微服務設計外，其餘的設計被貼上“單體Monolith”標籤，但作為一名架構師，當嘗試基於某個領域開始建立新軟體設計時，會不進行任何判斷而直接採用微服務嗎？只是因為它是受歡迎的？每個人都應該只是停下來考慮一下自己公司基礎設施、員工專業知識、並在此基礎上選擇M微服務。

讓我們看看微服務和單體的比較：

1. 專案相關人力資源：當你接到一個專案時，首先要考慮的第一個問題是在這個專案中將會有多少員工？他們的經歷是什麼。如果你的實力很低，比如那就不要使用微服務，因為微服務意味著獨立的服務，而座右銘是“你建立它你就執行它”，所以應該有一個團隊擁有完整的微服務所有權，如果你人力數量少，每一個或兩個人將擁有兩個或三個微服務的所有權，微服務數量大於人員數量，會產生一個關鍵問題：知識會僅限於他們之間，他們將成為中樞員工，另一方面根據“開發人員應該只關注一小部分”座右銘，但是在這種情況下他們瞭解所有的服務了，破壞了這一規則。

2.微服務及其相關知識：微服務是一種新的架構，有各種與微服務相關的概念，如分散式架構規則，如高可用性、彈性、服務發現、CAP定理、領域驅動設計、斷路器模式、分散式快取機制、路由跟蹤等，不僅DevOps文化與微服務緊密結合，才能發揮微服務的全部功能，因此你需要了解CI / CD工具及其文化（自動部署）。團隊應該高效地驅動所有這些微服務，如果微服務部署在雲或容器中，團隊應該瞭解雲架構（PCF，亞馬遜，Bluemix等）或Container架構（Docker，Docker Swarm，Messos，Kubernetes等）。

3.組織架構：另一個重要的維度是組織基礎架構，在調整微服務之前總是檢查組織工作的模式，根據Conway康威定律，你公司的組織結構已經反映到了程式碼中，那麼首先請檢查，你的公司是否採用了敏捷技術？是否構建了跨技術團隊（如UI，中間層，資料庫），什麼是部署和QA測試模式？你的公司是否遵循手動部署和手動測試？或者他們已經或將要採用DevOps文化，其中待部署的釋出包是什麼？ 公司有幾個伺服器？你可以在其中安裝應用程式伺服器並部署的釋出包？或準備使用雲？基於這些引數選擇你是否會採用微服務。

3.領域關鍵性：檢查你正在從事的領域性質，與業務分析師一起了解有很重要的，是否需要將領域拆分為子域，以便相關功能是否可以基於上下文的基礎上封裝，如果不是那就只好堅持單體了，因為不再需要建立上下文對映Context map並在有界上下文中封裝子域了。

4.專案預算：這是另一個重要的方面。想想專案的預算，專案的性質是固定出價還是TNM型別。微服務專案比巨石更昂貴，因為它需要更多的伺服器或雲基礎設施、自動化管道、資源數量，所有團隊都應該是跨技能團隊，因此在基礎設施和資源水平方面它比單體成本高得多，所以想想你的預算與你的專案保持一致（偷偷地我給一個提示給你，請不要向任何人釋出，作為一個優秀的忠誠架構師總是要考慮邊際收入，模組化的單體比微型服務更好，如果預算很少，它可以達到你的目的收入，而且在未來如果你想遷移到微服務也是可能的。）

結論 ：現在，新手或中級開發人員認為單體是一個大爛泥塊，但如果你保持模組化的方法，它還是好的，在許多情況下，當我們的資源有限時，它比微服務更好。所以謹慎選擇不要順其自然，我總是建議首先使用單體，但是使其模組化，如果你使用Java9的模組，你可以從模組化開始採用SOA，當有實際需要時，比如模組邊界會洩漏，或者你無法維護模組之間的非迴圈圖（DAG），然後考慮在DDD上使用單體並且可以傾向於微服務。在此之前，我想說的是不要因為其他人正在採用微服務就用它，而是在你需要時採用它。 “偉大的力量來自偉大的責任”。

(banq注：該文滲透著一種對新技術和方法的恐懼和本能排斥，總是把新東西看得高大上，把很多新東西糅合成大爛泥塊阻嚇別人，微服務的好處是執行時的模組化和外掛化，單體的模組化只能做到開發時的模組化。)

Microservice Vs Monolith:Which one to Choose? | Ma

相關文章