基於微服務和Docker的PaaS雲平臺架構設計

　　基於微服務架構和Docker容器技術的PaaS雲平臺建設目標是給我們的開發人員提供一套服務快速開發、部署、運維管理、持續開發持續整合的流程。平臺提供基礎設施、中介軟體、資料服務、雲伺服器等資源，開發人員只需要開發業務程式碼並提交到平臺程式碼庫，做一些必要的配置，系統會自動構建、部署，實現應用的敏捷開發、快速迭代。在系統架構上，PaaS雲平臺主要分為微服務架構、Docker容器技術、DveOps三部分，這篇文章重點介紹微服務架構的實施。

　　實施微服務需要投入大量的技術力量來開發基礎設施，這對很多公司來說顯然是不現實的，別擔心，業界已經有非常優秀的開源框架供我們參考使用。目前業界比較成熟的微服務框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基於Spring Boot的一整套實現微服務的框架，它提供了開發微服務所需的元件，跟Spring Boot一起使用的話開發微服務架構的雲服務會變的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我們的微服務架構設計中，就使用了很多Spring Cloud Netflix框架的元件。Spring Cloud Netflix專案的時間還不長，相關的文件資料很少，博主當時研究這套框架啃了很多英文文件，簡直痛苦不堪。對於剛開始接觸這套框架的同學，要搭建一套微服務應用架構，可能會不知道如何下手，接下來介紹我們的微服務架構搭建過程以及需要那些框架或元件來支援微服務架構。

　　為了直接明瞭的展示微服務架構的組成及原理，博主畫了一張系統架構圖，如下：

　　從上圖可以看出，微服務訪問大致路徑為：外部請求 → 負載均衡 → 服務閘道器(GateWay)→ 微服務 → 資料服務/訊息服務。服務閘道器和微服務都會用到服務註冊和發現來呼叫依賴的其他服務，各服務叢集都能透過配置中心服務來獲得配置資訊。

　　服務閘道器(GateWay)

　　閘道器是外界系統(如：客戶端瀏覽器、移動裝置等)和企業內部系統之間的一道門，所有的客戶端請求透過閘道器訪問後臺服務。為了應對高併發訪問，服務閘道器以叢集形式部署，這就意味著需要做負載均衡，我們採用了亞馬遜EC2作為虛擬雲伺服器，採用ELB(Elastic Load Balancing)做負載均衡。EC2具有自動配置容量功能，當使用者流量達到尖峰，EC2可以自動增加更多的容量以維持虛擬主機的效能。ELB彈性負載均衡，在多個例項間自動分配應用的傳入流量。為了保證安全性，客戶端請求需要使用https加密保護，這就需要我們進行SSL解除安裝,使用Nginx對加密請求進行解除安裝處理。外部請求經過ELB負載均衡後路由到GateWay叢集中的某個GateWay服務，由GateWay服務轉發到微服務。服務閘道器作為內部系統的邊界，它有以下基本能力：

　　1、動態路由：動態的將請求路由到所需要的後端服務叢集。雖然內部是複雜的分散式微服務網狀結構，但是外部系統從閘道器看就像是一個整體服務，閘道器遮蔽了後端服務的複雜性。

　　2、限流和容錯：為每種型別的請求分配容量，當請求數量超過閥值時拋掉外部請求，限制流量，保護後臺服務不被大流量沖垮;黨內部服務出現故障時直接在邊界建立一些響應，集中做容錯處理，而不是將請求轉發到內部叢集，保證使用者良好的體驗。

　　3、身份認證和安全性控制：對每個外部請求進行使用者認證，拒絕沒有透過認證的請求，還能透過訪問模式分析，實現反爬蟲功能。

　　4、監控：閘道器可以收集有意義的資料和統計，為後臺服務最佳化提供資料支援。

　　5、訪問日誌：閘道器可以收集訪問日誌資訊，比如訪問的是哪個服務?處理過程(出現什麼異常)和結果?花費多少時間?透過分析日誌內容，對後臺系統做進一步最佳化。

　　我們採用Spring Cloud Netflix框架的開源元件Zuul來實現閘道器服務。Zuul使用一系列不同型別的過濾器(Filter)，透過重寫過濾器，使我們能夠靈活的實現閘道器(GateWay)的各種功能。

　　服務註冊與發現

