圖文詳解：如何給女朋友解釋什么是微服務(wù)？

微服務(wù)：微服務(wù)是基于分而治之的思想演化出來的。過去傳統(tǒng)的一個(gè)大型而又全面的系統(tǒng)，隨著互聯(lián)網(wǎng)的發(fā)展已經(jīng)很難滿足市場(chǎng)對(duì)技術(shù)的需求，于是我們從單獨(dú)架構(gòu)發(fā)展到分布式架構(gòu)，又從分布式架構(gòu)發(fā)展到 SOA 架構(gòu)，服務(wù)不斷的被拆分和分解，粒度也越來越小，直到微服務(wù)架構(gòu)的誕生。

微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。

每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)和服務(wù)間采用輕量級(jí)的通信機(jī)制互相溝通（通常是基于 HTTP 的 RESTful API）。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對(duì)其進(jìn)行構(gòu)建。

現(xiàn)在市面常見的微服務(wù)框架主要有：Spring Cloud 和 Dubbo

服務(wù)注冊(cè)發(fā)現(xiàn)

服務(wù)注冊(cè)發(fā)現(xiàn)：服務(wù)注冊(cè)就是維護(hù)一個(gè)登記薄，服務(wù)注冊(cè)就是維護(hù)一個(gè)登記簿，它管理系統(tǒng)內(nèi)所有的服務(wù)地址。當(dāng)新的服務(wù)啟動(dòng)后，它會(huì)向登記 簿交待自己的地址信息。服務(wù)的依賴方直接向登記簿要 Service Provider 地址就行了。當(dāng)下用于服務(wù)注冊(cè)的工具非常多 ZooKeeper，Consul，Etcd, 還有 Netflix 家的 eureka 等。服務(wù)注冊(cè)有兩種形式：客戶端注冊(cè)和第三方注冊(cè).

服務(wù)注冊(cè)（zookeeper）

服務(wù)注冊(cè)是服務(wù)自身要負(fù)責(zé)注冊(cè)與注銷的工作。當(dāng)服務(wù)啟動(dòng)后向注冊(cè)中心注冊(cè)自身，當(dāng)服務(wù)下線時(shí)注銷自己。期間還需要和注冊(cè)中心保持心跳。心跳不一定要客戶端來做，也可以由注冊(cè)中心 負(fù)責(zé)（這個(gè)過程叫探活）。這種方式的缺點(diǎn)是注冊(cè)工作與服務(wù)耦合在一起，不同語言都要實(shí)現(xiàn)一套注冊(cè)邏輯。

服務(wù)發(fā)現(xiàn)

當(dāng)服務(wù)調(diào)用方調(diào)用某個(gè)服務(wù)的時(shí)候，可以通過服務(wù)的名字去服務(wù)注冊(cè)發(fā)現(xiàn)中心獲取可用的服務(wù)，服務(wù)發(fā)現(xiàn)中心從內(nèi)存的服務(wù)列表獲取所有可用的服務(wù)，然后負(fù)載均衡根據(jù)既定的規(guī)則選擇一個(gè)服務(wù)將 HTTP 服務(wù) ip port 返回給調(diào)用方，如果是grpc服務(wù)，從連接池獲取該服務(wù)的連接返回給調(diào)用方。

API網(wǎng)關(guān)

API網(wǎng)關(guān)：API網(wǎng)關(guān)是一個(gè)服務(wù)器，是系統(tǒng)的唯一入口。從面向?qū)ο笤O(shè)計(jì)的角度看，它與外觀模式類似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個(gè)客戶端提供一個(gè)定制的API。它可能還具有其它職責(zé)，如身份驗(yàn)證、監(jiān)控、負(fù)載均衡、緩存、請(qǐng)求分片與管理、靜態(tài)響應(yīng)處理。

API Gateway 負(fù)責(zé)請(qǐng)求轉(zhuǎn)發(fā)、合成和協(xié)議轉(zhuǎn)換。所有來自客戶端的請(qǐng)求都要先經(jīng)過 API Gateway，然后路由這些請(qǐng)求到對(duì)應(yīng)的微服務(wù)。API Gateway 將經(jīng)常通過調(diào)用多個(gè)微服務(wù)來處理一個(gè)請(qǐng)求以及聚合多個(gè)服務(wù)的結(jié)果。它可以在 web 協(xié)議與內(nèi)部使用的非 Web 友好型協(xié)議間進(jìn)行轉(zhuǎn)換，如HTTP 協(xié)議、WebSocket 協(xié)議。

