架構圖
網關
負責路由轉發+過濾器；他是系統的唯一對外的入口，介於客戶端和服務器之間的中間層，處理非業務功能，提供路由請求、鑒權、監控、緩存、限流等功能
服務注冊發現
調用和被調用方信息維護；服務啟動的時候，都注冊到注冊中心里，這樣的話別人調用的時候，就知道有哪些ip地址和端口號了
配置中心
管理配置，動態更新
鏈路追蹤
分析調用鏈路耗時；例如：下單、查庫存、減庫存、付款、下單完成
負載均衡器
分發負載；例如：nginx
熔斷
保護自己和被調用方，類似於家里的保險絲，為了防止整個系統故障
降級
服務降級是當服務器壓力劇增的情況下，根據當前業務情況及流量對一些服務和頁面有策略的降級，以此釋放服務器資源以保證核心任務的正常運行。
熔斷和降級區別
相同點
- 從可用性和可靠性觸發，為了防止系統崩潰
- 最終讓用戶體驗到的是某些功能暫時不能用
不同點
- 服務熔斷一般是下游服務故障導致的
- 服務降級一般是從整個系統負荷考慮，由調用方控制
拋棄一些非核心的接口和數據，例如：雙11，支付寶將查詢當月賬單功能臨時降級等等
什么是微服務的注冊中心
服務管理，核心是有個服務注冊表，心跳機制動態維護
服務提供者
啟動的時候向注冊中心上報自己的網絡信息
服務消費者
啟動的時候向注冊中心上報自己的網站信息，拉取提供者的相關網絡信息
為什么要用注冊中心
微服務應用和機器越來越多，調用方需要知道接口的網絡地址，如果靠配置文件的方式去控制網絡地址，對於動態新增機器，維護起來很麻煩
主流的注冊中心
- zookeeper
- eureka
- consul
- etcd
- nacos
- 等
分布式應用CAP理論知識
定理
指的是在一個分布式系統中，Consistency(一致性)、Availability(可用性)、Partition tolerance(分區容錯性)，三者不可同時獲得。CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容錯性是我們必須需要實現的，所以我們只能在一致性和可用性之間進行權衡。
一致性(C)
在分布式系統中的所有數據備份，在同一時刻是否同樣的值(所有節點在同一時間的數據完全一致，越多數據同步越耗時)。
可用性(A)
負載過大后，集群整體是否還能響應客戶端的讀寫請求(服務一直可用，而且是正常響應時間)。
分區容錯性(P)
分區容忍性，就是高可用性，一個節點崩了，並不影響其他的節點。
CA(一致性、可用性)
數據同步(C)需要時間，也要正常的時間內響應(A)，那么機器數量就要少，所以P就不滿足。
CP(一致性、分區容錯性)
數據同步(C)需要時間，機器數量也多(P)，但是同步數據需要時間，所以不能再正常時間內響應，所以A就不滿足。
AP(可用性、分區容錯性)
機器數量也多(P)，正常的時間內響應(A)，那么數據就不能及時同步其他節點，所以C不滿足。
注冊中心選擇
Zookeeper：CP原則，保證了一致性，集群搭建的時候，某個節點失效，則會進行選舉新的leader，或者半數以上節點不可用，則無法提供服務，因此可用性沒法滿足
Eureka：AP原則，無主從節點，一個節點掛了，自動切換其他節點可以使用，去中心化
服務間調用方式
RPC
遠程過程調用，像調用本地服務(方法)一樣調用服務器的服務，支持同步、異步調用，客戶端和服務器之間建立TCP連接，可以一次建立一個，也可以多個調用復用一次連接
REST(Http)
http請求，支持多種協議和功能，開發方便成本低
未完持續性更新