1、技術架構

2、元件介紹

1、服務註冊與發現——Eureka

服務註冊與發現中心採用Eureka，以AP為核心的高可用註冊中心，保證高可用性和最終一致性，server之間互相註冊的replicate機制可以單點註冊、全域性感知，通過叢集式部署來避免單點故障導致服務不可用。

提供雲端服務發現，一個基於Rest的服務，用於定位服務，以實現雲端中間層的服務發現和故障轉移。

主要用來實現服務治理，統一管理眾多微服務應用的地址資訊，以及複雜的呼叫關係，減少應用之間的耦合，通過提供服務方在Eureka Server註冊服務，服務消費方在Server上訂閱所需服務得到提供者的地址資訊，完成一次服務之間的請求呼叫。

由Eureka Server和Eureka Client組成，Eureka Server用作註冊中心，支援叢集部署；Eureka Client是一個Java客戶端，用來處理服務註冊與發現。

2、服務閘道器——Spring Cloud GateWay

Spring Cloud GateWay作為Spring Cloud生態系統中的閘道器，旨在為微服務架構提供一種簡單有效的統一的API路由管理方式，並且基於Filter鏈的方式提供了閘道器基本的功能，如：安全、授權、監控/指標、限流等。

GateWay特徵有：動態路由、基於HTTP請求的路由匹配、Predicates和Filters作用於特定路由、整合Hystrix熔斷器、易於編寫的Predicates和Filters、限流、路徑重寫、與服務註冊發現元件結合根據serviceId轉發。

重要的概念

• 過濾器：用於攔截和鏈式處理web請求，實現橫切的、與應用無關的需求。可在代理請求處理之前（pre）執行，也可以在請求之後（post）執行。pre型別過濾器可以做引數校驗、許可權校驗、流量監控、日誌輸出、協議轉換等；post型別過濾器可以做響應內容、響應頭的修改、日誌輸出、流量監控等。過了pre和post的區分，根據作用範圍還可以分為針對單個路由的gateway filter和針對所有路由的global gateway filter。
• Predicate：在將web請求和路由進行匹配時，用到的就是predicate，決定請求走哪一個路由。GateWay內建了多種型別的Predicate。

請求時，客戶端向GateWay發起請求，如果在GateWay Handler Mapping中找到與請求相匹配的路由(此處用到Predicate)，將其傳送到GateWay Web Handler，Handler再通過指定的過濾鏈來將請求傳送到實際的服務執行業務邏輯，然後返回。期間，過濾器可能在傳送代理請求之前（pre過濾器）或之後（post過濾器）執行。

GateWay基於Webflux，支援非同步非阻塞程式設計。

3、服務呼叫——Ribbon + Hystrix + Feign

一次服務呼叫請求過程，提供某個服務的應用可能有多個（叢集部署），消費方需要從中選擇一個進行呼叫，即客戶端負載均衡技術，Ribbon主要提供客戶端的軟體負載均衡演算法。

Ribbon支援許多常見的負載均衡策略，同時也支援自定義負載均衡策略。

 

Hystrix的主要作用是熔斷器，控制故障範圍，是一個容錯管理工具，通過熔斷機制控制服務和第三方庫的節點，對延遲和故障提供更強大的容錯能力。

由於網路分割槽環境的複雜性，通常服務不能保證100%的可用性，如果某個服務出現故障，呼叫該服務就會出現執行緒阻塞，此時若有大量請求湧入，執行緒資源耗盡後造成服務癱瘓。而由於服務之間的呼叫依賴性，故障會快速在服務群中擴散，嚴重時導致大量微服務不可用，這就是服務故障的“雪崩 ”效應。

Hystrix可以在服務故障時攔截請求，快速返回錯誤資訊，同時自動探測服務狀態以便後續恢復服務請求，另外也支援實現服務降級機制，可以顯著增加整個分散式系統的健壯性和穩定性。

 

Feign是一個宣告式的Web服務客戶端，支援可插入註釋、可插拔編碼解碼器，以及Ribbon的負載均衡、Hystrix和它的fallback和HTTP請求和響應的壓縮。

