客戶端如何訪問服務(wù)？
傳統(tǒng)的開發(fā)方式，所有的服務(wù)都是本地的，客戶端可以直接調(diào)用，現(xiàn)在按功能拆分成獨立的服務(wù)，客戶端如何訪問？
后臺有 N 個服務(wù)，前臺就需要管理 N 個服務(wù)，一個服務(wù)下線/更新/升級，前臺就要重新部署，這明顯不符合我們拆分的理念，另外，N 個服務(wù)的調(diào)用也是一個不小的網(wǎng)絡(luò)開銷。還有一般微服務(wù)在系統(tǒng)內(nèi)部，通常是無狀態(tài)的，用戶登錄信息和權(quán)限管理最好有一個統(tǒng)一的地方維護管理（OAuth2）。
所以，一般在后臺 N 個服務(wù)和客戶端之間一般會一個代理（API Gateway），作用如下：
- 提供統(tǒng)一服務(wù)入口，聚合接口使得服務(wù)對調(diào)用者透明，客戶端與后端的耦合度降低
- 聚合后臺服務(wù)，節(jié)省流量，提高性能，提升用戶體驗
- 提供安全、流控、過濾、緩存、計費、監(jiān)控等 API 管理功能
服務(wù)之間如何通信？
因為服務(wù)都是獨立部署的，所以通信也就成了問題，不過好在業(yè)界已經(jīng)有很多成熟的解決方案，比如：
- 同步通信：
- REST（JAX-RS，Spring Boot）
- RPC（Dubbo，Thrift）
- 異步通信：
- RabbitMQ，Kafka
這么多服務(wù)如何查找？
在微服務(wù)架構(gòu)中，為了高可用，普遍采用集群方式構(gòu)建服務(wù)。一個服務(wù)可能隨時下線，也可能應(yīng)對臨時訪問壓力增加新的服務(wù)節(jié)點。
服務(wù)之間如何相互感知？服務(wù)如何管理？這就是服務(wù)發(fā)現(xiàn)的問題了?；径际峭ㄟ^類似 ZooKeeper 等類似技術(shù)做服務(wù)注冊信息的分布式管理。當服務(wù)上線時，服務(wù)提供者將自己的服務(wù)信息注冊到 ZooKeeper（或類似框架），并通過心跳維持長連接，實時更新連接信息。服務(wù)調(diào)用者通過 ZooKeeper 尋址，找到一個服務(wù)，還可以將服務(wù)信息緩存在本地以提高性能。當服務(wù)下線時，ZooKeeper 會發(fā)通知給服務(wù)客戶端。
服務(wù)掛了怎么辦？
在微服務(wù)架構(gòu)中，一個請求需要調(diào)用多個服務(wù)是非常常見的。如客戶端訪問 A 服務(wù)，而 A 服務(wù)需要調(diào)用 B 服務(wù)，B 服務(wù)需要調(diào)用 C 服務(wù)，由于網(wǎng)絡(luò)原因或者自身的原因，如果 B 服務(wù)或者 C 服務(wù)不能及時響應(yīng)，A 服務(wù)將處于阻塞狀態(tài)，直到 B 服務(wù) C 服務(wù)響應(yīng)。此時若有大量的請求涌入，容器的線程資源會被消耗完畢，導(dǎo)致服務(wù)癱瘓。服務(wù)與服務(wù)之間的依賴性，故障會傳播，造成連鎖反應(yīng)，會對整個微服務(wù)系統(tǒng)造成災(zāi)難性的嚴重后果，這就是服務(wù)故障的“雪崩”效應(yīng)。
雪崩是系統(tǒng)中的蝴蝶效應(yīng)導(dǎo)致，其發(fā)生的原因多種多樣，從源頭我們無法完全杜絕雪崩的發(fā)生，但是雪崩的根本原因來源于服務(wù)之間的強依賴，所以我們可以提前評估做好服務(wù)容錯。解決方案大概可以分為以下幾種：
- 請求緩存：支持將一個請求與返回結(jié)果做緩存處理；
- 請求合并：將相同的請求進行合并然后調(diào)用批處理接口；
- 請求限流：當請求過多時，可能會拖垮整個網(wǎng)站，通常會采取限流措施，降低機器的負載；
- 服務(wù)隔離：限制調(diào)用分布式服務(wù)的資源，某一個調(diào)用的服務(wù)出現(xiàn)問題不會影響其他服務(wù)調(diào)用；
- 服務(wù)熔斷：犧牲局部服務(wù)，保全整體系統(tǒng)穩(wěn)定性的措施；
- 服務(wù)降級：服務(wù)熔斷以后，客戶端調(diào)用自己本地方法返回缺省值。
今天要說的微服務(wù)架構(gòu)帶來的問題篇暫時先說這么多，了解更多技術(shù)干貨，關(guān)注公眾號【樂字節(jié)發(fā)送123可了解我們一起學習吖】，我是哩哩，一個有趣的靈魂！下期見！
