1.微服務架構要解決的問題
最大的問題：網絡是不可靠的。
1.1 客戶端如何訪問多個服務？
解決方案：服務聚合到API網關，聚合服務
1.2 服務與服務之間如何通信？
同步通信：Http（Apache Http Client）、RPC（Dubbo支持Java、Apache Thrift、gRPC）
異步通信：消息隊列，如：kafka、RabbitMQ、RocketMQ
1.3 多個服務如何管理？
實現高可用、高併發和高性能的微服務，即保證一直可以用，存在副本。服務治理（服務註冊），即服務上下線，管理服務的IP地址和端口。
基於客戶端的服務註冊與發現：Apache Zookeeper；
基於服務端的服務註冊與發現：Netflix Eureka。
1.4 服務掛了怎麼辦？
服務宕機或者異常而掛機時，常見的解決方案是：
- 重試機制
- 服務熔斷
- 服務降級
- 服務限流
2. 常見的分佈式解決方案對比
| Spring Boot + Spring Cloud | Spring Boot + Dubbo + Zookeeper |
|---|---|
| 組件多，功能完備 | 組件少 |
| Http通信 | RPC通信 |
3. 分佈式協調技術
分佈式協調技術主要用來解決分佈式環境當中多個進程之間的同步控制，讓他們有序地去訪問某種臨界資源，防止造成“髒數據”的後果。核心是實現分佈式鎖，Zookeeper是一個分佈式鎖的實現。
3.1 分佈式鎖應該具備哪些條件？
一個方法在同一時間只能被一個機器的一個線程執行
高可用地獲得鎖和釋放鎖
高性能地獲得鎖和釋放鎖
具備可重入性（較難）
具備鎖失效機制，防止死鎖
具備非阻塞鎖特性，既沒有獲取到鎖就直接返回獲取失敗
3.2 分佈式鎖有哪些實現？
- Memcached：利用其add命令，該命令爲原子操作，只有在key不存在的情況下才能add成功，也就意味着線程獲得到了鎖；
- Redis：利用其setnx命令，該命令也爲原子操作，只有在key不存在的情況下，才能set成功。
- Zookeeper：利用Zookeeper的順序臨時節點，來實現分佈式鎖和等待隊列，其設計初衷就是爲了實現分佈式鎖服務；
- Chubby：谷歌實現的粗粒度分佈式鎖微服務，底層利用了Paxos一致性算法。