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