上次講了微服務的前世今生（五）：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微服務架構視頻教程，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/152933.html
標籤：Java