微服務架構的前世此生（六）：微服務架構帶來的問題

上次講了微服務的前世此生（五）：CAP 原則與 BASE 理論，此次咱們再說微服務架構的前世此生（六）：微服務架構帶來的問題。

1、客戶端如何訪問服務？

傳統的開發方式，全部的服務都是本地的，客戶端能夠直接調用，如今按功能拆分紅獨立的服務，客戶端如何訪問？

後臺有 N 個服務，前臺就須要管理 N 個服務，一個服務下線/更新/升級，前臺就要從新部署，這明顯不符合咱們拆分的理念，另外，N 個服務的調用也是一個不小的網絡開銷。還有通常微服務在系統內部，一般是無狀態的，用戶登陸信息和權限管理最好有一個統一的地方維護管理（OAuth2）。

因此，通常在後臺 N 個服務和客戶端之間通常會一個代理（API Gateway），做用以下：

- 提供統一服務入口，聚合接口使得服務對調用者透明，客戶端與後端的耦合度下降
- 聚合後臺服務，節省流量，提升性能，提高用戶體驗
- 提供安全、流控、過濾、緩存、計費、監控等 API 管理功能

2、服務之間如何通訊？

由於服務都是獨立部署的，因此通訊也就成了問題，不過好在業界已經有不少成熟的解決方案，好比：

**同步通訊：**

- REST（JAX-RS，Spring Boot）
- RPC（Dubbo，Thrift）

**異步通訊：**

- RabbitMQ，Kafka

3、這麼多服務如何查找？

在微服務架構中，爲了高可用，廣泛採用集羣方式構建服務。一個服務可能隨時下線，也可能應對臨時訪問壓力增長新的服務節點。

服務之間如何相互感知？服務如何管理？這就是服務發現的問題了。基本都是經過相似 ZooKeeper 等相似技術作服務註冊信息的分佈式管理。當服務上線時，服務提供者將本身的服務信息註冊到 ZooKeeper（或相似框架），並經過心跳維持長連接，實時更新連接信息。服務調用者經過 ZooKeeper 尋址，找到一個服務，還能夠將服務信息緩存在本地以提升性能。當服務下線時，ZooKeeper 會發通知給服務客戶端。

 

4、服務掛了怎麼辦？

在微服務架構中，一個請求須要調用多個服務是很是常見的。如客戶端訪問 A 服務，而 A 服務須要調用 B 服務，B 服務須要調用 C 服務，因爲網絡緣由或者自身的緣由，若是 B 服務或者 C 服務不能及時響應，A 服務將處於阻塞狀態，直到 B 服務 C 服務響應。此時如有大量的請求涌入，容器的線程資源會被消耗完畢，致使服務癱瘓。服務與服務之間的依賴性，故障會傳播，形成連鎖反應，會對整個微服務系統形成災難性的嚴重後果，這就是服務故障的「雪崩」效應。

雪崩是系統中的蝴蝶效應致使，其發生的緣由多種多樣，從源頭咱們沒法徹底杜絕雪崩的發生，可是雪崩的根本緣由來源於服務之間的強依賴，因此咱們能夠提早評估作好服務容錯。解決方案大概能夠分爲如下幾種：

- 請求緩存：支持將一個請求與返回結果作緩存處理；
- 請求合併：將相同的請求進行合併而後調用批處理接口；
- 請求限流：當請求過多時，可能會拖垮整個網站，一般會採起限流措施，下降機器的負載；
- 服務隔離：限制調用分佈式服務的資源，某一個調用的服務出現問題不會影響其餘服務調用；
- 服務熔斷：犧牲局部服務，保全總體系統穩定性的措施；
- 服務降級：服務熔斷之後，客戶端調用本身本地方法返回缺省值。

下一篇講給你們帶來微服務架構生態體系，請關注。若是您想要學習視頻，請點擊獲取java微服務架構視頻教程。