Spring Cloud Alibaba面試核心知識點整理

11、Spring Cloud Alibaba

1.1、Spring Cloud Alibaba主要包含哪些組件？

Spring Cloud Alibaba 包含了多種開發(fā)分布式微服務系統(tǒng)的必需組件：

• Nacos：阿里巴巴開源產品，一個更易于構建云原生應用的動態(tài)服務發(fā)現,配置管理和服務管理平臺。
• Sentinel：阿里巴巴開源產品，把流量作為切入點,從流量控制,熔斷降級,系統(tǒng)負載保護等多個維度保護服務的穩(wěn)定性。
• RocketMQ：Apache RocketMQ 是一款基于Java 的高性能、高吞吐量的分布式消息和流計算平臺。
• Dubbo：Apache Dubbo 是一款高性能的 Java RPC 框架。
• Seata：阿里巴巴開源產品，一個易于使用的高性能微服務分布式事務解決、案。
• Alibaba Cloud ACM：一款在分布式架構環(huán)境中對應用配置進行集中管理和推送的應用配置中心產品。
• Alibaba Cloud OSS：阿里云對象存儲服務器（Object Storage Service，簡稱OSS），是阿里云提供的海量、安全、低成本、高可靠的云存儲服務。
• Alibaba Cloud SchedulerX：阿里中間件團隊開發(fā)的一款分布式調度產品,支持周期性的任務與固定時間點觸發(fā)任務。

1.2、相比原生的Spring Cloud，Spring Cloud Alibaba有哪些優(yōu)勢？

SpringCloud中的技術組件是集眾家之長，如注冊中心 Eureka、Zuul等都是依賴于Netflix，受制于第三方廠商。如Zuul宣布停止維護，Spring機構便不得不尋找替代品或自研；Eureka2.x 閉源不允許使用。Spring Cloud作為國外產品引入到國內后出現了水土不服，如SpringCloud Config默認將文件存在Github上，且沒有維護界面，國內軟件公司很難使用。

Spring Cloud Alibaba與原有 Spring Cloud 兼容的同時對微服務生態(tài)進行擴展，通過添加少量的配置注解，便可實現更符合國情的微服務架構。Spring Cloud Alibaba 對服務注冊、配置中心與負載均衡功能都整合進 Nacos，有圖形化界面，簡化了微服務架構的復雜度，出問題的概率也會降低。原有的服務保護組件也調整為 Sentinel，相較Hystrix功能更強大，使用也更加友好。同時還支持了對Dubbo的調用，而且還有Seata用于支持分布式事務。

22、Nacos

2.1、Nacos的核心功能有哪些？

• (1) 服務注冊：Nacos Client會通過發(fā)送REST請求的方式向Nacos Server注冊自己的服務，提供自身的元數據，比如ip地址、端口等信息。Nacos Server接收到注冊請求后，就會把這些元數據信息存儲在一個雙層的內存Map中。
• (2) 服務心跳：在服務注冊后，Nacos Client會維護一個定時心跳來持續(xù)通知Nacos Server，說明服務一直處于可用狀態(tài)，防止被剔除。默認5s發(fā)送一次心跳。
• (3) 服務同步：Nacos Server集群之間會互相同步服務實例，用來保證服務信息的一致性。leader raft
• (4) 服務發(fā)現：服務消費者（Nacos Client）在調用服務提供者的服務時，會發(fā)送一個REST請求給Nacos Server，獲取上面注冊的服務清單，并且緩存在Nacos Client本地，同時會在Nacos Client本地開啟一個定時任務定時拉取服務端最新的注冊表信息更新到本地緩存。
• (5) 服務健康檢查：Nacos Server會開啟一個定時任務用來檢查注冊服務實例的健康情況，對于超過15s沒有收到客戶端心跳的實例會將它的healthy屬性置為false(客戶端服務發(fā)現時不會發(fā)現)，如果某個實例超過30秒沒有收到心跳，直接剔除該實例(被剔除的實例如果恢復發(fā)送心跳則會重新注冊)

2.2、說說Nacos的工作流程？

