本文為joshua317原創文章,轉載請注明：轉載自joshua317博客 https://www.joshua317.com/article/186
一、引言
Nacos 的關鍵特性指出：nacos支持服務發現和服務健康監測。其中是這么描述的：
Nacos 支持基於 DNS 和基於 RPC 的服務發現。服務提供者使用 原生SDK、OpenAPI、或一個獨立的Agent TODO注冊 Service 后，服務消費者可以使用DNS TODO 或HTTP&API查找和發現服務。
Nacos 提供對服務的實時的健康檢查，阻止向不健康的主機或服務實例發送請求。Nacos 支持傳輸層 (PING 或 TCP)和應用層 (如 HTTP、MySQL、用戶自定義）的健康檢查。 對於復雜的雲環境和網絡拓撲環境中（如 VPC、邊緣網絡等）服務的健康檢查，Nacos 提供了 agent 上報模式和服務端主動檢測2種健康檢查模式。Nacos 還提供了統一的健康檢查儀表盤，幫助您根據健康狀態管理服務的可用性及流量。
從上面我們可以知道，Nacos 提供了 agent 上報模式和服務端主動檢測2種健康檢查模式。
Nacos 在 1.0.0版本 instance級別增加了一個ephemeral字段，該字段表示注冊的實例是否是臨時實例還是持久化實例。如果是臨時實例，則不會在 Nacos 服務端持久化存儲，需要通過上報心跳的方式進行保活，如果一段時間內沒有上報心跳，則會被 Nacos 服務端摘除。在被摘除后如果又開始上報心跳，則會重新將這個實例注冊。持久化實例則會持久化到Nacos 服務端，通過主動探知客戶端健康的方式進行檢測，此時即使注冊實例的客戶端進程不在，這個實例也不會從服務端刪除，只會將健康狀態設為不健康。
同一個服務下可以同時有臨時實例和持久化實例，這意味着當這服務的所有實例進程不在時，會有部分實例從服務上摘除，剩下的實例則會保留在服務下。
使用實例的ephemeral來判斷
ephemeral為true對應的是服務健康檢查模式中的 client 模式,即是agent 上報模式，
ephemeral為為false對應的是 server 模式，即是服務端主動檢測模式。
二、agent上報模式
客戶端（注冊在nacos上的其它微服務實例）健康檢查。
客戶端通過心跳上報方式告知服務端(nacos注冊中心)健康狀態；
默認心跳間隔5秒；
nacos會在超過15秒未收到心跳后將實例設置為不健康狀態；
超過30秒將實例刪除；
三、服務端主動檢測模式
服務端健康檢查。
nacos主動探知客戶端健康狀態，默認間隔為20秒；
健康檢查失敗后實例會被標記為不健康，不會被立即刪除。
四、不得不說的"臨時實例"和"持久化實例"
Instance中有一個ephemeral字段，用來表示該實例是臨時實例，還是持久化實例。
把ephemera的字段值設置為true，則為臨時實例。
把ephemera的字段值設置為false，則為持久化實例。
臨時實例與持久化實例的區別：主要體現在服務器對實例的處理上。
臨時實例向Nacos注冊，Nacos不會對其進行持久化存儲，只能通過心跳方式保活。默認模式是：客戶端心跳上報Nacos實例健康狀態，默認間隔5秒，Nacos在15秒內未收到該實例的心跳，則會設置為不健康狀態，超過30秒則將實例刪除。
持久化實例向Nacos注冊，Nacos會對其進行持久化處理。當該實例不存在時，Nacos只會將其健康狀態設置為不健康，但並不會對將其從服務端刪除。
另外，可以使用實例的ephemeral來判斷健康檢查模式，ephemeral為true對應的是client模式（客戶端心跳），為false對應的是server模式（服務端檢查）。
五、為什么會有兩種健康檢查模式呢？
對於臨時實例，健康檢查失敗，則直接可以從列表中刪除。這種特性就比較適合那些需要應對流量突增的場景，服務可以進行彈性擴容。當流量過去之后，服務停掉即可自動注銷了。
對於持久化實例，健康檢查失敗，會被標記成不健康狀態。它的好處是運維可以實時看到實例的健康狀態，便於后續的警告、擴容等一些列措施。
除了上述場景之外，持久化實例還有另外一個場景用的到，那就是保護閾值。
六、拓展
6.1 Nacos的保護閾值
Nacos中可以針對具體的實例設置一個保護閾值，值為0-1之間的浮點類型。本質上，保護閾值是⼀個⽐例值（當前服務健康實例數/當前服務總實例數）。
⼀般情況下，服務消費者要從Nacos獲取可用實例有健康/不健康狀態之分。Nacos在返回實例時，只會返回健康實例。
但在高並發、大流量場景會存在⼀定的問題。比如，服務A有100個實例，98個實例都處於不健康狀態，如果Nacos只返回這兩個健康實例的話。流量洪峰的到來可能會直接打垮這兩個服務，進一步產生雪崩效應。
保護閾值存在的意義在於當服務A健康實例數/總實例數 < 保護閾值時，說明健康的實例不多了，保護閾值會被觸發（狀態true）。
Nacos會把該服務所有的實例信息（健康的+不健康的）全部提供給消費者，消費者可能訪問到不健康的實例，請求失敗，但這樣也⽐造成雪崩要好。犧牲了⼀些請求，保證了整個系統的可⽤。
這里我們看到了不健康實例的另外一個作用：防止產生雪崩。
那么，如果所有的實例都是臨時實例，當雪崩場景發生時，Nacos的閾值保護機制是不是就沒有足夠的（包含不健康實例）實例返回了？如果有一部分實例是持久化實例，即便它們已經掛掉，狀態為不健康的，但當觸發閾值保護時，還是可以起到分流的作用。
6.2 Nacos CP/AP模式切換
CAP原則又稱CAP定理，指的是在一個分布式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
分區容忍性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
CAP原則的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某個分布式系統中數據無副本， 那么系統必然滿足強一致性條件， 因為只有獨一數據，不會出現數據不一致的情況，此時C和P兩要素具備，但是如果系統發生了網絡分區狀況或者宕機，必然導致某些數據不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足 。
Nacos 集群默認支持的是CAP原則中的AP原則，但是也可切換為CP原則，切換命令如下：
curl -X PUT '127.0.0.1:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'
同時微服務的bootstrap.properties 需配置如下選項指明注冊為臨時/永久實例 AP模式不支持數據一致性，所以只支持服務注冊的臨時實例，CP模式支持服務注冊的永久實例，滿足配置文件的一致性
6.3 Server運行模式的設置
Server的運行模式，是指 Nacos Server 可以運行在多種模式下，當前支持三種模式：AP、CP和 MIXED 。這里的運行模式，使用的是CAP理論里的C、A和P概念。基於CAP理論，在分布式系統中，數據的一致性、服務的可用性和網絡分區容錯性只能三者選二。一般來說分布式系統需要支持網絡分區容錯性，那么就只能在C和A里選擇一個作為系統支持的屬性。C 的准確定義應該是所有節點在同一時間看到的數據是一致的，而A的定義是所有的請求都會收到響應。
Nacos 支持 AP 和 CP 模式的切換，這意味着 Nacos 同時支持兩者一致性協議。這樣，Nacos能夠以一個注冊中心管理這些生態的服務。不過在Nacos中，AP模式和CP模式的具體含義，還需要再說明下。
AP模式為了服務的可用性而減弱了一致性，因此AP模式下只支持注冊臨時實例。AP 模式是在網絡分區下也能夠注冊實例。在AP模式下也不能編輯服務的元數據等非實例級別的數據，但是允許創建一個默認配置的服務。同時注冊實例前不需要進行創建服務的操作，因為這種模式下，服務其實降級成一個簡單的字符創標識，不在存儲任何屬性，會在注冊實例的時候自動創建。
CP模式下則支持注冊持久化實例，此時則是以 Raft 協議為集群運行模式，因此網絡分區下不能夠注冊實例，在網絡正常情況下，可以編輯服務器別的配置。改模式下注冊實例之前必須先注冊服務，如果服務不存在，則會返回錯誤。
MIXED 模式可能是一種比較讓人迷惑的模式，這種模式的設立主要是為了能夠同時支持臨時實例和持久化實例的注冊。這種模式下，注冊實例之前必須創建服務，在服務已經存在的前提下，臨時實例可以在網絡分區的情況下進行注冊。
6.4 AP 還是 CP ？
說到分布式系統就一定離不開CAP定理,CAP定理叫作布魯爾定理。對於設計分布式系統來說(不僅僅是分布式事務)的架構師來說，CAP就是你的入門理論。
- C (一致性):對某個指定的客戶端來說，讀操作能返回最新的寫操作。對於數據分布在不同節點上的數據上來說，如果在某個節點更新了數據，那么在其他節點如果都能讀取到這個最新的數據，那么就稱為強一致，如果有某個節點沒有讀取到，那就是分布式不一致。
- A (可用性)：非故障的節點在合理的時間內返回合理的響應(不是錯誤和超時的響應)。可用性的兩個關鍵一個是合理的時間，一個是合理的響應。合理的時間指的是請求不能無限被阻塞，應該在合理的時間給出返回。合理的響應指的是系統應該明確返回結果並且結果是正確的，這里的正確指的是比如應該返回50，而不是返回40。
- P (分區容錯性):當出現網絡分區后，系統能夠繼續工作。打個比方，這里個集群有多台機器，有台機器網絡出現了問題，但是這個集群仍然可以正常工作。
熟悉CAP的人都知道，三者不能共有，如果感興趣可以搜索CAP的證明，在分布式系統中，網絡無法100%可靠，分區其實是一個必然現象，如果我們選擇了CA而放棄了P，那么當發生分區現象時，為了保證一致性，這個時候必須拒絕請求，但是A又不允許，所以分布式系統理論上不可能選擇CA架構，只能選擇CP或者AP架構。
對於CP來說，放棄可用性，追求一致性和分區容錯性，我們的zookeeper其實就是追求的強一致。
對於AP來說，放棄一致性(這里說的一致性是強一致性)，追求分區容錯性和可用性，這是很多分布式系統設計時的選擇，后面的BASE也是根據AP來擴展。
順便一提，CAP理論中是忽略網絡延遲，也就是當事務提交時，從節點A復制到節點B，但是在現實中這個是明顯不可能的，所以總會有一定的時間是不一致。同時CAP中選擇兩個，比如你選擇了CP，並不是叫你放棄A。因為P出現的概率實在是太小了，大部分的時間你仍然需要保證CA。就算分區出現了你也要為后來的A做准備，比如通過一些日志的手段，是其他機器回復至可用。
本文為joshua317原創文章,轉載請注明：轉載自joshua317博客 https://www.joshua317.com/article/186