一、Nacos注冊中心
1、服務啟動后---->服務注冊原理
- springCloud集成Nacos實現原理： 服務啟動時，在spring-cloud-commons包下 spring.factories文件中自動裝配，當webServer初始話完成后，會注冊監聽事件。調用Nacos的register注冊服務
- springCloudAlibaba實現原理，springCloudAlibaba使用的是Nacos為注冊中心，自動裝配的配置類是 DubboLoadBalanceRestTemplateAutoConfiguration，原理和上述一致，基於事件監聽，不過事件類型不通，spring CloudAlibaba使用了@EvevntListener（ApplicationStartEvent.class） ，該事件是在應用程序初始化上下文后執行，即refresh()方法初始話上下文
2、服務注冊時---->與Nacos建立心跳原理
- 服務調用registerInstance方法進行服務注冊，registerInstance方法中，會調用addBeatInfo方法與Nacos Server服務建立心跳。
- 服務端是實現”心跳檢測“原理：即executorService.schedule(BeatTask beatTask)定時線程定時執行 入參為心跳包數據
- 服務 啟動一個定時線程-----（每隔5s）----->向Nacos服務發送BeatInfo心跳數據包
- 服務 啟動一個監視線程-----（）----->用來檢測上面的定時線程發送完數據包后，Nacos服務的回應，如果Nacos服務未回應，則認為Nacos服務異常。
3、Nacos收到服務注冊信息---->與服務建立心跳檢測原理
- Nacos收到服務注冊原理：服務調用Nacos的open API進行服務注冊，Nacos處理時，實際上時創建了一個concurrentHashMap將服務的信息以Namespace/group/緩存到服務內存中。
- Nacos收到心跳數據原理：Nacos服務init完成后，會定時監聽上述 第二步 服務發來的心跳包，如果等待超時后，沒有收到數據包，則認為服務異常healthy為false，會更新concurrentHashMap緩存的服務地址列表數據。
- 更新服務的地址列表數據后，會向所有的服務 主動推送Push一個最新的服務地址列表數據
- 基於數據一致性協議，會將最新的 服務地址列表數據同步到Nacos集群的其他節點上
4、服務端之間進行遠程調用---->調用Nacos獲取遠程服務地址列表數據原理
- 服務端獲取遠程調用服務地址列表數據原理：基於Nacos OpenAPI完成 獲取遠程服務地址列表數據，進而完成服務之間的遠程調用。同時本地會緩存一份地址列表數據（這里說一下，如果使用的是feign那么服務之間的調用協議是Http，如果是Dubbo，那么可以自定義協議，或者Dubbo協議）
5、服務本地會緩存一份服務提供者地址列表數據---->Nacos實現服務提供者地址列表數據 動態感知
- 一旦涉及到緩存，就要涉及緩存數據的一致性。在微服務的調用中，服務調用者會緩存一份 服務提供者的地址列表數據，如果這份緩存數據和 Nacos注冊中心的 服務提供者地址列表數據不一致。會造成服務消費者進行遠程調用時出錯。如果客戶端的負載均衡沒有做好，會造成嚴重問題。 Nacos解決 服務消費者動態感知 服務提供者地址 列表數據原理：（一般有兩種方式Push和Pull，Nacos都提供了）
- Pull模式：服務消費者 主動拉取，在調用selectInstance時，可以subscribe為true實現訂閱，客戶端會有 一個HostReactor update的定時線程-----（每隔10s）---->獲取一次服務提供者地址列表數據。這里定時為10s，比上面第二步5s上報心跳大，一定程度上保證了服務消費者獲取的地址列表數據的准確性
- Push模式：Push模式需要依賴上述的第二步，Nacos會監聽服務提供者的心跳數據包，並更新最后一次的心跳時間，如果超時了，那么說明服務提供者異常，會更新地址列表數據。並主動Push給服務消費者。
- 服務消費者收到Push數據原理：服務消費者收到最新的地址列表數據后，會將數據交給上述 Pull模式的 update定時線程來處理。站在服務消費者的角度，相當於服務消費者主動Pull了一次最新數據。這么做的原因是：保持服務消費者 只有一個線程感知接收服務提供者的地址列表數據。避免了Pull和Push如果多個線程處理，因為時間差造成的地址列表數據不一致的情況。
二、Nacos注冊中心 原理 架構圖
三、nacos配置中心原理：
1：配置的動態刷新客戶端如何感知，有兩種方式完成客戶端主動Pull拉取配置，Nacos Server主動Push配置數據
nacos采取的是Pull模式來完成配置的管理和動態刷新
1： Pull模式： 長輪詢機制
nacos采用了長輪詢機制實現，客戶端發起一個Pull拉取配置請求，nacos server建立一個延時任務隊列，每隔29.5s處理一個任務，
處理任務便是花費0.5s檢查配置有沒有變更。不管有沒有變更，都返回配置數據給客戶端。
之所以叫長輪詢，是因為客戶端和nacos建立的連接是一個30s的長連接。
缺點：沒有實時性，配置無變化會發起空pull,連接浪費資源。不過這里的缺點在下面的push都解決了。
2： Push模式：
當通過nacos dashboard或者nacos api修改了配置后，nacos檢查pull任務隊列，可能會在任務中29.5s內的任意時刻，開始處理任務，
和上述流程一致，檢查配置變更數據，返回給Pull請求最新配置。所以Push模式實質上還是利用了Pull請求的任務來完成。
PS: 客戶端本身會有一個定時線程每隔10ms檢查一次本地配置（硬盤中存儲）和內存（JVM）配置是否一致。通過上述動態刷新的只是內存中的配置。
四、naocs配置中心流程圖