將對Rest服務請求封裝成介面形式，以呼叫本地介面的形式呼叫遠端Rest服務，對開發更加直觀友好。

Feign通過編寫簡單的介面和插入註解，Feign就會根據自定義的HTTP請求的引數、格式、地址等資訊，來完全代理HTTP請求，通過呼叫介面就可以完成服務請求。

4、業務叢集——SpringBoot + SpringMVC

Spring Cloud基於SpringBoot工程構建，利用SpringBoot可以快速開發單個微服務應用。

通過SpringMVC的相關注解可以對外暴露Rest服務。

5、服務配置中心——Spring Cloud Config

 隨著微服務規模的增大，以及生產、測試等環境隔離的要求，由每個微服務應用單獨維護各自的配置資訊會非常混亂，而且每次配置資訊的變更都需要應用的重啟才能生效，因此需要一個分散式配置中心，提供統一的配置資訊管理。

Spring Cloud中的分散式配置中心元件Spring Cloud Config，支援配置資訊放在配置伺服器本地，也支援存放在遠端Git倉庫中，集中化管理叢集配置，可以分為兩個角色，Config Server和Config Client。

Config Server儲存配置資訊在本地或遠端倉庫中，然後對外發布配置服務，將配置資訊服務化；Config Client通過訪問Config Server提供的服務介面，獲取相關的配置資訊來完成自身的應用初始化。

為了避免單點故障，同樣可以部署成叢集模式。

同樣另一個問題，由配置中心統一管理，配置資訊變更時，無需重啟應用，就可以做到配置資訊實時更新生效。

6、訊息匯流排——Bus

Spring Cloud Bus通過輕量的訊息代理連線各個分佈的節點，稱為事件、訊息匯流排，用於在叢集中傳播狀態變化，可以與Spring Cloud Config聯合使用實現配置資訊熱部署。主要功能有兩點：

• 對指定主題的訊息進行訂閱和釋出
• 事件監聽，包括重新整理事件、環境變更事件、遠端應用的ack事件以及本地服務端傳送事件等。

其本質是利用了MQ的廣播機制在分散式系統中傳播訊息。

1. 提交程式碼或變更配置觸發post請求給bus/refresh
2. server端接受請求併發送給Bus
3. Bus接到訊息後通知給客戶端
4. 客戶端收到通知後，請求server獲取最新配置
5. 全部客戶端更新配置

7、認證、授權、安全——spring cloud security + OAuth2 + JWT

Spring Security是一個強大的、高度可定製化的身份驗證和訪問控制框架，兩個主要目標就是 認證 和 授權，一般為先認證身份，然後進行授權。

 

認證協議——JWT。基本思路就是使用者提供使用者名稱和密碼給認證伺服器，伺服器驗證使用者提交資訊的合法性，驗證成功返回一個Token，使用者用這個Token訪問伺服器上受保護的資源。JWT的宣告一般被用來在身份提供者和服務提供者間傳遞被認證的使用者身份資訊，以便於從資源伺服器獲取資源，也可以增加一些額外的其它業務邏輯所必須的宣告資訊，該token也可直接被用於認證，也可被加密。

授權框架——OAuth2。OAuth允許使用者提供一個令牌，而不是使用者名稱和密碼，每一個令牌授權一個特定的第三方應用在特定的時段內訪問特定的資源。

8、鏈路跟蹤——zipkin(spring cloud sleuth)

隨著系統和微服務應用的增多，一個業務可能需要多個微服務協同完成，鏈路上任何一個應用的服務出現問題都會導致業務失敗，需要快速跟蹤故障位置。

Spring Cloud Sleuth，主要功能是在分散式系統中提供追蹤解決方案，並且相容支援zipkin、HTrace和log-base追蹤。

服務追蹤從客戶都拿發起請求到達被追蹤系統邊界開始，到被追蹤系統向客戶返回響應結束，稱為一次trace；在trace過程每次呼叫服務時，埋入一個呼叫記錄（"span"），再附帶上響應時間和請求成功與否等資訊，這樣，若干有序的span就組成了一個trace。

Sleuth為服務之間呼叫提供鏈路跟蹤，可以做到理清服務間呼叫關係；耗時分析；視覺化錯誤（藉助zipkin）；鏈路優化。

