上次講了微服務的前世今生（五）：CAP 原則與 BASE 理論，這次我們再說微服務架構的前世今生（六）：微服務架構帶來的問題。 一、客戶端如何訪問服務？ 傳統的開發方式，所有的服務都是本地的，客戶端可以直接調用，現在按功能拆分成獨立的服務，客戶端如何訪問？ 後臺有 N 個服務，前臺就需要管理 N 個 ...
上次講了微服務的前世今生（五）：CAP 原則與 BASE 理論，這次我們再說微服務架構的前世今生（六）：微服務架構帶來的問題。
一、客戶端如何訪問服務？
傳統的開發方式，所有的服務都是本地的，客戶端可以直接調用，現在按功能拆分成獨立的服務，客戶端如何訪問？
後臺有 N 個服務，前臺就需要管理 N 個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不符合我們拆分的理念，另外，N 個服務的調用也是一個不小的網路開銷。還有一般微服務在系統內部，通常是無狀態的，用戶登錄信息和許可權管理最好有一個統一的地方維護管理（OAuth2）。
所以，一般在後臺 N 個服務和客戶端之間一般會一個代理（API Gateway），作用如下：
- 提供統一服務入口，聚合介面使得服務對調用者透明，客戶端與後端的耦合度降低
- 聚合後臺服務，節省流量，提高性能，提升用戶體驗
- 提供安全、流控、過濾、緩存、計費、監控等 API 管理功能
二、服務之間如何通信？
因為服務都是獨立部署的，所以通信也就成了問題，不過好在業界已經有很多成熟的解決方案，比如：
**同步通信：**
- REST（JAX-RS，Spring Boot）
- RPC（Dubbo，Thrift）
**非同步通信：**
- RabbitMQ，Kafka
三、這麼多服務如何查找？
在微服務架構中，為了高可用，普遍採用集群方式構建服務。一個服務可能隨時下線，也可能應對臨時訪問壓力增加新的服務節點。
服務之間如何相互感知？服務如何管理？這就是服務發現的問題了。基本都是通過類似 ZooKeeper 等類似技術做服務註冊信息的分散式管理。當服務上線時，服務提供者將自己的服務信息註冊到 ZooKeeper（或類似框架），並通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過 ZooKeeper 定址，找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZooKeeper 會發通知給服務客戶端。
四、服務掛了怎麼辦？
在微服務架構中，一個請求需要調用多個服務是非常常見的。如客戶端訪問 A 服務，而 A 服務需要調用 B 服務，B 服務需要調用 C 服務，由於網路原因或者自身的原因，如果 B 服務或者 C 服務不能及時響應，A 服務將處於阻塞狀態，直到 B 服務 C 服務響應。此時若有大量的請求涌入，容器的線程資源會被消耗完畢，導致服務癱瘓。服務與服務之間的依賴性，故障會傳播，造成連鎖反應，會對整個微服務系統造成災難性的嚴重後果，這就是服務故障的“雪崩”效應。
雪崩是系統中的蝴蝶效應導致，其發生的原因多種多樣，從源頭我們無法完全杜絕雪崩的發生，但是雪崩的根本原因來源於服務之間的強依賴，所以我們可以提前評估做好服務容錯。解決方案大概可以分為以下幾種：
- 請求緩存：支持將一個請求與返回結果做緩存處理；
- 請求合併：將相同的請求進行合併然後調用批處理介面；
- 請求限流：當請求過多時，可能會拖垮整個網站，通常會採取限流措施，降低機器的負載；
- 服務隔離：限制調用分散式服務的資源，某一個調用的服務出現問題不會影響其他服務調用；
- 服務熔斷：犧牲局部服務，保全整體系統穩定性的措施；
- 服務降級：服務熔斷以後，客戶端調用自己本地方法返回預設值。
下一篇講給大家帶來微服務架構生態體系，請關註。如果您想要學習視頻，請點擊獲取java微服務架構視頻教程。
