1.註冊與發現
-
服務通過nacos server內部的open api進行服務註冊，nacos server內部有一個sevice服務的概念，裏面有多個instance實例的概念，同時對不同的service服務可以劃歸到不同的namespace命名空間下去
![]()
註冊的時候就是在註冊表裏維護好每個服務的每個實例的服務器地址，包括ip地址和端口號
一旦註冊成功之後，服務就會跟nacos server進行定時的心跳，保持心跳是很關鍵的，nacos server會定時檢查服務各個實例的心跳，如果一定時間沒心跳，就認爲這個服務實例宕機了，就從註冊表裏摘除了
其他服務會從nacos server通過open api查詢要調用的服務實例列表，而且nacos客戶端會啓動一個定時任務，每隔10s就重新拉取一次服務實例列表，這樣如果調用的服務有上線或者下線，就能很快感知到了
還可以對要調用的服務進行監聽，如果有異常變動會由nacos server反向通知他
nacos本身的話，其實是完全可以脫離spring cloud自己獨立運作的，但是他目前是集成到spring cloud alibaba裏去的，也就是在spring cloud的標準之下實現了一些東西，spring cloud自己是有一個接口，叫做ServiceRegistry，也就是服務註冊中心的概念
2.數據一致性
- 目前來看基本可以歸爲兩家：一種是基於 Leader 的非對等部署的單點寫一致性，一種是對等部署的多寫一致性。
- 當我們選用服務註冊中心的時候，並沒有一種協議能夠覆蓋所有場景
- Nacos 因爲要支持多種服務類型的註冊，並能夠具有機房容災、集羣擴展等必不可少的能力，在 1.0.0 正式支持 AP 和 CP 兩種一致性協議並存。
- 目前的一致性協議實現，一個是基於簡化的 Raft 的 CP 一致性，一個是基於自研協議 Distro 的 AP 一致性。
3.負載均衡
負載均衡嚴格的來說，並不算是傳統註冊中心的功能。一般來說服務發現的完整流程應該是先從註冊中心獲取到服務的實例列表，然後再根據自身的需求，來選擇其中的部分實例或者按照一定的流量分配機制來訪問不同的服務提供者，因此註冊中心本身一般不限定服務消費者的訪問策略
3.1Ribbon 設計的客戶端負載均衡機制
- Ribbon 設計的客戶端負載均衡機制，主要是選擇合適現有的 IRule、ServerListFilter 等接口實現，或者自己繼承這些接口，實現自己的過濾邏輯。這裏 Ribbon 採用的是兩步負載均衡，第一步是先過濾掉不會採用的服務提供者實例，第二步是在過濾後的服務提供者實例裏，實施負載均衡策略。Ribbon 內置的幾種負載均衡策略功能還是比較強大的，同時又因爲允許用戶去擴展，這可以說是一種比較好的設計。
- 基於標籤的負載均衡策略可以做到非常靈活，Kubernetes 和 Fabio 都已經將標籤運用到了對資源的過濾中，使用標籤幾乎可以實現任意比例和權重的服務流量調配。但是標籤本身需要單獨的存儲以及讀寫功能，不管是放在註冊中心本身或者對接第三方的 CMDB。