基于微服務架構的PaaS云平臺架構設計

常秀巖

唐山科技職業技術學院 信息多媒體系 河北 唐山 063000

引言

近年來，微服務架構及容器技術備受關注，在各類文章、演講、博客中頻頻亮相，成為業界最熱門的話題。諸多研發人員開始重新思考互聯網時代服務的架構以及應用開發、運維的方法。微服務以一種全新的架構設計模式，牽動了互聯網應用從設計到運維整個流程方法論的變革。而以Docker為代表的容器技術則為微服務理念提供了匹配的實現機制，進而實質性的改變了新一代應用開發和發布的方式。

1 微服務架構的原理與實施

1.1 微服務架構的原理 微服務架構是一種架構風格和設計模式，提倡將應用分割成一系列細小的服務，每個服務專注于單一業務功能，運行于獨立的進程中，服務之間邊界清晰，采用輕量級通信機制(如HTTP/REST)相互溝通、配合來實現完整的應用，滿足業務和用戶的需求。微服務作為架構模式的變革，其誕生絕非偶然。它是當傳統服務架構在互聯網時代遭遇挑戰時，人們對于架構模式，開發和運維方法論的一種反思。

目前業界比較成熟的微服務框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套實現微服務的框架，它提供了開發微服務所需的組件，在本文的微服務架構設計中，使用了諸多Spring Cloud Netflix框架的組件。其微服務架構的組成及原理如下圖1所示：

圖1 微服務架構的組成及原理

由上圖可知，微服務訪問大致路徑為：外部請求→負載均衡→服務網關(Gate Way)→微服務→數據服務/消息服務。服務網關和微服務都會用到服務注冊和發現來調用依賴的其他服務，各服務集群都能通過配置中心服務來獲得配置信息。

1.2 微服務架構的實施 本文采用亞馬遜EC2作為虛擬云服務器，采用ELB(Elastic Load Balancing)做負載均衡。EC2具有自動配置容量功能，當用戶流量達到尖峰，EC2可以自動增加更多的容量以維持虛擬主機的性能；ELB彈性負載均衡，在多個實例間自動分配應用的傳入流量。為了保證安全性，客戶端請求需要使用https加密保護，這就需要我們進行SSL卸載，使用Nginx對加密請求進行卸載處理，外部請求經過ELB負載均衡后路由到Gate Way集群中的某個Gate Way服務，由Gate Way服務轉發到微服務。

由于微服務架構是由一系列職責單一的細粒度服務構成的網狀結構，服務之間通過輕量機制進行通信，這就引入了服務注冊與發現的問題，服務的提供方要注冊報告服務地址，服務調用放要能發現目標服務。我們的微服務架構中使用了Eureka組件來實現服務的注冊與發現。所有的微服務(通過配置Eureka服務信息)到Eureka服務器中進行注冊，并定時發送心跳進行健康檢查，Eureka默認配置是30秒發送一次心跳，表明服務仍然處于存活狀態，發送心跳的時間間隔可以通過Eureka的配置參數自行配置，Eureka服務器在接收到服務實例的最后一次心跳后，需要等待90秒(默認配置90秒，可以通過配置參數進行修改)后，才認定服務已經死亡(即連續3次沒有接收到心跳)，在Eureka自我保護模式關閉的情況下會清除該服務的注冊信息。

微服務有很多依賴配置，某些配置參數在服務運行期間可能還要動態修改，比如：根據訪問流量動態調整熔斷閥值。這里我們使用Spring Cloud的configserver服務幫我們實現動態配置中心的搭建。

2 PaaS云平臺架構的設計

2.1 服務網關的設計 服務網關作為內部系統的邊界，應具備以下功能：

(1)動態路由：動態的將請求路由到所需要的后端服務集群。雖然內部是復雜的分布式微服務網狀結構，但是外部系統從網關看就像是一個整體服務，網關屏蔽了后端服務的復雜性。

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

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

(4)監控：網關可以收集有意義的數據和統計，為后臺服務優化提供數據支持。

(5)訪問日志：網關可以收集訪問日志信息，比如訪問的是哪個服務、處理過程出現什么異常和結果、花費多少時間等，通過分析日志內容對后臺系統做進一步的優化。

本文采用Spring Cloud Netflix框架的開源組件Zuul來實現網關服務。Zuul使用一系列不同類型的過濾器，通過重寫過濾器，使我們能夠靈活的實現網關的各種功能。

2.2 微服務的部署 傳統的部署方式，需要在每臺服務器上安裝運行環境，如果我們的服務器數量龐大，在每臺服務器上安裝運行環境將是一項無比繁重的工作，一旦運行環境發生改變，就不得不重新安裝，這簡直是災難性的。微服務是一系列職責單一、細粒度的服務，是將我們的業務進行拆分為獨立的服務單元，伸縮性好，耦合度低，不同的微服務可以用不同的語言開發，每一個服務處理的單一的業務。微服務可以劃分為前端服務和后端服務，前端服務是對后端服務做必要的聚合和剪裁后暴露給外部不同的設備(如PC、Phone等)，所有的服務啟動時都會到Eureka服務器進行注冊，服務之間會有錯綜復雜的依賴關系。本文的Eureka服務器部署架構如下圖2所示：

微服務以鏡像的形式，運行在Docker容器中，Docker容器技術讓我們的服務部署變得簡單、高效。使用Docker容器技術，我們只需要將所需的基礎鏡像和微服務生成一個新的鏡像，將這個最終的鏡像部署在Docker容器中運行，這種方式簡單、高效，能夠快速部署服務。每個Docker容器中可以運行多個微服務，Docker容器以集群的方式部署，使用Docker Swar m對這些容器進行管理。我們創建一個鏡像倉庫用來存放所有的基礎鏡像以及生成的最終交付鏡像，在鏡像倉庫中對所有鏡像進行管理。

圖2 Eureka服務器部署架構圖

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

3 微服務動態配置中心的設計

傳統的實現信息配置的方法，比如放在x ml、y ml等配置文件中和應用一起打包，每次修改都要重新提交代碼、打包構建、生成新的鏡像、重新啟動服務，效率太低，這樣顯然是不合理的，因此我們需要搭建一個動態配置中心服務支持微服務動態配置。

本文使用Spring Cloud的configserver服務幫我們實現動態配置中心的搭建。我們開發的微服務代碼都存放在git服務器私有倉庫里面，所有需要動態配置的配置文件存放在git服務器下的configserver(配置中心)服務中，部署到Docker容器中的微服務從git服務器動態讀取配置文件的信息。當本地git倉庫修改代碼后push到git服務器倉庫，git服務端hooks(post－receive，在服務端完成代碼更新后會自動調用)自動檢測是否有配置文件更新，如果有，git服務端通過消息隊列給配置中心發消息，通知配置中心刷新對應的配置文件。這樣微服務就能獲取到最新的配置文件信息，實現動態配置。

4 結論

本文設計了一套基于微服務架構的PaaS云架構平臺，上述系統框架和組件是支撐實施微服務架構的核心，在實際生產中，我們還會用到很多其他的組件，比如日志服務組件、消息服務組件等等。根據業務需要自行選擇使用，在我們的微服務架構實施案例中，參考使用了很多Spring Cloud Netflix框架的開源組件，主要包括服務網關、服務注冊與發現、服務容錯、客戶端負載均衡等，這些優秀的開源組件，為我們實施微服務架構提供了捷徑。