微服務架構是一種架構模式，它可以讓一個應用程式分成一組模組化的服務程式，下面我們稱這些模組化的服務為模組，每個模組之間進行通訊、協助，為使用者提供最終有價值的應用服務。

每個模組服務可以執行在相對獨立的專案中，模組和模組之間採用相對輕量級的通訊機制互相溝通（通常是基於 HTTP 的 RESTful API）。每個模組都圍繞著具體業務進行構建，並且能夠被獨立地部署到不同的生產環境、類生產環境等。另外，應儘量避免統一的、集中式的模組管理機制，對具體的一個模組服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。

現在市面常見的微服務框架主要有：Spring Cloud 和 Dubbo

服務註冊發現

服務註冊發現：服務註冊就是維護一個登記薄，服務註冊就是維護一個登記簿，它管理系統內所有的模組地址。當新的模組啟動後，它會向登記簿傳送自己的地址資訊。模組的呼叫方直接向登記簿要 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容器上使用。