漫談什麼時候從單體架構遷移到微服務？

原文: 漫談什麼時候從單體架構遷移到微服務？

面對微服務如火如荼的發展，不少人都在瞭解，學習但願能在本身的項目中幫得上忙，當你對微服務的廬山真面目有所瞭解後，接下來就是說服本身了，到底如何評估微服務，何時使用微服務，什麼時間點最合適，須要哪些技術儲備和資源投入等等，這些都是你須要面對和解決的。

本文從單體架構，微服務架構，微服務風險評估，微服務落地條件等幾個方面探討微服務的落地過程，但願對你有所啓發。

　　講解微服務以前，咱們先簡單瞭解下單體架構。

1、單體架構

　　

單體架構的優勢：

• 快速開發和驗證想法，證實產品思路是否可行

• 投入資源和成本，包括人力和物力相對比較節約

單體架構的缺點：

　　隨着業務的複雜度增長，單體的靈活度會逐漸降低，好比：

• IDE過載：隨着代碼量增長，代碼總體編譯效率降低。

• 規模化：沒法知足團隊規模化高效開發。

• 系統開發、測試、部署的衝突和效率低下等問題

• 只能關注一套技術棧

• 應用擴展性比較差

• 海量用戶高併發訪問數量有限

單體適用場景：

　　架構設計的三大原則告訴咱們，架構須要的是簡單、適度、演化。

　　對於項目起步階段，單體是最高效也是最節省成本的方式。由於初期階段，因爲人力，成本，業務熟悉程度，微服務技術積累等因素，如何過分設計可能工期和複雜度會急劇上升，形成交付困難，問題百出，從而錯過了時間窗口。最合適，簡單的方式仍是單體優先，這是創業公司的特色決定的。固然設計面向微服務的單體架構也是一種聰明的方法，這遵照了系統演化的法則。

單體分層目的：

　　不管採起何種維度的架構分層，分層的最核心目的是保證各層之間的差別足夠清晰，邊界足夠明顯，爲未來可能產生的變化提供最容易、最小化的修改。好比客戶端要從安卓替換爲IOS，底層無須任何改動，就像替換積木同樣。又好比，設備須要接入新的設備或協議，其餘層也不須要作任何變化，能夠無縫平滑接入任何設備。

建議

　　若是前期在業務不十分清晰，求的是驗證想法，證實產品思路是否可行性，而且業務量不大，僅限於省級範圍，建議只要對當前架構稍加改良升級就能夠了，這樣改動量相對較小，且至少能支撐必定時間段的業務增加。

2、微服務架構

微服務的優點

　　支撐的業務更加龐大，能夠支撐海量用戶高併發和海量設備接入，支持分佈式多機房，多區域部署，支持服務器無限擴容。支持私有云，公有云，混合雲等部署方式。因此微服務是大多數互聯網公司的首選。

微服務的代價

• 技術門檻高：微服務包括，服務描述，註冊中心，服務框架，服務監控，服務追蹤，服務治理等幾大基本組件，以上每一個組件缺一不可，每一個組件展開又包括不少技術門檻，好比，容器技術，持續部署，DevOps等相關概念。
• 複雜性增長：相對單體架構將全部功能打包部署在一塊兒，集中地進行開發、測試和運維，微服務會將這些單體的服務進行拆分部署，業務拆分粒度是一個難點，拆分後服務聚合也是一個麻煩。由於服務粒度增長後，相互調用，相互依存，因此問題排查難度會增長，就須要一套完整的服務監控，服務跟蹤和治理的系統。
• 觀念變化：微服務不只僅是技術的升級，更是開發方式、組織架構、開發觀念的轉變。
• 前期投入成本較高

微服務架構圖

　　微服務架構圖譜谷歌或Bing下，能夠看到各類各樣的架構圖，源於業務和架構師自身的喜愛或者粗細粒度，可是每一個架構圖的基本組件和架構分層都差異不大，只是有的細一些，有的粗一下。好比有客戶端層，容器層(K8S)，API Gateway，微服務集羣層，EventBus層是必需要有的，至於服務監控和服務跟蹤、服務治理自己就是一個完整的系統，粒度就沒有細了。基於這些概念，我把架構圖稍微細化一下，這裏省去服務監控跟蹤和治理的部分，後續單獨抽離出來分析。

