?
?
微服務：微服務是基于分而治之的思想演化出來的，過去傳統的一個大型而又全面的系統，隨著互聯網的發展已經很難滿足市場對技術的需求，于是我們從單獨架構發展到分布式架構，又從分布式架構發展到 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容器上使用，
?
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/261247.html
標籤：Java
上一篇：Java String型別