當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

图文详解：如何给女朋友解释什么是微服务？

發布時間：2024/3/13 编程问答 34 豆豆

生活随笔收集整理的這篇文章主要介紹了图文详解：如何给女朋友解释什么是微服务？小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

微服務：微服務是基于分而治之的思想演化出來的。過去傳統的一個大型而又全面的系統，隨著互聯網的發展已經很難滿足市場對技術的需求，于是我們從單獨架構發展到分布式架構，又從分布式架構發展到 SOA 架構，服務不斷的被拆分和分解，粒度也越來越小，直到微服務架構的誕生。

微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。

每個服務運行在其獨立的進程中，服務和服務間采用輕量級的通信機制互相溝通（通常是基于 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容器上使用。

最后想給大家帶來一個好消息，小羽的公號最近也在遷移過程中，預計下周末就可以遷移完成，希望在未來能和大家繼續一起交流，互相學習，共同進步。感謝大家一直以來的支持，我們下期見！

總結

以上是生活随笔為你收集整理的图文详解：如何给女朋友解释什么是微服务？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。