結合zipkin，將資料發到zipkin，進行資料視覺化，展示微服務呼叫請求鏈、錯誤資訊視覺化。可以直觀地看到一次請求經過了那些微服務，以及每個服務的耗時，在請求失敗時可以快速定位到請求鏈中哪一環出了問題。

9、監控中心——Turbine、Dashboard + Spring Boot Admin

首先介紹兩個Hystrix監控工具：

• Hystrix Dashboard是一個針對Hystrix進行實時監控的工具，可以直觀地看到各個Hystrix Command的請求響應時間、請求成功率等。
• Dashboard只能看到單個應用內的服務資訊，Hystrix Turbine可以聚合監控系統內多個服務的資料。由於分散式系統中服務通常叢集部署，Turbine可以把多個相同服務的節點狀態聚合為一個數據源，以一個整體叢集的形式供Dashboard展示。

Actuator時Spring Boot提供的對應用系統的自省和監控的整合功能，可以檢視應用配置的詳細資訊等，為了保證Actuator暴露的監控介面的安全性，需要新增安全管理的Security依賴。

Actuator監控分為原生端點和使用者自定義端點兩類，可以觀察應用執行期間的各種效能指標和內部狀況。

Spring Boot Admin：

由於使用Actuator監控，需要對每個應用單獨呼叫固定的介面來進行監控，而且返回資料均為json資料。

Spring Boot Admin是一個開源社群專案，用於管理和監控SpringBoot應用程式。應用程式作為Spring Boot Admin Client向為Spring Boot Admin Server註冊（通過HTTP）或使用SpringCloud註冊中心（例如Eureka，Consul，Zookeeper）發現。 在前端介面展示Admin Client的Actuator端點上的一些監控資訊。

提供了安全登入介面的元件，並且和Spring Boot Security相結合，提供安全登入功能。

Spring Boot Admin Server中還可以整合Turbine元件，讓Turbine中展示的內容整合到Admin Server中，和應用例項一起監控，方便檢視和管理。

10、訊息佇列——Kfaka

11、分散式日誌系統——ELK

ElK，即ElasticSearch+Logstash+Kibana。

• ElasticSearch是一個基於Lucene的開源分散式搜尋伺服器。它的特點有：分散式，零配置，自動發現，索引自動分片，索引副本機制，restful風格介面，多資料來源，自動搜尋負載等。它提供了一個分散式多使用者能力的全文搜尋引擎，基於RESTful web介面。設計用於雲端計算中，能夠達到實時搜尋，穩定，可靠，快速，安裝使用方便。
• Logstash是一個完全開源的工具，它可以對日誌進行收集、過濾、分析，支援大量的資料獲取方法，並將其儲存供以後使用（如搜尋）。一般工作方式為c/s架構，client端安裝在需要收集日誌的主機上，server端負責將收到的各節點日誌進行過濾、修改等操作再一併發往elasticsearch上去。
• Kibana是一個基於瀏覽器頁面的Elasticsearch前端展示工具，可以為 Logstash 和 ElasticSearch 提供日誌分析友好的 Web 介面。

1. 每臺伺服器叢集節點安裝Logstash日誌收集系統外掛，將日誌輸入到Logstash中
2. Logstash將該日誌格式化為json格式，根據每天建立不同的索引，輸出到ElasticSearch中
3. 另外，zipkin的流也可以直接傳給ElasticSearch，便於運維管理和分析
4. 瀏覽器使用安裝Kibana查詢日誌資訊

12、分散式事務

 由於在微服務架構中，不同的業務叢集維護各自獨立的資料庫，互相之間資料不互通，呼叫也只是介面的呼叫，再加上網路環境的不穩定性，分散式事務的一致性就顯得非常重要。

常見的分散式事務解決方案有：

• 兩階段提交
• 補償事務機制
• 本地訊息表
• MQ事務訊息

13、分散式快取——Redis

Redis可以用來做分散式系統Session共享，同時，Redis做二級快取對降低整個服務響應時間、減少資料庫訪問次數也有幫助，可選Redis Cluster（叢集模式）和Redis Sentinel（哨兵模式）。

相關推薦