微服務：微服務是基於分而治之的思想演化出來的。過去傳統的一個大型而又全面的系統，隨著網際網路的發展已經很難滿足市場對技術的需求，於是我們從單獨架構發展到分散式架構，又從分散式架構發展到 SOA 架構，服務不斷的被拆分和分解，粒度也越來越小，直到微服務架構的誕生。
微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。
每個服務執行在其獨立的程式中，服務和服務間採用輕量級的通訊機制互相溝通（通常是基於 HTTP 的 RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。
現在市面常見的微服務框架主要有：Spring Cloud 和 Dubb
服務註冊發現
服務註冊發現：服務註冊就是維護一個登記薄，服務註冊就是維護一個登記簿，它管理系統內所有的服務地址。當新的服務啟動後，它會向登記 簿交待自己的地址資訊。服務的依賴方直接向登記簿要 Service Provider 地址就行了。當下用於服務註冊的工具非常多 ZooKeeper，Consul，Etcd, 還有 Netflix 家的 eureka 等。服務註冊有兩種形式：客戶端註冊和第三方註冊.
服務註冊（zookeeper）
服務註冊是服務自身要負責註冊與登出的工作。當服務啟動後向註冊中心註冊自身，當服務下線時登出自己。期間還需要和註冊中心保持心跳。心跳不一定要客戶端來做，也可以由註冊中心 負責（這個過程叫探活）。這種方式的缺點是註冊工作與服務耦合在一起，不同語言都要實現一套註冊邏輯。
服務發現
當服務呼叫方呼叫某個服務的時候，可以通過服務的名字去服務註冊發現中心獲取可用的服務，服務發現中心從記憶體的服務列表獲取所有可用的服務，然後負載均衡根據既定的規則選擇一個服務將 HTTP 服務 ip port 返回給呼叫方，如果是grpc服務，從連線池獲取該服務的連線返回給呼叫方。
API閘道器
API閘道器：API閘道器是一個伺服器，是系統的唯一入口。從物件導向設計的角度看，它與外觀模式類似。API閘道器封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、快取、請求分片與管理、靜態響應處理。
API Gateway 負責請求轉發、合成和協議轉換。所有來自客戶端的請求都要先經過 API Gateway，然後路由這些請求到對應的微服務。API Gateway 將經常通過呼叫多個微服務來處理一個請求以及聚合多個服務的結果。它可以在 web 協議與內部使用的非 Web 友好型協議間進行轉換，如HTTP 協議、WebSocket 協議。
API閘道器方式的核心要點是，所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。通常，閘道器也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。
請求轉發
服務轉發主要是對客戶端的請求安裝微服務的負載轉發到不同的服務上。
相應合併
把業務上需要呼叫多個服務介面才能完成的工作合併成一次呼叫對外統一提供服務。
協議轉換
重點是支援 SOAP、JMS比如 Rest 間的協議轉換。
資料轉換
重點是支援 XML 和 Json 之間的報文格式轉換能力（可選）。
安全認證
•基於 Token 的客戶端訪問控制和安全策略；•傳輸資料和報文加密，到服務端解密，需要在客戶端有獨立的 SDK 代理包；•基於 Https 的傳輸加密，客戶端和服務端數字證書支援；•基於 OAuth2.0 的服務安全認證(授權碼，客戶端，密碼模式等）。
配置中心
配置中心：配置中心一般用作系統的引數配置，它需要滿足如下幾個要求：高效獲取、實時感知、分散式訪問。
zookeeper 配置中心
實現的架構圖如下所示，採取資料載入到記憶體方式解決高效獲取的問題，藉助 zookeeper 的節點監聽機制來實現實時感知。
配置中心資料分類
事件排程（kafka）
訊息服務和事件的統一排程，常用用 kafka ，activemq 等。
服務跟蹤（starter-sleuth）
隨著微服務數量不斷增長，需要跟蹤一個請求從一個微服務到下一個微服務的傳播過程， Spring Cloud Sleuth 正是解決這個問題，它在日誌中引入唯一 ID，以保證微服務呼叫之間的一致性，這樣你就能跟蹤某個請求是如何從一個微服務傳遞到下一個。
•為了實現請求跟蹤，當請求傳送到分散式系統的入口端點時，只需要服務跟蹤框架為該請求建立一個唯一的跟蹤標識，同時在分散式系統內部流轉的時候，框架始終保持傳遞該唯一標 識，直到返回給請求方為止，這個唯一標識就是前文中提到的 Trace ID。通過 Trace ID 的記錄，我們就能將所有請求過程日誌關聯起來；
•為了統計各處理單元的時間延遲，當請求達到各個服務元件時，或是處理邏輯到達某個狀態時，也通過一個唯一標識來標記它的開始、具體過程以及結束，該標識就是我們前文中提到的 Span ID，對於每個 Span 來說，它必須有開始和結束兩個節點，通過記錄開始 Span 和結束 Span 的時間戳，就能統計出該 Span 的時間延遲，除了時間戳記錄之外，它還可以包含一些其他後設資料，比如：事件名稱、請求資訊等；
•在 Spring Boot 應用中，通過在工程中引入 spring-cloudstarter-sleuth 依賴之後， 它會自動的為當前應用構建起各通訊通道的跟蹤機制，比如：
•通過諸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 繫結器實現的訊息中介軟體）傳遞的請求。•通過 Zuul 代理傳遞的請求。•通過 RestTemplate 發起的請求。
服務熔斷（Hystrix）
服務熔斷：在微服務架構中通常會有多個服務層呼叫，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。
熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以後的多個呼叫快速失敗，不再訪問遠端伺服器，從而防止應用程式不斷地嘗試執行可能會失敗的操作，使得應用程式繼續執行而不用等待修正錯誤，或者浪費 CPU時間去等到長時間的超時產生。熔斷器也可以使應用程式能夠診斷錯誤是否已經修正，如果已經修正，應用程式會再次嘗試呼叫操作。
Hystrix 斷路器機制
斷路器很好理解, 當 Hystrix Command 請求後端服務失敗數量超過一定比例(預設 50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會傳送到後端服務. 斷路器保持在開路狀態一段時間後(預設 5 秒), 自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回情況, 如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN). Hystrix 的斷路器就像我們家庭電路中的保險絲, 一旦後端服務不可用, 斷路器會直接切斷請求鏈, 避免傳送大量無效請求影響系統吞吐量, 並且斷路器有自我檢測並恢復的能力。
API管理
SwaggerAPI 管理工具
SwaggerAPI管理工具：官網地址：https://swagger.io Swagger 是一款RESTFUL介面的文件線上自動生成+功能測試功能軟體，是一個規範和完整的框架，標準的，語言無關，用於生成、描述、呼叫和視覺化 RESTful 風格的 Web 服務。總體目標是使客戶端和檔案系統作為伺服器以同樣的速度來更新。檔案的方法，引數和模型緊密整合到伺服器端的程式碼，允許API來始終保持同步。Swagger 讓部署管理和使用功能強大的API從未如此簡單。
目前最新版本是V3，SwaggerUI是一個簡單的Restful API 測試和文件工具。簡單、漂亮、易用。通過讀取JSON 配置顯示API. 專案本身僅僅也只依賴一些 html,css.js靜態檔案. 你可以幾乎放在任何Web容器上使用。