　　由於微服務架構是由一系列職責單一的細粒度服務構成的網狀結構，服務之間透過輕量機制進行通訊，這就引入了服務註冊與發現的問題，服務的提供方要註冊報告服務地址，服務呼叫放要能發現目標服務。我們的微服務架構中使用了Eureka元件來實現服務的註冊與發現。所有的微服務(透過配置Eureka服務資訊)到Eureka伺服器中進行註冊，並定時傳送心跳進行健康檢查，Eureka預設配置是30秒傳送一次心跳，表明服務仍然處於存活狀態，傳送心跳的時間間隔可以透過Eureka的配置引數自行配置，Eureka伺服器在接收到服務例項的最後一次心跳後，需要等待90秒(預設配置90秒，可以透過配置引數進行修改)後，才認定服務已經死亡(即連續3次沒有接收到心跳)，在Eureka自我保護模式關閉的情況下會清除該服務的註冊資訊。所謂的自我保護模式是指，出現網路分割槽、Eureka在短時間內丟失過多的服務時，會進入自我保護模式，即一個服務長時間沒有傳送心跳，Eureka也不會將其刪除。自我保護模式預設為開啟，可以透過配置引數將其設定為關閉狀態。

　　Eureka服務以叢集的方式部署(在博主的另一篇文章中詳細介紹了Eureka叢集的部署方式)，叢集內的所有Eureka節點會定時自動同步微服務的註冊資訊，這樣就能保證所有的Eureka服務註冊資訊保持一致。那麼在Eureka叢集裡，Eureka節點是如何發現其他節點的呢?我們透過DNS伺服器來建立所有Eureka節點的關聯，在部署Eureka叢集之外還需要搭建DNS伺服器。

　　當閘道器服務轉發外部請求或者是後臺微服務之間相互呼叫時，會去Eureka伺服器上查詢目標服務的註冊資訊，發現目標服務並進行呼叫，這樣就形成了服務註冊與發現的整個流程。Eureka的配置引數數量很多，多達上百個，博主會在另外的文章裡詳細說明。

　　微服務部署

　　微服務是一系列職責單一、細粒度的服務，是將我們的業務進行拆分為獨立的服務單元，伸縮性好，耦合度低，不同的微服務可以用不同的語言開發，每一個服務處理的單一的業務。微服務可以劃分為前端服務(也叫邊緣服務)和後端服務(也叫中間服務)，前端服務是對後端服務做必要的聚合和剪裁後暴露給外部不同的裝置(PC、Phone等)，所有的服務啟動時都會到Eureka伺服器進行註冊，服務之間會有錯綜複雜的依賴關係。當閘道器服務轉發外部請求呼叫前端服務時，透過查詢服務登錄檔就可以發現目標服務進行呼叫，前端服務呼叫後端服務時也是同樣的道理，一次請求可能涉及到多個服務之間的相互呼叫。由於每個微服務都是以叢集的形式部署，服務之間相互呼叫的時候需要做負載均衡，因此每個服務中都有一個LB元件用來實現負載均衡。

　　微服務以映象的形式，執行在Docker容器中。Docker容器技術讓我們的服務部署變得簡單、高效。傳統的部署方式，需要在每臺伺服器上安裝執行環境，如果我們的伺服器數量龐大，在每臺伺服器上安裝執行環境將是一項無比繁重的工作，一旦執行環境發生改變，就不得不重新安裝，這簡直是災難性的。而使用Docker容器技術，我們只需要將所需的基礎映象(jdk等)和微服務生成一個新的映象，將這個最終的映象部署在Docker容器中執行，這種方式簡單、高效，能夠快速部署服務。每個Docker容器中可以執行多個微服務，Docker容器以叢集的方式部署，使用Docker Swarm對這些容器進行管理。我們建立一個映象倉庫用來存放所有的基礎映象以及生成的最終交付映象，在映象倉庫中對所有映象進行管理。

　　服務容錯

　　微服務之間存在錯綜複雜的依賴關係，一次請求可能會依賴多個後端服務，在實際生產中這些服務可能會產生故障或者延遲，在一個高流量的系統中，一旦某個服務產生延遲，可能會在短時間內耗盡系統資源，將整個系統拖垮，因此一個服務如果不能對其故障進行隔離和容錯，這本身就是災難性的。我們的微服務架構中使用了Hystrix元件來進行容錯處理。Hystrix是Netflix的一款開源元件，它透過熔斷模式、隔離模式、回退(fallback)和限流等機制對服務進行彈性容錯保護，保證系統的穩定性。