API網(wǎng)關(guān)方式的核心要點(diǎn)是，所有的客戶端和消費(fèi)端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪問API。服務(wù)端通過API-GW注冊(cè)和管理服務(wù)。

請(qǐng)求轉(zhuǎn)發(fā)

服務(wù)轉(zhuǎn)發(fā)主要是對(duì)客戶端的請(qǐng)求安裝微服務(wù)的負(fù)載轉(zhuǎn)發(fā)到不同的服務(wù)上。

相應(yīng)合并

把業(yè)務(wù)上需要調(diào)用多個(gè)服務(wù)接口才能完成的工作合并成一次調(diào)用對(duì)外統(tǒng)一提供服務(wù)。

協(xié)議轉(zhuǎn)換

重點(diǎn)是支持?SOAP、JMS比如?Rest?間的協(xié)議轉(zhuǎn)換。

數(shù)據(jù)轉(zhuǎn)換

重點(diǎn)是支持?XML?和?Json?之間的報(bào)文格式轉(zhuǎn)換能力（可選）。

安全認(rèn)證

?基于 Token 的客戶端訪問控制和安全策略；?傳輸數(shù)據(jù)和報(bào)文加密，到服務(wù)端解密，需要在客戶端有獨(dú)立的 SDK 代理包；?基于 Https 的傳輸加密，客戶端和服務(wù)端數(shù)字證書支持；?基于 OAuth2.0 的服務(wù)安全認(rèn)證(授權(quán)碼，客戶端，密碼模式等）。

配置中心

配置中心：配置中心一般用作系統(tǒng)的參數(shù)配置，它需要滿足如下幾個(gè)要求：高效獲取、實(shí)時(shí)感知、分布式訪問。

zookeeper 配置中心

實(shí)現(xiàn)的架構(gòu)圖如下所示，采取數(shù)據(jù)加載到內(nèi)存方式解決高效獲取的問題，借助 zookeeper 的節(jié)點(diǎn)監(jiān)聽機(jī)制來實(shí)現(xiàn)實(shí)時(shí)感知。

配置中心數(shù)據(jù)分類

事件調(diào)度（kafka）

消息服務(wù)和事件的統(tǒng)一調(diào)度，常用用 kafka ，activemq 等。

服務(wù)跟蹤（starter-sleuth）

隨著微服務(wù)數(shù)量不斷增長(zhǎng)，需要跟蹤一個(gè)請(qǐng)求從一個(gè)微服務(wù)到下一個(gè)微服務(wù)的傳播過程， Spring Cloud Sleuth 正是解決這個(gè)問題，它在日志中引入唯一 ID，以保證微服務(wù)調(diào)用之間的一致性，這樣你就能跟蹤某個(gè)請(qǐng)求是如何從一個(gè)微服務(wù)傳遞到下一個(gè)。

?為了實(shí)現(xiàn)請(qǐng)求跟蹤，當(dāng)請(qǐng)求發(fā)送到分布式系統(tǒng)的入口端點(diǎn)時(shí)，只需要服務(wù)跟蹤框架為該請(qǐng)求創(chuàng)建一個(gè)唯一的跟蹤標(biāo)識(shí)，同時(shí)在分布式系統(tǒng)內(nèi)部流轉(zhuǎn)的時(shí)候，框架始終保持傳遞該唯一標(biāo) 識(shí)，直到返回給請(qǐng)求方為止，這個(gè)唯一標(biāo)識(shí)就是前文中提到的 Trace ID。通過 Trace ID 的記錄，我們就能將所有請(qǐng)求過程日志關(guān)聯(lián)起來；
?為了統(tǒng)計(jì)各處理單元的時(shí)間延遲，當(dāng)請(qǐng)求達(dá)到各個(gè)服務(wù)組件時(shí)，或是處理邏輯到達(dá)某個(gè)狀態(tài)時(shí)，也通過一個(gè)唯一標(biāo)識(shí)來標(biāo)記它的開始、具體過程以及結(jié)束，該標(biāo)識(shí)就是我們前文中提到的 Span ID，對(duì)于每個(gè) Span 來說，它必須有開始和結(jié)束兩個(gè)節(jié)點(diǎn)，通過記錄開始 Span 和結(jié)束 Span 的時(shí)間戳，就能統(tǒng)計(jì)出該 Span 的時(shí)間延遲，除了時(shí)間戳記錄之外，它還可以包含一些其他元數(shù)據(jù)，比如：事件名稱、請(qǐng)求信息等；
?在 Spring Boot 應(yīng)用中，通過在工程中引入 spring-cloudstarter-sleuth 依賴之后， 它會(huì)自動(dòng)的為當(dāng)前應(yīng)用構(gòu)建起各通信通道的跟蹤機(jī)制，比如：
?通過諸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 綁定器實(shí)現(xiàn)的消息中間件）傳遞的請(qǐng)求。?通過 Zuul 代理傳遞的請(qǐng)求。?通過 RestTemplate 發(fā)起的請(qǐng)求。

服務(wù)熔斷（Hystrix）

服務(wù)熔斷：在微服務(wù)架構(gòu)中通常會(huì)有多個(gè)服務(wù)層調(diào)用，基礎(chǔ)服務(wù)的故障可能會(huì)導(dǎo)致級(jí)聯(lián)故障，進(jìn)而造成整個(gè)系統(tǒng)不可用的情況，這種現(xiàn)象被稱為服務(wù)雪崩效應(yīng)。服務(wù)雪崩效應(yīng)是一種因“服務(wù)提供者”的不可用導(dǎo)致“服務(wù)消費(fèi)者”的不可用,并將不可用逐漸放大的過程。

熔斷器的原理很簡(jiǎn)單，如同電力過載保護(hù)器。它可以實(shí)現(xiàn)快速失敗，如果它在一段時(shí)間內(nèi)偵測(cè)到許多類似的錯(cuò)誤，會(huì)強(qiáng)迫其以后的多個(gè)調(diào)用快速失敗，不再訪問遠(yuǎn)程服務(wù)器，從而防止應(yīng)用程序不斷地嘗試執(zhí)行可能會(huì)失敗的操作，使得應(yīng)用程序繼續(xù)執(zhí)行而不用等待修正錯(cuò)誤，或者浪費(fèi) CPU時(shí)間去等到長(zhǎng)時(shí)間的超時(shí)產(chǎn)生。熔斷器也可以使應(yīng)用程序能夠診斷錯(cuò)誤是否已經(jīng)修正，如果已經(jīng)修正，應(yīng)用程序會(huì)再次嘗試調(diào)用操作。

Hystrix 斷路器機(jī)制

斷路器很好理解, 當(dāng)?Hystrix Command?請(qǐng)求后端服務(wù)失敗數(shù)量超過一定比例(默認(rèn) 50%), 斷路器會(huì)切換到開路狀態(tài)(Open). 這時(shí)所有請(qǐng)求會(huì)直接失敗而不會(huì)發(fā)送到后端服務(wù). 斷路器保持在開路狀態(tài)一段時(shí)間后(默認(rèn) 5 秒), 自動(dòng)切換到半開路狀態(tài)(HALF-OPEN). 這時(shí)會(huì)判斷下一次請(qǐng)求的返回情況, 如果請(qǐng)求成功, 斷路器切回閉路狀態(tài)(CLOSED), 否則重新切換到開路狀態(tài)(OPEN). Hystrix 的斷路器就像我們家庭電路中的保險(xiǎn)絲, 一旦后端服務(wù)不可用, 斷路器會(huì)直接切斷請(qǐng)求鏈, 避免發(fā)送大量無效請(qǐng)求影響系統(tǒng)吞吐量, 并且斷路器有自我檢測(cè)并恢復(fù)的能力。

API管理

SwaggerAPI 管理工具

SwaggerAPI管理工具：官網(wǎng)地址：https://swagger.io Swagger 是一款RESTFUL接口的文檔在線自動(dòng)生成+功能測(cè)試功能軟件，是一個(gè)規(guī)范和完整的框架，標(biāo)準(zhǔn)的，語言無關(guān)，用于生成、描述、調(diào)用和可視化 RESTful 風(fēng)格的 Web 服務(wù)。總體目標(biāo)是使客戶端和文件系統(tǒng)作為服務(wù)器以同樣的速度來更新。文件的方法，參數(shù)和模型緊密集成到服務(wù)器端的代碼，允許API來始終保持同步。Swagger 讓部署管理和使用功能強(qiáng)大的API從未如此簡(jiǎn)單。

目前最新版本是V3，SwaggerUI是一個(gè)簡(jiǎn)單的Restful API 測(cè)試和文檔工具。簡(jiǎn)單、漂亮、易用。通過讀取JSON 配置顯示API. 項(xiàng)目本身僅僅也只依賴一些 html,css.js靜態(tài)文件. 你可以幾乎放在任何Web容器上使用。

最后想給大家?guī)硪粋€(gè)好消息，小羽的公號(hào)最近也在遷移過程中，預(yù)計(jì)下周末就可以遷移完成，希望在未來能和大家繼續(xù)一起交流，互相學(xué)習(xí)，共同進(jìn)步。感謝大家一直以來的支持，我們下期見！