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的廣播機制在分佈式系統中傳播消息。
- 提交代碼或變更配置觸發post請求給bus/refresh
- server端接受請求併發送給Bus
- Bus接到消息後通知給客戶端
- 客戶端收到通知後，請求server獲取最新配置
- 全部客戶端更新配置
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、消息隊列
11、分佈式日誌系統——ELK
ElK，即ElasticSearch+Logstash+Kibana。
- ElasticSearch是一個基於Lucene的開源分佈式搜索服務器。它的特點有：分佈式，零配置，自動發現，索引自動分片，索引副本機制，restful風格接口，多數據源，自動搜索負載等。它提供了一個分佈式多用戶能力的全文搜索引擎，基於RESTful web接口。設計用於雲計算中，能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。
- Logstash是一個完全開源的工具，它可以對日誌進行收集、過濾、分析，支持大量的數據獲取方法，並將其存儲供以後使用（如搜索）。一般工作方式爲c/s架構，client端安裝在需要收集日誌的主機上，server端負責將收到的各節點日誌進行過濾、修改等操作再一併發往elasticsearch上去。
- Kibana是一個基於瀏覽器頁面的Elasticsearch前端展示工具，可以爲 Logstash 和 ElasticSearch 提供日誌分析友好的 Web 界面。
- 每臺服務器集羣節點安裝Logstash日誌收集系統插件，將日誌輸入到Logstash中
- Logstash將該日誌格式化爲json格式，根據每天創建不同的索引，輸出到ElasticSearch中
- 另外，zipkin的流也可以直接傳給ElasticSearch，便於運維管理和分析
- 瀏覽器使用安裝Kibana查詢日誌信息
12、分佈式事務
由於在微服務架構中，不同的業務集羣維護各自獨立的數據庫，互相之間數據不互通，調用也只是接口的調用，再加上網絡環境的不穩定性，分佈式事務的一致性就顯得非常重要。
常見的分佈式事務解決方案有：
- 兩階段提交
- 補償事務機制
- 本地消息表
- MQ事務消息
13、分佈式緩存——Redis
Redis可以用來做分佈式系統Session共享，同時，Redis做二級緩存對降低整個服務響應時間、減少數據庫訪問次數也有幫助，可選Redis Cluster（集羣模式）和Redis Sentinel（哨兵模式）。