　　這邊的架構圖譜相對以前的架構圖，更加貼近業務，粒度也更細，雖然個別組件有所省略，好比跟蹤和治理部分。

　　

　　以上架構圖主要分4層，每一個層次遵循架構分層的核心思想：關注點分離，職責各異，邊界清晰。

　　第1層：客戶端：理論上包含一切能夠聯網的設備，包括移動設備，Android、IoS、Pad、微信、微博、QQ、Web、各自瀏覽器、物聯網設備等等……

　　第2層：API網關：包括服務註冊，發現，認證受權，單點登陸，熔斷，限流……網關的知識點豐富，是微服務的核心之一。

• • 假如網關對外提供統一的地址：www.jackyfei.com

　　第3層：微服務集羣：包括各類具體的microservice，好比縱向劃分的業務服務(用戶服務，訂單服務，……)，橫向劃分的基礎或公共服務(元數據服務，公共服務……)

　　其餘微服務的地址多是這樣的：

• • 用戶服務：1.user.jackyfei.com
  • 訂單服務：2.order.jackyfei.com
  • 元數據服務：3.base.jackyfei.com
  • 消息服務：4.msg.jackyfei.com

　　第4層：事件總線：Event Bus 目的是消息解耦，不要讓服務之間直接的連接。不一樣與SOA的服務總線，事件總線相對比較輕量，常常基於消息隊列引擎進行解耦，目的是爲了讓服務之間的關聯弱化，不直接進行關聯。不少時候用的是相對穩定、可靠、企業級的RabbitMQ。

　　微服務的架構其實不難，根據以上的架構，每種業務均可以進行套用，這裏的難點在於服務的劃分和粒度控制，另外如何管理膨脹的服務是一個麻煩事。

3、什麼時候採用微服務?

3.1楊波說

　　這裏引用架構師楊波(前Ebay架構師，目前任職拍拍貸研發部總監，資深技術架構師，微服務技術專家)的一些觀點：

　　「企業一開始不推薦直接使用微服務，由於微服務須要前期基礎設施的投資，複雜性很高，若是對問題領域並非很理解，一開始用微服務，你很難去劃分服務的邊界，你的生產力反而會比較低，並且你花了很大精力進行開發，你的產品並無被市場驗證過，有可能會失敗，因此這個選項風險會比較高。因此咱們推薦的是單塊優先，先從單塊運用作起，這樣成本低，團隊成員也比較少，無須太多研發投入，就能夠交付一些基本的功能給客戶使用。

　　隨着應用愈來愈成功，客戶增長，你的系統複雜度會愈來愈高，就會出現單塊應用和團隊規模之間的矛盾，生產力會隨着業務複雜度逐漸下降。因此在一些初創型公司，你更多看到的是單塊應用，只有一些中大型的公司會看到微服務架構。」

      

　　「交叉點代表，業務已經到達了必定的複雜性，單塊應用已經沒法知足業務增加的須要，研發效率開始降低了，而微服務能夠提高研發和交付的效率。這個點須要架構師去綜合，權衡。我的經驗，通常團隊須要達到百人規模，纔去考慮微服務。」

　　以上的觀點講的很中肯，給個人啓發和幫助很是大。這裏的交叉點怎麼來肯定和評估是重點，好比咱們上線一個社交姑且叫抖信，初期爲了快速上線，驗證可行性，能夠只開發首頁聊天、通信錄、評論等基本功能。產品上線後，通過一段時間的運營，用戶開始逐步增多，可行性驗證經過，下一階段就須要進一步增長更多的新特性來吸引更多的目標用戶，好比再給這個社交抖信添加朋友圈、消息通知、遊戲、電商等等功能。

