微服務架構：基於微服務和Docker容器技術的PaaS雲平臺架構設計

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

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：854630135，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

實施微服務須要投入大量的技術力量來開發基礎設施，這對不少公司來講顯然是不現實的，別擔憂，業界已經有很是優秀的開源框架供咱們參考使用。目前業界比較成熟的微服務框架有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服務轉發到微服務。服務網關做爲內部系統的邊界，它有如下基本能力：

一、動態路由：動態的將請求路由到所須要的後端服務集羣。雖然內部是複雜的分佈式微服務網狀結構，可是外部系統從網關看就像是一個總體服務，網關屏蔽了後端服務的複雜性。

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

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

四、監控：網關能夠收集有意義的數據和統計，爲後臺服務優化提供數據支持。

五、訪問日誌：網關能夠收集訪問日誌信息，好比訪問的是哪一個服務？處理過程（出現什麼異常）和結果？花費多少時間？經過分析日誌內容，對後臺系統作進一步優化。

咱們採用Spring Cloud Netflix框架的開源組件Zuul來實現網關服務。Zuul使用一系列不一樣類型的過濾器（Filter），經過重寫過濾器，使咱們可以靈活的實現網關（GateWay）的各類功能。

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：854630135，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

服務註冊與發現

因爲微服務架構是由一系列職責單一的細粒度服務構成的網狀結構，服務之間經過輕量機制進行通訊，這就引入了服務註冊與發現的問題，服務的提供方要註冊報告服務地址，服務調用放要能發現目標服務。咱們的微服務架構中使用了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的配置參數數量不少，多達上百個，博主會在另外的文章裏詳細說明。

微服務部署

微服務是一系列職責單1、細粒度的服務，是將咱們的業務進行拆分爲獨立的服務單元，伸縮性好，耦合度低，不一樣的微服務能夠用不一樣的語言開發，每個服務處理的單一的業務。微服務能夠劃分爲前端服務（也叫邊緣服務）和後端服務（也叫中間服務），前端服務是對後端服務作必要的聚合和剪裁後暴露給外部不一樣的設備（PC、Phone等），全部的服務啓動時都會到Eureka服務器進行註冊，服務之間會有錯綜複雜的依賴關係。當網關服務轉發外部請求調用前端服務時，經過查詢服務註冊表就能夠發現目標服務進行調用，前端服務調用後端服務時也是一樣的道理，一次請求可能涉及到多個服務之間的相互調用。因爲每一個微服務都是以集羣的形式部署，服務之間相互調用的時候須要作負載均衡，所以每一個服務中都有一個LB組件用來實現負載均衡。

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

服務容錯

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

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

二、隔離模式：Hystrix默認採用線程隔離，不一樣的服務使用不一樣的線程池，彼此之間不受影響，當一個服務出現故障耗盡它的線程池資源，其餘的服務正常運行不受影響，達到隔離的效果。例如咱們經過andThreadPoolKey配置某個服務使用命名爲TestThreadPool的線程池，實現與其餘命名的線程池隔離。

三、回退（fallback）：fallback機制實際上是一種服務故障時的容錯方式，原理相似Java中的異常處理。只須要繼承HystixCommand並重寫getFallBack()方法，在此方法中編寫處理邏輯，好比能夠直接拋異常（快速失敗），能夠返回空值或缺省值，也能夠返回備份數據等。當服務調用出現異常時，會轉向執行getFallBack()。有如下幾種狀況會觸發fallback：

1）程序拋出非HystrixBadRequestExcepption異常，當拋出HystrixBadRequestExcepption異常時，調用程序能夠捕獲異常，沒有觸發fallback，當拋出其餘異常時，會觸發fallback；

2）程序運行超時；

3）熔斷啓動；

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（客戶端負載均衡）等。這些優秀的開源組件，爲咱們實施微服務架構提供了捷徑。

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：854630135，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。