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