　　「通常狀況下，這個時候就須要大規模地擴張開發人員，以支撐多個功能的開發。若是這個時候繼續採用單體應用架構，多個功能模塊混雜在一塊兒開發、測試和部署的話，就會致使不一樣功能之間相互影響，一次打包部署須要全部的功能都測試 OK 才能上線。

　　不只如此，多個功能模塊混部在一塊兒，對線上服務的穩定性也是個巨大的挑戰。好比 A 開發的一個功能因爲代碼編寫考慮不夠全面，上線後產生了內存泄漏，運行一段時間後進程異常退出，那麼部署在這個服務池中的全部功能都不可訪問。

　　根據個人實際項目經驗，一旦單體應用同時進行開發的人員超過 10 人，就會遇到上面的問題，這個時候就該考慮進行服務化拆分了。」 ---胡忠想(微博微服務技術專家)

　　至此，咱們什麼時候採用微服務已經十分明確了，關鍵是 業務複雜度和 團隊規模兩大要點，而業務複雜度和市場窗口是權衡和抉擇的首要因素。

3.2微服務落地條件評估

　　通常狀況下，業務系統引入新技術就必然會帶來架構的複雜度提高，在具體決策前，你先要認識到新架構會帶來哪些新的問題，這些問題你和你的團隊是否可以解決？如何解決？是本身投入人力建設，仍是採用業界開源方案？假如你和我同樣都是微服務的旁觀者或者學習者，那麼下面的評估也許對你又所參考。

3.2.1落地方式選擇

不一樣的落地方式決定不一樣的資源配置。

方式一：借力外部架構諮詢公司提供架構DEMO和培訓服務助推內部團隊技術轉型升級。

方式二：招聘相關經驗豐富的人員進來，自行研究和搭建架構並作內部培訓，推進團隊技術升級。

建議：若是比較緊急，採用第一種方式，由於招聘匹配的人才比較困難，等不起。可是無論是那種方式，對於團隊來講都須要必定的技術人才儲備方便後續交接和運維。

3.2.2人才儲備

　　這裏分紅兩類人員，一類是研究型，一類是應用型。研究型主要是以技術攻堅爲主，負責微服務的核心組件的研究和開發，好比服務發佈和訂閱，服務跟蹤和監控，服務的治理；應用型主要是負責技術理解應用爲主。

　　

3.2.3技術儲備

　　微服務相關技術棧和微服務周邊技術棧。周邊技術棧包括領域驅動涉及，持續交付，分佈式至少，負載均衡，CAP理論，緩存原理，DevOps和容器化技術。

3.2.4團隊規模評估

　　楊波在給微服務的開發團隊規劃時候給了一個百人左右的大概預估，至於到底須要多少開發人員就沒有細說，可能做者自己呆過的公司都是大廠，對人力成本控制沒有那麼大的包袱，對於中小企業，人力是最貴的成本。若是要必定要上微服務，該怎麼辦？

　　對於微服務的團隊規模衆說紛紜，有的說要百來號人；有的說須要精兵10人左右；有的說和人數沒有關係，只和業務有關；有的說一個懂微服務的架構師也能搞定。這些說法都比較籠統，若是你想上微服務，人力評估包括人力、能力、人數等等，這些因素仍是很是重要的，畢竟成本纔是商業的本質，有可能不客觀的規劃會致使項目的潰敗。 

　　對於微服務的團隊規模是哪些方面決定的呢？我以爲至少要從如下兩個維度來評估：

　　 業務規模：若是大家的業務架構很是複雜，有倉儲系統開發，ERP系統，OA系統，訂單系統等等，業務越多，需求人數越多(這裏人數指的都是後臺開發人數)。

　　 技術能力：另外，別忘了非功能性的開發，好比API網關，服務跟蹤、治理等也是須要人去開發和維護的，這些非功能性的核心組件須要多少人，因爲沒有完整的開發經驗，加上個別組件，好比跟蹤系統，開發的程度可深可淺，開發週期可長可短，以目前我的的經驗還沒法給與合理的建議。可能牛人1我的兩週就夠了，也可能高級開發2我的，一人分工三個核心組件，兩週也夠用。或者架構外包，只要交接的人能跟上，也是一種解決方案。

