1、Spring Cloud相關常用組件

注冊中心（nacos、Eureka等）、負載均衡（Ribbon、LoadBalancer）、遠程調用（feign）、服務熔斷（Sentinel、Hystrix）、網關（Gateway）

2、nacos與Eureka的區別

相同：

• 都支持服務注冊和服務拉取
• 都支持服務提供者心跳方式做健康檢測

區別：

• nacos支持服務端主動檢測提供者狀態：臨時實例采用心跳模式，非臨時實例采用主動檢測模式。
• 臨時實例心跳異常會被剔除，非臨時實例不會。
• nacos支持服務列表變更的消息推送，服務列表更新及時。
• nacos集群默認采用AP模式（高可用模式），當集群中存在非臨時實例時，采用CP模式（強一致模式），Eureka采用AP方式。
• nacos還支持配置中心，Eureka只有注冊中心。

3、服務雪崩

服務雪崩：一個服務失敗，導致整條鏈路的服務都失敗的情形

解決方式：

• 服務降級（針對某個接口）：服務自我保護的一種方式，或者保護下游服務的一種方式，用于確保服務不會受到請求突增影響變得不可用，確保服務不會崩潰，一般在實際開發中與feign接口整合，編寫降級邏輯。
• 服務熔斷（針對整個服務）：默認關閉，需要手動打開，如果檢測到10秒內請求的失敗率超過一定比率（如50%），就會觸發熔斷機制，之后每隔5秒重新嘗試請求微服務，如果微服務不能響應，繼續走熔斷機制。如果服務可達，則關閉熔斷機制，恢復正常請求

4、微服務的監控——skywalking

skywalking：一個分布式系統的應用程序性能監控工具，提供了完善的鏈路追蹤能力。

skywalking主要可以監控接口、服務、物理實例的一些狀態。特別是在壓測的時候可以看到眾多服務的中哪些服務和接口比較慢，我們可以針對性的分析和優化。

skywalking還可以設置告警規則，特別是在項目上線后，如果報錯，我們分別設置了可以給相關負責人發短信和發郵件，第一時間知道bug，第一時間修復。

5、微服務限流

限流實現方式：tomacat:可以設置最大連接數（一般在單體項目中使用），nginx：漏桶算法，網關：令牌桶算法，自定義攔截器。

nginx限流：

基于客戶端IP：

語法：limit_req_zone key zone rate

key:定義限流對象，binary _remote_addr就是一種key，基于客戶端ip限流方式。

zone:定義共享存儲區來存儲訪問信息，10m可以存儲16wip地址訪問信息。

rate:最大訪問速率，rate=10r/s，表示每秒最多請求10個請求。

burst=20，相當于桶的大小。nodelay：快速處理。

基于控制并發數：

語法一樣，還是上面這個：limit_req_zone key zone rate。

對應的key變為： $binary_remote_addr,表示限制單個IP同時最多能持有多少個連接。

網關限流：

yml配置文件中，微服務路由設置添加局部過濾器RequestRateLimiter。默認是使用redis的連接去存儲令牌。

6、分布式事務

CAP定理：CAP是一致性（consistency）、可用性（availability）、分區容錯性（partition tolerance）的首字母縮寫

分布式系統節點之間肯定是需要網絡連接的，分區（P）是必然存在的。

如果保證訪問的高可用性，可以持續對外提供服務，但是不能保證數據的強一致性，那這種就是AP。如果保證訪問數據的強一致性（C），那么就要放棄高可用性，這種就是CP。

BASE理論是對CAP的一種解決思路，包含三個思想。

Basically Available（基本可用）：分布式系統出現故障時，允許損失部分可用性，即保證核心可用。

Soft State （軟狀態）：在一定時間內，允許出現中間狀態，比如臨時的不一致狀態。

Eventually Consistent（最終一致性）：雖然無法保證強一致性，但是在軟狀態結束后，最終達到數據一致。

7、分布式事務解決方案

常用解決方案：seata框架（XA、AT、TCC）、MQ。

seata框架：

該框架中用三個重要角色：

TC（事務協調者）：維護全局和分支事務狀態，協調全局事務提交或回滾。

TM（事務管理器）：定義全局事務的范圍，開始全局事務、提交或回滾全局事務。

RM（資源管理器）：管理分支事務處理的資源，與TC交談以注冊分支事務和報告分支事務的狀態，并驅動分支事務提交或回滾。

這里的XA模式就是上面提到的CP模式（數據強一致性）。

AT模式就是上面提到的AP模式（高可用性），底層使用undo log實現。

TCC模式也是AP模式，使用try、confirm、cancel進行事務操作。

MQ：

這種一般時保證高可用，對數據強一致沒有效果。

8、分布式服務的接口冪等性的設計

冪等：多次調用方法或接口不會改變業務狀態，可以保證重復調用的結果和單次調用的結果一致。

解決方案：數據庫唯一索引（新增操作時）、token+redis(新增、修改都可以解決）、分布式鎖（也可以解決新增、修改時的冪等性問題）

9、分布式任務調度

這里主要介紹xxl-job。

xxl-job:解決集群任務重復執行的問題、cron表達式定義靈活、定時任務失敗了，重試和統計、任務量大、分片執行。

xxl-job的路由策略：大概有十種：輪詢、隨機、第一個（固定找第一個實例執行）、最后一個（固定找最后一個實例執行）、一致性hash（按照hash算法固定選擇某一個實例，且所有任務均勻散列在不同實例上）、最不經常使用、最近最久未使用、故障轉移（當去執行的實例出現故障，則選擇新的健康的實例去執行）、忙碌轉移、分片廣播。

xxl-job任務執行失敗怎么解決：

故障轉移+失敗重試，查看日志分析——>郵件警告