　　1、熔斷模式：熔斷模式原理類似於電路熔斷器，當電路發生短路時，熔斷器熔斷，保護電路避免遭受災難性損失。當服務異常或者大量延時，滿足熔斷條件時服務呼叫方會主動啟動熔斷，執行fallback邏輯直接返回，不會繼續呼叫服務進一步拖垮系統。熔斷器預設配置服務呼叫錯誤率閥值為50%，超過閥值將自動啟動熔斷模式。服務隔離一段時間以後，熔斷器會進入半熔斷狀態，即允許少量請求進行嘗試，如果仍然呼叫失敗，則回到熔斷狀態，如果呼叫成功，則關閉熔斷模式。

　　2、隔離模式：Hystrix預設採用執行緒隔離，不同的服務使用不同的執行緒池，彼此之間不受影響，當一個服務出現故障耗盡它的執行緒池資源，其他的服務正常執行不受影響，達到隔離的效果。例如我們透過andThreadPoolKey配置某個服務使用命名為TestThreadPool的執行緒池，實現與其他命名的執行緒池隔離。

　　3、回退(fallback)：fallback機制其實是一種服務故障時的容錯方式，原理類似Java中的異常處理。只需要繼承HystixCommand並重寫getFallBack()方法，在此方法中編寫處理邏輯，比如可以直接拋異常(快速失敗)，可以返回空值或預設值，也可以返回備份資料等。當服務呼叫出現異常時，會轉向執行getFallBack()。有以下幾種情況會觸發fallback：

　　1)程式丟擲非HystrixBadRequestExcepption異常，當丟擲HystrixBadRequestExcepption異常時，呼叫程式可以捕獲異常，沒有觸發fallback，當丟擲其他異常時，會觸發fallback;

　　2)程式執行超時;

　　3)熔斷啟動;

　　4)執行緒池已滿。

　　4、限流： 限流是指對服務的併發訪問量進行限制，設定單位時間內的併發數，超出限制的請求拒絕並fallback，防止後臺服務被沖垮。

　　Hystix使用命令模式HystrixCommand包裝依賴呼叫邏輯，這樣相關的呼叫就自動處於Hystrix的彈性容錯保護之下。呼叫程式需要繼承HystrixCommand並將呼叫邏輯寫在run()中，使用execute()(同步阻塞)或queue()(非同步非阻塞)來觸發執行run()。

　　動態配置中心

　　微服務有很多依賴配置，某些配置引數在服務執行期間可能還要動態修改，比如：根據訪問流量動態調整熔斷閥值。傳統的實現資訊配置的方法，比如放在xml、yml等配置檔案中，和應用一起打包，每次修改都要重新提交程式碼、打包構建、生成新的映象、重新啟動服務，效率太低，這樣顯然是不合理的，因此我們需要搭建一個動態配置中心服務支援微服務動態配置。我們使用Spring Cloud的configserver服務幫我們實現動態配置中心的搭建。我們開發的微服務程式碼都存放在git伺服器私有倉庫裡面，所有需要動態配置的配置檔案存放在git伺服器下的configserver(配置中心，也是一個微服務)服務中，部署到Docker容器中的微服務從git伺服器動態讀取配置檔案的資訊。當本地git倉庫修改程式碼後push到git伺服器倉庫，git服務端hooks(post-receive，在服務端完成程式碼更新後會自動呼叫)自動檢測是否有配置檔案更新，如果有，git服務端透過訊息佇列給配置中心(configserver，一個部署在容器中的微服務)發訊息，通知配置中心重新整理對應的配置檔案。這樣微服務就能獲取到最新的配置檔案資訊，實現動態配置。

　　以上這些框架或元件是支撐實施微服務架構的核心，在實際生產中，我們還會用到很多其他的元件，比如日誌服務元件、訊息服務元件等等，根據業務需要自行選擇使用。在我們的微服務架構實施案例中，參考使用了很多Spring Cloud Netflix框架的開源元件，主要包括Zuul(服務閘道器)、Eureka(服務註冊與發現)、Hystrix(服務容錯)、Ribbon(客戶端負載均衡)等。這些優秀的開源元件，為我們實施微服務架構提供了捷徑。

　　以上篇幅主要介紹了微服務架構的基本原理，其中有些比較細節的東西，比如Eureka的各項引數配置說明、動態配置中心搭建過程等，博主會在其他的文章中做出詳細的說明，供大家參考。

　　文章作者：風中程式猿
　　原文連結：https://www.cnblogs.com/fangfuhai/p/7065847.html