　　總結：1個精通微服務落地經驗的架構師是必不可少的，圍繞架構師周邊一幫高級開發，按 根據實際業務來肯定，通常一個開發負責2-3個核心模塊，不宜太多，好比目前核心模塊有8個，對應人數配置大概在3-4個左右。

3.3轉微服務風險評估

3.3.1重寫面廣

　　因爲是架構級別的調整，以前能保留下來的大部分是解耦比較好的代碼，好比前端代碼，採集服務代碼，部分業務邏輯代碼，因此對現有框架衝擊面比較大。

3.3.2複雜度高

　　由於微服務是一種觀念和思想，又是新近技術，自己就有各類架構實現方式和技術解決方案。因此對技術人員來講，對比選型自己就是一個考驗。加上自己涉及的技術面就比較廣，因此複雜度和門檻相對比較高。

可是該技術發源於亞馬遜，通過近些年的發展，雖然還在發展，可是已經相對成熟。

3.3.3人員配置

　　微服務架構工做量主要集中在後端，對後端開發人員的技術級別有較高的要求，主要是對微服務原理和開源組件的熟悉上，同時須要具有總體的微服務的意識。暫時不具有總體微服務開發意識和經驗，須要經過培訓後進行轉型升級。

3.3.4合做方式

　　若是採用藉助外部架構力量來助推架構升級，和架構單位的合做就不是簡單的外包，涉及的面會變得比較廣，在徹底交接過來以前，週期會比較長。包括對咱們業務架構的深刻了解，而後根據業務架構繪製可靠技術架構藍圖，再根據技術藍圖進行落地實施(不建議只提供架構方案而由其餘單位實施落地)，包括新系統的開發，舊系統的升級，固然這種升級是平滑過分的，對業務窗口並不會產生影響。

3.4合理的拆分姿式

　　如何正確拆分？這裏正確指的是合理，由於沒有絕對的標準。按照前人的經驗能夠分爲縱向和橫向兩種劃分方法：

3.4.1縱向拆分

　　是從業務維度進行拆分。標準是按照業務的關聯程度來決定，關聯比較密切的業務適合拆分爲一個微服務，而功能相對比較獨立的業務適合單獨拆分爲一個微服務，好比上圖中的訂單服務，用戶服務。另外粒度過小，服務聚合是一個坑，粒度太大，分和沒分一個樣。

3.4.2橫向拆分

　　是從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其餘服務調用，且依賴的資源獨立不與其餘業務耦合。好比上圖中的元數據服務和消息服務。

3.4.3總結

　　借用《微服務設計》中的一句話：「你越不瞭解一個領域，爲服務找到合適的界限上下文就越難……服務的界限劃分錯誤，可能會致使不得不頻繁地更改服務間的協做，而這種更改爲本更高……」

4、SOA和微服務

　　因爲SOA和微服務有千絲萬縷的關係，這裏簡單羅列雙方的對比圖，算是一個小知識點：

　　

　　兩種架構背後的意圖是不一樣的：SOA嘗試將應用集成，通常採用中央管理模式來確保各應用可以交互運做。微服務嘗試部署新功能，快速有效地擴展開發團隊。它着重於分散管理、代碼再利用與自動化執行。

5、總結

　　最後讓咱們回顧一下前人經典的話語：

• 分佈式第必定律是「儘可能不要使用分佈式」。
• 軟件行業從業者，尤爲是那些已經不寫代碼的從業者，總會指望有銀彈，但銀彈終究是沒有的。
• 微服務依賴於「基礎設施自動化」。微服務不是「銀彈」。

　　仍是回到咱們架構設計的原則上，遵循簡單，適用，演化的原則，那麼你的抉擇也許會變得沒有那麼使人糾纏。

文章引用

• 從單體式架構遷移到微服務架構
• 《微服務設計》做者: [英] Sam Newman 出版社: 人民郵電出版社
• 4 Challenges You Need to Address with Microservices Adoption
• 爲何使用微服務？