圖文詳解：如何給女友解釋什麼是微服務？

 

​微服務：微服務是基於分而治之的思想演化出來的。過去傳統的一個大型而又全面的系統，隨着互聯網的發展已經很難知足市場對技術的需求，因而咱們從單獨架構發展到分佈式架構，又從分佈式架構發展到 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容器上使用。