微服務(wù)架構(gòu)實(shí)施原理詳解
點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號(hào)”
優(yōu)質(zhì)文章，第一時(shí)間送達(dá)
基于微服務(wù)架構(gòu)和Docker容器技術(shù)的PaaS云平臺(tái)建設(shè)目標(biāo)是給我們的開(kāi)發(fā)人員提供一套服務(wù)快速開(kāi)發(fā)、部署、運(yùn)維管理、持續(xù)開(kāi)發(fā)持續(xù)集成的流程。平臺(tái)提供基礎(chǔ)設(shè)施、中間件、數(shù)據(jù)服務(wù)、云服務(wù)器等資源，開(kāi)發(fā)人員只需要開(kāi)發(fā)業(yè)務(wù)代碼并提交到平臺(tái)代碼庫(kù)，做一些必要的配置，系統(tǒng)會(huì)自動(dòng)構(gòu)建、部署，實(shí)現(xiàn)應(yīng)用的敏捷開(kāi)發(fā)、快速迭代。在系統(tǒng)架構(gòu)上，PaaS云平臺(tái)主要分為微服務(wù)架構(gòu)、Docker容器技術(shù)、DveOps三部分，這篇文章重點(diǎn)介紹微服務(wù)架構(gòu)的實(shí)施。
實(shí)施微服務(wù)需要投入大量的技術(shù)力量來(lái)開(kāi)發(fā)基礎(chǔ)設(shè)施，這對(duì)很多公司來(lái)說(shuō)顯然是不現(xiàn)實(shí)的，別擔(dān)心，業(yè)界已經(jīng)有非常優(yōu)秀的開(kāi)源框架供我們參考使用。目前業(yè)界比較成熟的微服務(wù)框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套實(shí)現(xiàn)微服務(wù)的框架，它提供了開(kāi)發(fā)微服務(wù)所需的組件，跟Spring Boot一起使用的話開(kāi)發(fā)微服務(wù)架構(gòu)的云服務(wù)會(huì)變的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我們的微服務(wù)架構(gòu)設(shè)計(jì)中，就使用了很多Spring Cloud Netflix框架的組件。Spring Cloud Netflix項(xiàng)目的時(shí)間還不長(zhǎng)，相關(guān)的文檔資料很少，博主當(dāng)時(shí)研究這套框架啃了很多英文文檔，簡(jiǎn)直痛苦不堪。對(duì)于剛開(kāi)始接觸這套框架的同學(xué)，要搭建一套微服務(wù)應(yīng)用架構(gòu)，可能會(huì)不知道如何下手，接下來(lái)介紹我們的微服務(wù)架構(gòu)搭建過(guò)程以及需要那些框架或組件來(lái)支持微服務(wù)架構(gòu)。
為了直接明了的展示微服務(wù)架構(gòu)的組成及原理，博主畫了一張系統(tǒng)架構(gòu)圖，如下：
從上圖可以看出，微服務(wù)訪問(wèn)大致路徑為：外部請(qǐng)求 → 負(fù)載均衡 → 服務(wù)網(wǎng)關(guān)（GateWay）→ 微服務(wù) → 數(shù)據(jù)服務(wù)/消息服務(wù)。服務(wù)網(wǎng)關(guān)和微服務(wù)都會(huì)用到服務(wù)注冊(cè)和發(fā)現(xiàn)來(lái)調(diào)用依賴的其他服務(wù)，各服務(wù)集群都能通過(guò)配置中心服務(wù)來(lái)獲得配置信息。
服務(wù)網(wǎng)關(guān)（GateWay）
網(wǎng)關(guān)是外界系統(tǒng)（如：客戶端瀏覽器、移動(dòng)設(shè)備等）和企業(yè)內(nèi)部系統(tǒng)之間的一道門，所有的客戶端請(qǐng)求通過(guò)網(wǎng)關(guān)訪問(wèn)后臺(tái)服務(wù)。為了應(yīng)對(duì)高并發(fā)訪問(wèn)，服務(wù)網(wǎng)關(guān)以集群形式部署，這就意味著需要做負(fù)載均衡，我們采用了亞馬遜EC2作為虛擬云服務(wù)器，采用ELB(Elastic Load Balancing)做負(fù)載均衡。EC2具有自動(dòng)配置容量功能，當(dāng)用戶流量達(dá)到尖峰，EC2可以自動(dòng)增加更多的容量以維持虛擬主機(jī)的性能。ELB彈性負(fù)載均衡，在多個(gè)實(shí)例間自動(dòng)分配應(yīng)用的傳入流量。為了保證安全性，客戶端請(qǐng)求需要使用https加密保護(hù)，這就需要我們進(jìn)行SSL卸載,使用Nginx對(duì)加密請(qǐng)求進(jìn)行卸載處理。外部請(qǐng)求經(jīng)過(guò)ELB負(fù)載均衡后路由到GateWay集群中的某個(gè)GateWay服務(wù)，由GateWay服務(wù)轉(zhuǎn)發(fā)到微服務(wù)。服務(wù)網(wǎng)關(guān)作為內(nèi)部系統(tǒng)的邊界，它有以下基本能力：
1、動(dòng)態(tài)路由：動(dòng)態(tài)的將請(qǐng)求路由到所需要的后端服務(wù)集群。雖然內(nèi)部是復(fù)雜的分布式微服務(wù)網(wǎng)狀結(jié)構(gòu)，但是外部系統(tǒng)從網(wǎng)關(guān)看就像是一個(gè)整體服務(wù)，網(wǎng)關(guān)屏蔽了后端服務(wù)的復(fù)雜性。
2、限流和容錯(cuò)：為每種類型的請(qǐng)求分配容量，當(dāng)請(qǐng)求數(shù)量超過(guò)閥值時(shí)拋掉外部請(qǐng)求，限制流量，保護(hù)后臺(tái)服務(wù)不被大流量沖垮；黨內(nèi)部服務(wù)出現(xiàn)故障時(shí)直接在邊界創(chuàng)建一些響應(yīng)，集中做容錯(cuò)處理，而不是將請(qǐng)求轉(zhuǎn)發(fā)到內(nèi)部集群，保證用戶良好的體驗(yàn)。
3、身份認(rèn)證和安全性控制：對(duì)每個(gè)外部請(qǐng)求進(jìn)行用戶認(rèn)證，拒絕沒(méi)有通過(guò)認(rèn)證的請(qǐng)求，還能通過(guò)訪問(wèn)模式分析，實(shí)現(xiàn)反爬蟲功能。
4、監(jiān)控：網(wǎng)關(guān)可以收集有意義的數(shù)據(jù)和統(tǒng)計(jì)，為后臺(tái)服務(wù)優(yōu)化提供數(shù)據(jù)支持。
5、訪問(wèn)日志：網(wǎng)關(guān)可以收集訪問(wèn)日志信息，比如訪問(wèn)的是哪個(gè)服務(wù)？處理過(guò)程（出現(xiàn)什么異常）和結(jié)果？花費(fèi)多少時(shí)間？通過(guò)分析日志內(nèi)容，對(duì)后臺(tái)系統(tǒng)做進(jìn)一步優(yōu)化。
我們采用Spring Cloud Netflix框架的開(kāi)源組件Zuul來(lái)實(shí)現(xiàn)網(wǎng)關(guān)服務(wù)。Zuul使用一系列不同類型的過(guò)濾器（Filter），通過(guò)重寫過(guò)濾器，使我們能夠靈活的實(shí)現(xiàn)網(wǎng)關(guān)（GateWay）的各種功能。
服務(wù)注冊(cè)與發(fā)現(xiàn)
由于微服務(wù)架構(gòu)是由一系列職責(zé)單一的細(xì)粒度服務(wù)構(gòu)成的網(wǎng)狀結(jié)構(gòu)，服務(wù)之間通過(guò)輕量機(jī)制進(jìn)行通信，這就引入了服務(wù)注冊(cè)與發(fā)現(xiàn)的問(wèn)題，服務(wù)的提供方要注冊(cè)報(bào)告服務(wù)地址，服務(wù)調(diào)用放要能發(fā)現(xiàn)目標(biāo)服務(wù)。我們的微服務(wù)架構(gòu)中使用了Eureka組件來(lái)實(shí)現(xiàn)服務(wù)的注冊(cè)與發(fā)現(xiàn)。所有的微服務(wù)（通過(guò)配置Eureka服務(wù)信息）到Eureka服務(wù)器中進(jìn)行注冊(cè)，并定時(shí)發(fā)送心跳進(jìn)行健康檢查，Eureka默認(rèn)配置是30秒發(fā)送一次心跳，表明服務(wù)仍然處于存活狀態(tài)，發(fā)送心跳的時(shí)間間隔可以通過(guò)Eureka的配置參數(shù)自行配置，Eureka服務(wù)器在接收到服務(wù)實(shí)例的最后一次心跳后，需要等待90秒（默認(rèn)配置90秒，可以通過(guò)配置參數(shù)進(jìn)行修改）后，才認(rèn)定服務(wù)已經(jīng)死亡（即連續(xù)3次沒(méi)有接收到心跳），在Eureka自我保護(hù)模式關(guān)閉的情況下會(huì)清除該服務(wù)的注冊(cè)信息。所謂的自我保護(hù)模式是指，出現(xiàn)網(wǎng)絡(luò)分區(qū)、Eureka在短時(shí)間內(nèi)丟失過(guò)多的服務(wù)時(shí)，會(huì)進(jìn)入自我保護(hù)模式，即一個(gè)服務(wù)長(zhǎng)時(shí)間沒(méi)有發(fā)送心跳，Eureka也不會(huì)將其刪除。自我保護(hù)模式默認(rèn)為開(kāi)啟，可以通過(guò)配置參數(shù)將其設(shè)置為關(guān)閉狀態(tài)。
Eureka服務(wù)以集群的方式部署（在博主的另一篇文章中詳細(xì)介紹了Eureka集群的部署方式），集群內(nèi)的所有Eureka節(jié)點(diǎn)會(huì)定時(shí)自動(dòng)同步微服務(wù)的注冊(cè)信息，這樣就能保證所有的Eureka服務(wù)注冊(cè)信息保持一致。那么在Eureka集群里，Eureka節(jié)點(diǎn)是如何發(fā)現(xiàn)其他節(jié)點(diǎn)的呢？我們通過(guò)DNS服務(wù)器來(lái)建立所有Eureka節(jié)點(diǎn)的關(guān)聯(lián)，在部署Eureka集群之外還需要搭建DNS服務(wù)器。
當(dāng)網(wǎng)關(guān)服務(wù)轉(zhuǎn)發(fā)外部請(qǐng)求或者是后臺(tái)微服務(wù)之間相互調(diào)用時(shí)，會(huì)去Eureka服務(wù)器上查找目標(biāo)服務(wù)的注冊(cè)信息，發(fā)現(xiàn)目標(biāo)服務(wù)并進(jìn)行調(diào)用，這樣就形成了服務(wù)注冊(cè)與發(fā)現(xiàn)的整個(gè)流程。Eureka的配置參數(shù)數(shù)量很多，多達(dá)上百個(gè)，博主會(huì)在另外的文章里詳細(xì)說(shuō)明。
微服務(wù)部署
微服務(wù)是一系列職責(zé)單一、細(xì)粒度的服務(wù)，是將我們的業(yè)務(wù)進(jìn)行拆分為獨(dú)立的服務(wù)單元，伸縮性好，耦合度低，不同的微服務(wù)可以用不同的語(yǔ)言開(kāi)發(fā)，每一個(gè)服務(wù)處理的單一的業(yè)務(wù)。微服務(wù)可以劃分為前端服務(wù)（也叫邊緣服務(wù)）和后端服務(wù)（也叫中間服務(wù)），前端服務(wù)是對(duì)后端服務(wù)做必要的聚合和剪裁后暴露給外部不同的設(shè)備（PC、Phone等），所有的服務(wù)啟動(dòng)時(shí)都會(huì)到Eureka服務(wù)器進(jìn)行注冊(cè)，服務(wù)之間會(huì)有錯(cuò)綜復(fù)雜的依賴關(guān)系。當(dāng)網(wǎng)關(guān)服務(wù)轉(zhuǎn)發(fā)外部請(qǐng)求調(diào)用前端服務(wù)時(shí)，通過(guò)查詢服務(wù)注冊(cè)表就可以發(fā)現(xiàn)目標(biāo)服務(wù)進(jìn)行調(diào)用，前端服務(wù)調(diào)用后端服務(wù)時(shí)也是同樣的道理，一次請(qǐng)求可能涉及到多個(gè)服務(wù)之間的相互調(diào)用。由于每個(gè)微服務(wù)都是以集群的形式部署，服務(wù)之間相互調(diào)用的時(shí)候需要做負(fù)載均衡，因此每個(gè)服務(wù)中都有一個(gè)LB組件用來(lái)實(shí)現(xiàn)負(fù)載均衡。
微服務(wù)以鏡像的形式，運(yùn)行在Docker容器中。Docker容器技術(shù)讓我們的服務(wù)部署變得簡(jiǎn)單、高效。傳統(tǒng)的部署方式，需要在每臺(tái)服務(wù)器上安裝運(yùn)行環(huán)境，如果我們的服務(wù)器數(shù)量龐大，在每臺(tái)服務(wù)器上安裝運(yùn)行環(huán)境將是一項(xiàng)無(wú)比繁重的工作，一旦運(yùn)行環(huán)境發(fā)生改變，就不得不重新安裝，這簡(jiǎn)直是災(zāi)難性的。而使用Docker容器技術(shù)，我們只需要將所需的基礎(chǔ)鏡像（jdk等）和微服務(wù)生成一個(gè)新的鏡像，將這個(gè)最終的鏡像部署在Docker容器中運(yùn)行，這種方式簡(jiǎn)單、高效，能夠快速部署服務(wù)。每個(gè)Docker容器中可以運(yùn)行多個(gè)微服務(wù)，Docker容器以集群的方式部署，使用Docker Swarm對(duì)這些容器進(jìn)行管理。我們創(chuàng)建一個(gè)鏡像倉(cāng)庫(kù)用來(lái)存放所有的基礎(chǔ)鏡像以及生成的最終交付鏡像，在鏡像倉(cāng)庫(kù)中對(duì)所有鏡像進(jìn)行管理。
服務(wù)容錯(cuò)
微服務(wù)之間存在錯(cuò)綜復(fù)雜的依賴關(guān)系，一次請(qǐng)求可能會(huì)依賴多個(gè)后端服務(wù)，在實(shí)際生產(chǎn)中這些服務(wù)可能會(huì)產(chǎn)生故障或者延遲，在一個(gè)高流量的系統(tǒng)中，一旦某個(gè)服務(wù)產(chǎn)生延遲，可能會(huì)在短時(shí)間內(nèi)耗盡系統(tǒng)資源，將整個(gè)系統(tǒng)拖垮，因此一個(gè)服務(wù)如果不能對(duì)其故障進(jìn)行隔離和容錯(cuò)，這本身就是災(zāi)難性的。我們的微服務(wù)架構(gòu)中使用了Hystrix組件來(lái)進(jìn)行容錯(cuò)處理。Hystrix是Netflix的一款開(kāi)源組件，它通過(guò)熔斷模式、隔離模式、回退（fallback）和限流等機(jī)制對(duì)服務(wù)進(jìn)行彈性容錯(cuò)保護(hù)，保證系統(tǒng)的穩(wěn)定性。
1、熔斷模式：熔斷模式原理類似于電路熔斷器，當(dāng)電路發(fā)生短路時(shí)，熔斷器熔斷，保護(hù)電路避免遭受災(zāi)難性損失。當(dāng)服務(wù)異?；蛘叽罅垦訒r(shí)，滿足熔斷條件時(shí)服務(wù)調(diào)用方會(huì)主動(dòng)啟動(dòng)熔斷，執(zhí)行fallback邏輯直接返回，不會(huì)繼續(xù)調(diào)用服務(wù)進(jìn)一步拖垮系統(tǒng)。熔斷器默認(rèn)配置服務(wù)調(diào)用錯(cuò)誤率閥值為50%，超過(guò)閥值將自動(dòng)啟動(dòng)熔斷模式。服務(wù)隔離一段時(shí)間以后，熔斷器會(huì)進(jìn)入半熔斷狀態(tài)，即允許少量請(qǐng)求進(jìn)行嘗試，如果仍然調(diào)用失敗，則回到熔斷狀態(tài)，如果調(diào)用成功，則關(guān)閉熔斷模式。
2、隔離模式：Hystrix默認(rèn)采用線程隔離，不同的服務(wù)使用不同的線程池，彼此之間不受影響，當(dāng)一個(gè)服務(wù)出現(xiàn)故障耗盡它的線程池資源，其他的服務(wù)正常運(yùn)行不受影響，達(dá)到隔離的效果。例如我們通過(guò)andThreadPoolKey配置某個(gè)服務(wù)使用命名為TestThreadPool的線程池，實(shí)現(xiàn)與其他命名的線程池隔離。
3、回退（fallback）：fallback機(jī)制其實(shí)是一種服務(wù)故障時(shí)的容錯(cuò)方式，原理類似Java中的異常處理。只需要繼承HystixCommand并重寫getFallBack()方法，在此方法中編寫處理邏輯，比如可以直接拋異常（快速失?。?，可以返回空值或缺省值，也可以返回備份數(shù)據(jù)等。當(dāng)服務(wù)調(diào)用出現(xiàn)異常時(shí)，會(huì)轉(zhuǎn)向執(zhí)行g(shù)etFallBack()。有以下幾種情況會(huì)觸發(fā)fallback：
1）程序拋出非HystrixBadRequestExcepption異常，當(dāng)拋出HystrixBadRequestExcepption異常時(shí)，調(diào)用程序可以捕獲異常，沒(méi)有觸發(fā)fallback，當(dāng)拋出其他異常時(shí)，會(huì)觸發(fā)fallback；
2）程序運(yùn)行超時(shí)；
3）熔斷啟動(dòng)；
4）線程池已滿。
4、限流：限流是指對(duì)服務(wù)的并發(fā)訪問(wèn)量進(jìn)行限制，設(shè)置單位時(shí)間內(nèi)的并發(fā)數(shù)，超出限制的請(qǐng)求拒絕并fallback，防止后臺(tái)服務(wù)被沖垮。
Hystix使用命令模式HystrixCommand包裝依賴調(diào)用邏輯，這樣相關(guān)的調(diào)用就自動(dòng)處于Hystrix的彈性容錯(cuò)保護(hù)之下。調(diào)用程序需要繼承HystrixCommand并將調(diào)用邏輯寫在run()中，使用execute()（同步阻塞）或queue()（異步非阻塞）來(lái)觸發(fā)執(zhí)行run()。
動(dòng)態(tài)配置中心
微服務(wù)有很多依賴配置，某些配置參數(shù)在服務(wù)運(yùn)行期間可能還要?jiǎng)討B(tài)修改，比如：根據(jù)訪問(wèn)流量動(dòng)態(tài)調(diào)整熔斷閥值。傳統(tǒng)的實(shí)現(xiàn)信息配置的方法，比如放在xml、yml等配置文件中，和應(yīng)用一起打包，每次修改都要重新提交代碼、打包構(gòu)建、生成新的鏡像、重新啟動(dòng)服務(wù)，效率太低，這樣顯然是不合理的，因此我們需要搭建一個(gè)動(dòng)態(tài)配置中心服務(wù)支持微服務(wù)動(dòng)態(tài)配置。我們使用Spring Cloud的configserver服務(wù)幫我們實(shí)現(xiàn)動(dòng)態(tài)配置中心的搭建。我們開(kāi)發(fā)的微服務(wù)代碼都存放在git服務(wù)器私有倉(cāng)庫(kù)里面，所有需要?jiǎng)討B(tài)配置的配置文件存放在git服務(wù)器下的configserver（配置中心，也是一個(gè)微服務(wù)）服務(wù)中，部署到Docker容器中的微服務(wù)從git服務(wù)器動(dòng)態(tài)讀取配置文件的信息。當(dāng)本地git倉(cāng)庫(kù)修改代碼后push到git服務(wù)器倉(cāng)庫(kù)，git服務(wù)端hooks(post-receive，在服務(wù)端完成代碼更新后會(huì)自動(dòng)調(diào)用)自動(dòng)檢測(cè)是否有配置文件更新，如果有，git服務(wù)端通過(guò)消息隊(duì)列給配置中心（configserver，一個(gè)部署在容器中的微服務(wù)）發(fā)消息，通知配置中心刷新對(duì)應(yīng)的配置文件。這樣微服務(wù)就能獲取到最新的配置文件信息，實(shí)現(xiàn)動(dòng)態(tài)配置。
以上這些框架或組件是支撐實(shí)施微服務(wù)架構(gòu)的核心，在實(shí)際生產(chǎn)中，我們還會(huì)用到很多其他的組件，比如日志服務(wù)組件、消息服務(wù)組件等等，根據(jù)業(yè)務(wù)需要自行選擇使用。在我們的微服務(wù)架構(gòu)實(shí)施案例中，參考使用了很多Spring Cloud Netflix框架的開(kāi)源組件，主要包括Zuul（服務(wù)網(wǎng)關(guān)）、Eureka（服務(wù)注冊(cè)與發(fā)現(xiàn)）、Hystrix（服務(wù)容錯(cuò)）、Ribbon（客戶端負(fù)載均衡）等。這些優(yōu)秀的開(kāi)源組件，為我們實(shí)施微服務(wù)架構(gòu)提供了捷徑。
以上篇幅主要介紹了微服務(wù)架構(gòu)的基本原理，其中有些比較細(xì)節(jié)的東西，比如Eureka的各項(xiàng)參數(shù)配置說(shuō)明、動(dòng)態(tài)配置中心搭建過(guò)程等，博主會(huì)在其他的文章中做出詳細(xì)的說(shuō)明，供大家參考。
作者 | 風(fēng)中程序猿
來(lái)源 | cnblogs.com/fangfuhai/p/7065847.html