• (1) 客戶端啟動時會將當前服務的信息包含ip）端口號）服務名）分組名）集群名等信息封裝為一個Instance對象，準備向Nacos服務器注冊服務，在注冊服務之前，會根據Instance中的信息創(chuàng)建一個BeatInfo對象，然后創(chuàng)建一個定時任務，每隔一段時間向Nacos服務器發(fā)送PUT請求并攜帶相關信息，作為定時心跳連接，服務器端在接收到心跳請求后，會去檢查當前服務列表中有沒有該實例，如果沒有的話將當前服務實例重新注冊，注冊完成后立即開啟一個異步任務，更新客戶端實例的最后心跳時間，如果當前實例是非健康狀態(tài)則將其改為健康狀態(tài)；
• (2) 心跳定時任務創(chuàng)建完成后，通過POST請求將當前服務實例信息注冊進Nacos服務器，服務器端在接收到注冊實例請求后，會將請求攜帶的數據封裝為一個Instance對象，然后為這個服務實例創(chuàng)建一個服務Service，一個Service下可能有多個服務實例，服務在Nacos保存到一個ConcurrentHashMap中，格式為命名空間為key，value為map，分組名和服務名為內層map的key，value為服務數據，如Map(namespace,Map(group::serviceName, Service))；
• (3) 服務創(chuàng)建完成之后，開啟一個定時任務（5s），檢查當前服務中的各個實例是否在線，如果實例上次心跳時間大于15s就將其狀態(tài)設置為不健康，如果超出30s，則直接將該實例刪除；
• (4) 然后將當前實例添加到對應服務列表中，這里會通過synchronized鎖住當前服務，然后分兩種情況向集群中添加實例，如果是持久化數據，則使用基于CP模式的簡單Raft協議，通過leader節(jié)點將實例數據更新到內存和磁盤文件中，并且通過CountDownLatch實現了一個簡單的raft寫入數據的邏輯，必須集群半數以上節(jié)點寫入成功才會給客戶端返回成功；
• (5) 如果是非持久話實例數據，使用的是基于AP模式的Distro協議，首先向任務阻塞隊列添加一個本地服務實例改變任務，去更新本地服務列表，然后在遍歷集群中所有節(jié)點，分別創(chuàng)建數據同步任務放進阻塞隊列異步進行集群數據同步，不保證集群節(jié)點數據同步完成即可返回；
• (6) 在將服務實例更新到服務注冊表中時，為了防止并發(fā)讀寫沖突，采用的是寫時復制的思想，將原注冊表數據拷貝一份，添加完成之后再替換回真正的注冊表，更新完成之后，通過發(fā)布服務變化事件，將服務變動通知給客戶端，采用的是UDP通信，客戶端接收到UDP消息后會返回一個ACK信號，如果一定時間內服務端沒有收到ACK信號，還會嘗試重發(fā)，當超出重發(fā)時間后就不在重發(fā)，雖然通過UDP通信不能保證消息的可靠抵達，但是由于Nacos客戶端會開啟定時任務，每隔一段時間更新客戶端緩存的服務列表，通過定時輪詢更新服務列表做兜底，所以不用擔心數據不會更新的情況，這樣既保證了實時性，又保證了數據更新的可靠性；
• (7) 服務發(fā)現：客戶端通過定時任務定時從服務端拉取服務數據保存在本地緩存，服務端在發(fā)生心跳檢測）服務列表變更或者健康狀態(tài)改變時會觸發(fā)推送事件，在推送事件中會基于UDP通信將服務列表推送到客戶端，同時開啟定時任務，每隔10s定時推送數據到客戶端。

33、Sentinel

3.1、說說Sentinel的使用場景？

sentinel在微服務中叫做流量防衛(wèi)兵，以流量為切入點，從流量控制、熔斷降級、系統(tǒng)負載保護等多個維度保護服務的穩(wěn)定性。Sentinel 具有以下特征：

• (1) 豐富的應用場景：Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺（即突發(fā)流量控制在系統(tǒng)容量可以承受的范圍）、消息削峰填谷、集群流量控制、實時熔斷下游不可用應用等。
• (2) 完備的實時監(jiān)控：Sentinel 同時提供實時的監(jiān)控功能。您可以在控制臺中看到接入應用的單臺機器秒級數據，甚至 500 臺以下規(guī)模的集群的匯總運行情況。
• (3) 廣泛的開源生態(tài)：Sentinel 提供開箱即用的與其它開源框架/庫的整合模塊，例如與 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相應的依賴并進行簡單的配置即可快速地接入 Sentinel。同時 Sentinel 提供 Java/Go/C++ 等多語言的原生實現。
• (4) 完善的 SPI 擴展機制：Sentinel 提供簡單易用、完善的 SPI 擴展接口。您可以通過實現擴展接口來快速地定制邏輯。例如定制規(guī)則管理、適配動態(tài)數據源等。

