一、服務網關
隨着微服務的不斷增多，不同的微服務一般會有不同的網絡地址，而外部客戶端可能需要調用多個服務的接口才能完成一個業務需求，如果讓客戶端直接與各個微服務通信可能出現：
客戶端會多次請求不同的微服務，增加了客戶端的復雜性
存在跨域請求，在一定場景下處理相對復雜
身份認證問題，每個微服務需要獨立身份認證
難以重構，隨着項目的迭代，可能需要重新划分微服務
某些微服務可能使用了防火牆/瀏覽器不友好的協議，直接訪問會有一定的困難
針對這些問題，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 在很多場景下也是完全能滿足需求，具體怎么去選擇鑒權方案，還是要結合實際的需求來。