如何從傳統(tǒng)單體架構(gòu)轉(zhuǎn)向微服務(wù)？

從傳統(tǒng)單體架構(gòu)轉(zhuǎn)向微服務(wù)，是隨著業(yè)務(wù)應(yīng)用系統(tǒng)愈來愈復(fù)雜與技術(shù)不斷交織演進(jìn)的結(jié)果。

微服務(wù)架構(gòu)簡介微服務(wù)是架構(gòu)層的一個(gè)概念，通過分解（業(yè)務(wù)單元），將項(xiàng)目拆解出 n 個(gè)單元，互相沒有強(qiáng)依賴關(guān)系（解耦），自我準(zhǔn)備需要的依賴條件，進(jìn)而達(dá)到可以獨(dú)立運(yùn)行，不再受環(huán)境與地點(diǎn)上的限制。微服務(wù)的由來微服務(wù)最早由 Martin Fowler 與 James Lewis 于 2014 年共同提出，微服務(wù)架構(gòu)風(fēng)格是一種使用一套小服務(wù)來開發(fā)單個(gè)應(yīng)用的一種方式，每個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中，并使用輕量級(jí)機(jī)制通信，通常是 HTTP API，這些服務(wù)基于業(yè)務(wù)能力構(gòu)建，并能夠通過自動(dòng)化部署機(jī)制來獨(dú)立部署，這些服務(wù)使用不同的編程語言實(shí)現(xiàn)，以及不同數(shù)據(jù)存儲(chǔ)技術(shù)，并保持最低限度的集中式管理。傳統(tǒng)的單體應(yīng)用模式我們?cè)谝酝膫鹘y(tǒng)應(yīng)用模式下，大致是所有的功能都集成在同一個(gè)應(yīng)用中，這種模式一般被稱為單體式開發(fā)，即所有的功能打包在一個(gè) war 包內(nèi)，然后部署在 jee 中，這里面包含了所有的業(yè)務(wù)邏輯，觸發(fā)器，大部分的還包含了 ui，如下圖：這樣的模式下暴露出了他所致命的缺點(diǎn)：代碼管理比較難，因?yàn)榇蠹叶荚谕粋€(gè)工程下，會(huì)經(jīng)常的發(fā)生沖突新人不太容易上手，因?yàn)轳詈闲蕴撸{(diào)查一個(gè)問題時(shí)往往會(huì)牽扯更多的功能打包危險(xiǎn)度大，往往只是提交很小一部分的修改卻需要全量打包運(yùn)維危險(xiǎn)度大，可能只是某一個(gè)功能崩潰了就會(huì)導(dǎo)致整個(gè)系統(tǒng)癱瘓不容易擴(kuò)展，如果只是一個(gè)功能的請(qǐng)求量突增，不容易擴(kuò)展部署要求較高，這樣的應(yīng)用往往需要高配置的主機(jī)來承載微服務(wù)的應(yīng)用模式我們?cè)谧黾軜?gòu)設(shè)計(jì)的時(shí)候，常常需要遵守三個(gè)標(biāo)準(zhǔn)（敏捷性、用戶體驗(yàn)、成本），基于微服務(wù)的架構(gòu)設(shè)計(jì)目的就是有效的拆分應(yīng)用，每個(gè)應(yīng)用單獨(dú)管理，進(jìn)而實(shí)現(xiàn)敏捷開發(fā)和部署，如下圖： ?p?DB ?? DB由一些獨(dú)立的應(yīng)用組合成一個(gè)軟件系統(tǒng)，每個(gè)服務(wù)獨(dú)立運(yùn)行，跑在自己的微環(huán)

境中，每個(gè)服務(wù)獨(dú)立開發(fā)可以按照業(yè)務(wù)單元進(jìn)行拆分，實(shí)現(xiàn)了跨組織夸地域協(xié)同的問題，多個(gè)服務(wù)采用分布式進(jìn)行管理，且具有強(qiáng)隔離性。

微服務(wù)架構(gòu)在微服務(wù)架構(gòu)中，除了每個(gè)業(yè)務(wù)單元的服務(wù)外，就是那些服務(wù)治理組件了，比如：服務(wù)中心、服務(wù)消費(fèi)、負(fù)載均衡、斷路器、智能路由、配置管理等，這些個(gè)組件互相配合再加上業(yè)務(wù)的各個(gè)微服務(wù)，共同組建了一個(gè)微服務(wù)系統(tǒng)，一個(gè)簡單的微服務(wù)系統(tǒng)如下：