3.2、Sentinel和Hystrix有何區(qū)別？

3.3 說說限流算法有哪幾種？

計數器：計數器限流算法是最簡單的一種限流實現方式。其本質是通過維護一個單位時間內的計數器，每次請求計數器加1，當單位時間內計數器累加到大于設定的閾值，則之后的請求都被拒絕，直到單位時間已經過去，再將計數器重置為零。

漏桶算法：漏桶算法可以很好地限制容量池的大小，從而防止流量暴增。漏桶可以看作是一個帶有常量服務時間的單服務器隊列，如果漏桶（包緩存）溢出，那么數據包會被丟棄。在網絡中，漏桶算法可以控制端口的流量輸出速率，平滑網絡上的突發(fā)流量，實現流量整形，從而為網絡提供一個穩(wěn)定的流量。為了更好的控制流量，漏桶算法需要通過兩個變量進行控制：一個是桶的大小，支持流量突發(fā)增多時可以存多少的水（burst），另一個是水桶漏洞的大?。╮ate）。

令牌桶算法：令牌桶算法是對漏桶算法的一種改進，桶算法能夠限制請求調用的速率，而令牌桶算法能夠在限制調用的平均速率的同時還允許一定程度的突發(fā)調用。在令牌桶算法中，存在一個桶，用來存放固定數量的令牌。算法中存在一種機制，以一定的速率往桶中放令牌。每次請求調用需要先獲取令牌，只有拿到令牌，才有機會繼續(xù)執(zhí)行，否則選擇選擇等待可用的令牌、或者直接拒絕。放令牌這個動作是持續(xù)不斷的進行，如果桶中令牌數達到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時進來的請求就可以直接拿到令牌執(zhí)行，比如設置qps為100，那么限流器初始化完成一秒后，桶中就已經有100個令牌了，這時服務還沒完全啟動好，等啟動完成對外提供服務時，該限流器可以抵擋瞬時的100個請求。所以，只有桶中沒有令牌時，請求才會進行等待，最后相當于以一定的速率執(zhí)行。

3.4、Sentinel熔斷降級的原則是什么？

當檢測到調用鏈路中某個資源出現不穩(wěn)定的表現，例如請求響應時間長或異常比例升高的時候，則對這個資源的調用進行限制，讓請求快速失敗，避免影響到其它的資源而導致級聯故障。

3.5、Sentinel如何限制資源的調用？

通過并發(fā)線程數進行限制：Sentinel 通過限制資源并發(fā)線程的數量，來減少不穩(wěn)定資源對其它資源的影響。這樣不但沒有線程切換的損耗，也不需要您預先分配線程池的大小。當某個資源出現不穩(wěn)定的情況下，例如響應時間變長，對資源的直接影響就是會造成線程數的逐步堆積。當線程數在特定資源上堆積到一定的數量之后，對該資源的新請求就會被拒絕。堆積的線程完成任務后才開始繼續(xù)接收請求。

通過響應時間對資源進行降級：除了對并發(fā)線程數進行控制以外，Sentinel 還可以通過響應時間來快速降級不穩(wěn)定的資源。當依賴的資源出現響應時間過長后，所有對該資源的訪問都會被直接拒絕，直到過了指定的時間窗口之后才重新恢復。歡迎關注公眾號"Java學習之道"，查看更多干貨！

44、Seata

4.1、說說Seata的使用場景？

seata是開源分布式事務框架，提供了AT、TCC、SAGA 和 XA 幾種事務模式。分布式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于分布式系統(tǒng)的不同節(jié)點之上。簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬于不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。

4.2、為什么會產生分布式事務？

場景舉例：一個顧客訪問電商平臺，電商平臺架構按照不同的功能進行了拆分，有訂單、會員、庫存子系統(tǒng)，下單的過程中分布式事務就產生了。顧客在創(chuàng)建一個訂單的時候，要在訂單庫增加一個訂單數據，同時會同步的會員庫增加積分和庫存庫減少庫存。這種操作在單個數據庫中完成是沒有任何問題的，一旦涉及到了分布式的情況，比如下方三個獨立數據庫的情況，如何來保障數據全局提交、全局回滾，這就是分布式事務要做的事情了。

