今天繼續說微服務架構生態體系，作者為哈嘍沃德先生，
一、服務網關
隨著微服務的不斷增多，不同的微服務一般會有不同的網路地址，而外部客戶端可能需要呼叫多個服務的介面才能完成一個業務需求，如果讓客戶端直接與各個微服務通信可能出現：
客戶端會多次請求不同的微服務，增加了客戶端的復雜性
存在跨域請求，在一定場景下處理相對復雜
身份認證問題，每個微服務需要獨立身份認證
難以重構，隨著專案的迭代，可能需要重新劃分微服務
某些微服務可能使用了防火墻/瀏覽器不友好的協議，直接訪問會有一定的困難
針對這些問題，API網關順勢而生，
API 網關直面意思是將所有 API 呼叫統一接入到 API 網關層，由網關層統一接入和輸出，一個網關的基本功能有：統一接入、安全防護、協議適配、流量管控、長短鏈接支持、容錯能力，有了網關之后，各個 API 服務提供團隊可以專注于自己的的業務邏輯處理，而 API 網關更專注于安全、流量、路由等問題，
二、服務呼叫
在微服務架構中，通常存在多個服務之間的遠程呼叫的需求，目前主流的遠程呼叫技術有基于 HTTP 的 RESTful 介面和基于 TCP 的 RPC 協議，以上兩種都屬于同步通信，還有基于佇列模式的異步通信，
- REST（Representational State Transfer）：一種 HTTP 呼叫的格式，更標準，更通用，無論哪種語言都支持
http 協議，
- RPC（Remote Promote Call）：一種行程間通信方式，允許像呼叫本地服務一樣呼叫遠程服務，RPC框架的主要目標就是讓遠程服務呼叫更簡單、透明，RPC框架負責屏蔽底層的傳輸方式、序列化方式和通信細節，開發人員在使用的時候只需要了解誰在什么位置提供了什么樣的遠程服務介面即可，并不需要關心底層通信細節和呼叫程序，
三、服務治理
服務治理就是進行服務的自動化管理，其核心是服務的自動注冊與發現，
「服務注冊」：服務實體將自身服務資訊注冊到注冊中心，
「服務發現」：服務實體通過注冊中心，獲取注冊到其中的服務實體的資訊，通過這些資訊去請求它們提供的服務，
「服務剔除」：服務注冊中心將出問題的服務自動剔除到可用串列之外，使其不會被呼叫到，
四、負載均衡
服務高可用的保證手段，為了保證高可用，每一個微服務都需要部署多個服務實體來提供服務，此時就需要根據不同的負載均衡策略對服務進行呼叫，
1、負載均衡策略
輪詢策略
實作原理：輪詢策略表示每次都順序取下一個 provider，比如一共有 5 個 provider，第 1 次取第 1 個，第 2 次取第 2 個，第 3 次取第 3 個，以此類推，
權重輪詢策略
實作原理：根據每個 provider 的回應時間分配一個權重，回應時間越長，權重越小，被選中的可能性越低，
原理：一開始為輪詢策略，并開啟一個計時器，每 30 秒收集一次每個 provider 的平均回應時間，當資訊足夠時，給每個 provider 附上一個權重，并按權重隨機選擇 provider，高權越重的 provider 會被高概率選中，
隨機策略
實作原理：從 provider 串列中隨機選擇一個，
最少并發數策略
實作原理：選擇正在請求中的并發數最小的 provider，除非這個 provider 在熔斷中，
重試策略
實作原理：其實就是輪詢策略的增強版，輪詢策略服務不可用時不做處理，重試策略服務不可用時會重新嘗試集群中的其他節點，
可用性敏感策略
實作原理：過濾性能差的 provider
第一種：過濾掉在 Eureka 中處于一直連接失敗的 provider，
第二種：過濾掉高并發（繁忙）的 provider，
區域敏感性策略
實作原理：以一個區域為單位考察可用性，對于不可用的區域整個丟棄，從剩下區域中選可用的 provider，如果這個 ip 區域內有一個或多個實體不可達或回應變慢，都會降低該 ip 區域內其他 ip 被選中的權 重，
五、服務容錯
在微服務中，一個請求經常會涉及到呼叫多個服務，如果其中某個服務不可用，沒有做服務容錯的話，極有可能會造成一連串的服務不可用，這就是雪崩效應，最終的結果就是：一個服務不可用，導致一系列服務的不可用，
造成雪崩的原因可以歸結為以下三點：
- 服務提供者不可用（硬體故障，程式 BUG，快取擊穿，用戶大量請求等）
- 重試加大流量（用戶重試，代碼邏輯重試）
- 服務消費者不可用（同步等待造成的資源耗盡）
我們沒法預防雪崩效應的發生，只能盡可能去做好容錯，服務容錯的三個核心思想是：
- 不被外界環境影響
- 不被上游請求壓垮
- 不被下游回應拖垮
六、鏈路追蹤
隨著微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務，互聯網應用構建在不同的軟體模塊集上，這些軟體模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實作、有可能布在了幾千臺服務器，橫跨多個不同的資料中心，因此，就需要對一次請求涉及的多個服務鏈路進行日志記錄，性能監控等等，單純的理解鏈路追蹤，就是指一次任務的開始到結束，期間呼叫的所有系統及耗時（時間跨度）都可以完整記錄下來，
鏈路追蹤系統做好了，鏈路資料有了，借助前端決議和渲染工具，可以達到下圖中的效果：
七、配置中心
組態檔是我們再熟悉不過的，在微服務系統中，每個微服務不僅僅只有代碼，還需要「連接其他資源」，例如資料庫的配置或功能性的開關 MySQL、Redis 、Security 等相關的配置，除了專案運行的基礎配置之外，還有一些配置是與我們業務有關系的，比如說七牛存盤、短信和郵件相關，或者一些業務上的開關，
但是隨著微服務系統的不斷迭代，整個微服務系統可能會成為一個「網狀結構」，這個時候就要考慮整個微服務系統的「擴展性、伸縮性、耦合性」等等，其中一個很重要的環節就是「配置管理」的問題，
常規配置管理解決方案缺點：
- 硬編碼（需要修改代碼、繁瑣、風險大）
- properties 或者 yml（集群環境下需要替換和重啟）
- xml（重新打包和重啟）
由于常規配置管理有很大的缺點，所以采用 Spring Cloud Config 或 Consul 或 Apollo 或 Nacos 等配置中心「集中式」的來管理「每個服務」的配置資訊，
八、安全認證
從單體應用架構到分布式應用架構再到微服務架構，應用的安全訪問在不斷的經受考驗，為了適應架構的變化、需求的變化，身份認證與鑒權方案也在不斷的變革，面對數十個甚至上百個微服務之間的呼叫，如何保證高效安全的身份認證？面對外部的服務訪問，該如何提供細粒度的鑒權方案？
David Borsos 在倫敦的微服務大會上提出了四種解決方案：
1、單點登錄（SSO）
這種方案意味著每個面向用戶的服務都必須與認證服務互動，這會產生大量非常瑣碎的網路流量和重復的作業，隨著微服務應用的增多，這種方案的弊端會更加明顯，
2、分布式 Session 方案
分布式會話方案原理主要是將關于用戶認證的資訊存盤在共享存盤中，且通常由用戶會話作為 Key 來實作的簡單分布式哈希映射，當用戶訪問微服務時，用戶資料可以從共享存盤中獲取，這種方案的缺點在于共享存盤需要一定保護機制，因此需要通過安全鏈接來訪問，這時解決方案的實作就通常具有相當高的復雜性了，
3、客戶端 Token 方案
令牌在客戶端生成，由身份驗證服務進行簽名，并且必須包含足夠的資訊，以便可以在所有微服務中建立用戶身份，令牌會附加到每個請求上，為微服務提供用戶身份驗證，這種解決方案的安全性相對較好，但身份驗證注銷是一個大問題，緩解這種情況的方法可以使用短期令牌和頻繁檢查認證服務等，對于客戶端令牌的編碼方案，David Borsos 更喜歡使用 JSON Web Tokens（JWT），它足夠簡單且庫支持程度也比較好，
4、客戶端 Token 與 API 網關結合
這個方案意味著所有請求都通過網關，從而有效地隱藏了微服務，在請求時，網關將原始用戶令牌轉換為內部會話 ID 令牌，在這種情況下，注銷就不是問題，因為網關可以在注銷時撤銷用戶的令牌，
九、總結
在微服務架構下，我們更傾向于 David Borsos 所建議的 JWT 方案，將 OAuth2 和 JWT 結合使用，OAuth2 一般用于第三方接入的場景，管理對外的權限，所以比較適合和 API 網關結合，針對于外部的訪問進行鑒權（當然，底層 Token 標準采用 JWT 也是可以的），
JWT 更加輕巧，在微服務之間進行認證&鑒權已然足夠，并且可以避免和身份認證服務直接打交道，當然，從能力實作角度來說，類似于分布式 Session 在很多場景下也是完全能滿足需求，具體怎么去選擇鑒權方案，還是要結合實際的需求來，
如您想完整系統地學習微服務架構，推薦點擊 java微服務架構spring全家桶學習視頻教程，資料豐富、視頻學習更快效率更高，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/149781.html
標籤：Java