用戶通過客戶端發(fā)起請(qǐng)求，nginx 負(fù)載到某個(gè) zuul 上然后轉(zhuǎn)發(fā)到相應(yīng)的微服務(wù)上，微服務(wù)間通過 rpc 或者 mq 進(jìn)行通信，通過配置服務(wù)獲取配置數(shù)據(jù)，最終將整合后的結(jié)果返回給用戶。

微服務(wù)的優(yōu)缺點(diǎn)微服務(wù)架構(gòu)之所以流行起來，與他的這些優(yōu)點(diǎn)密不可分，比如：他將巨大的單體式應(yīng)用分解出多個(gè)服務(wù)，解決了復(fù)雜性的問題，在總功能不變的情況下，系統(tǒng)被分解成多個(gè)可管理的服務(wù)，每個(gè)服務(wù)都用 rpc/mq 來驅(qū)動(dòng)和定義清晰的 api 邊界，為很難實(shí)現(xiàn)的功能提供了模塊化的解決方案，并且更容易開發(fā)和維護(hù)。在這樣的架構(gòu)模式下，可以實(shí)現(xiàn)每個(gè)服務(wù)可由不同的團(tuán)隊(duì)來開發(fā)，從而放寬了技術(shù)選型，只需提供標(biāo)準(zhǔn)的 restapi 即可，在這種自由模式的開發(fā)背景下， 開發(fā)者可以選擇較新的技術(shù)，由于每個(gè)服務(wù)的功能很小，所以開發(fā)的難度也很低，即使出現(xiàn)了代碼重寫的問題難度也不是很大。由于微服務(wù)采用的是獨(dú)立部署，開發(fā)者在部署的時(shí)候不用考慮其他的服務(wù)對(duì)自己的影響，這種改變加快了部署速度并減少了部署風(fēng)險(xiǎn)，微服務(wù)架構(gòu)使ci/cd 成為可能。但是微服務(wù)也存在一些不足，比如：微服務(wù)采用的分布式系統(tǒng)，故而會(huì)產(chǎn)生固有的復(fù)雜性，開發(fā)者需要在 rpc 等消息傳遞之間完成進(jìn)程間的通訊，更或者需要用代碼來解決消息傳遞過慢或異常的情況。來源于數(shù)據(jù)庫事務(wù)的分布，以至于我們不能達(dá)到強(qiáng)一致性，只能的選擇最終一致性當(dāng)我們對(duì)某個(gè)服務(wù)的某個(gè) api 進(jìn)行測(cè)試的時(shí)候，需要保證這個(gè)服務(wù)所依賴的其他服務(wù)都是正常開啟的狀態(tài)，這給測(cè)試帶來了復(fù)雜性的問題。

Fred Brooks 曾寫過 there are no silver bullets，像其他科技一樣，微服務(wù)也有很多不足，所以在做系統(tǒng)架構(gòu)之前首先要確定最終的目的，是否有效的拆分應(yīng)用，是否需要實(shí)現(xiàn)敏捷開發(fā)、敏捷部署。

思想上的轉(zhuǎn)變微服務(wù)對(duì)于我們來說，技術(shù)上不是問題，更多的是思維邏輯，對(duì)于微服務(wù)架構(gòu)我們應(yīng)該主動(dòng)的在思維上進(jìn)行轉(zhuǎn)變。主要有一下幾點(diǎn)：應(yīng)用的單元是業(yè)務(wù)邏輯，按照業(yè)務(wù)進(jìn)行服務(wù)的拆分做有生命的產(chǎn)品，而不是項(xiàng)目培養(yǎng)團(tuán)隊(duì)內(nèi)部核心人員，微服務(wù)架構(gòu)師，全棧專家單一職責(zé)的原則，每個(gè)服務(wù)只干一件事情部署方式向 docker 轉(zhuǎn)型開發(fā)模式向 devops 轉(zhuǎn)型同時(shí)，對(duì)于開發(fā)同學(xué)，有這么多的中間件和強(qiáng)大的 PE 支持固然是好事，我們也需要深入去了解這些中間件背后的原理，知其然知其所以然。最后，一般提到微服務(wù)都離不開 DevOps 和 Docker，理解微服務(wù)架構(gòu)是核心， devops 和 docker 則是工具，是手段。