4.3、Seata架構有哪幾個角色，作用是什么？

Seata架構中有三個角色：

• (1) TC (Transaction Coordinator)：事務協調者維護全局和分支事務的狀態(tài)，驅動全局事務提交或回滾。
• (2) TM (Transaction Manager) ：事務管理器定義全局事務的范圍：開始全局事務、提交或回滾全局事務。
• (3) RM (Resource Manager) ：資源管理器管理分支事務處理的資源，與TC交談以注冊分支事務和報告分支事務的狀態(tài)，并驅動分支事務提交或回滾。

假設有一個下單業(yè)務，用戶發(fā)起下單(Create_Order)后需要進行支付扣款、扣庫存。Create_Order需要調用其他兩個服務進行數據的更新。微服務OrderService就是TM，它發(fā)起了全局事務， 庫存和支付這兩個微服務都是事務的參與者，而全局事務的進行需要TC協調兩個RM完成。

4.4、Seata主推的事務模式是什么，有什么優(yōu)勢？

AT是Seata主推的模式，是基于改進后的二階段協議實現的。AT模式是一種無侵入的分布式事務解決方案，技術核心是在每個服務的業(yè)務數據庫中創(chuàng)建一個undolog表。用戶只需關注自己的“業(yè)務 SQL”，用戶的 “業(yè)務 SQL” 作為一階段，Seata 框架會自動生成事務的二階段提交和回滾操作。

在一階段中，Seata會攔截“業(yè)務SQL“，首先解析SQL語義，找到要更新的業(yè)務數據，在數據被更新前，保存下來"undo"，然后執(zhí)行”業(yè)務SQL“更新數據，更新之后再次保存數據”redo“，最后生成行鎖，這些操作都在本地數據庫事務內完成，這樣保證了一階段的原子性。

二階段負責整體的回滾和提交，如果之前的一階段中有本地事務沒有通過，那么就執(zhí)行全局回滾，否在執(zhí)行全局提交，回滾用到的就是一階段記錄的"undo Log"，通過回滾記錄生成反向更新SQL并執(zhí)行，以完成分支的回滾。當然事務完成后會釋放所有資源和刪除所有日志。

4.5、Seata如何避免并發(fā)場景的臟讀與臟寫？

臟寫：假設兩個事務A 和 B 同時在更新一條數據，事務 A 先把它更新為 A 值，事務 B 緊接著把它更新為 B 值。當事務 B 更新完后，事務 A 突然回滾了，導致事務 B 修改的值也沒了。

臟讀：假設事務 A 更新了一行數據的值為 A 值，事務 B 去查詢了一下這行數據的值，看到的值是 A 值。事務 A 突然回滾了，導致剛才更新的 A 值沒了，當事務 B 再去再次查詢那行數據的值，也不是A了。

無論是臟寫還是臟讀，都是因為一個事務去更新或者查詢了另外一個還沒提交的事務更新過的數據。因為另外一個事務還沒提交，所以它隨時可能會回滾，那么必然導致更新的數據就沒了，或者之前查詢到的數據就沒了，這就是臟寫和臟讀兩種場景。

Seata利用TC所自帶的分布式鎖來避免臟讀與臟寫。

• 臟寫解決方案：如下圖所示，作為TC它會為第一個事務增加一個全局的分布式鎖，當對ID進行操作的時候，只有持有鎖的事務才可以進行操作，要是其他進程要對這個數據進行操作，就會一直處于等待的狀態(tài)，直到獲取到這個鎖的時候在去對同一條數據進行后續(xù)處理。通過分布式鎖在對資源進行鎖定，來完成并發(fā)寫的操作。

• 臟讀解決方案：在原有select 語句后面加 for update，加上以后Seata就會對這個select語句進行解析，為查找到的數據增加分布式鎖，這樣即使有其他線程要對這個數據進行寫操作的時候，因為要獲取分布式鎖，所以他會一直處于阻塞狀態(tài)，只有select執(zhí)行完畢，分布式鎖被釋放以后，后續(xù)的寫操作才會進行執(zhí)行。