Nacos學習

Nacos是阿里開源的一個新框架，在分佈式的架構中，Nacos同時扮演着服務註冊中心和配置中心的角色。今天主要講的是Nacos做爲服務註冊中心。

分佈式中著名的CAP理論，任何一種服務註冊中心都只能實現其中的兩個特性，通常是AP（注重可用性）或者CP（注重一致性）。
Eureka就是一個AP的服務註冊中心，任何一個Eureka Server都是獨立的，可存儲全部的服務註冊信息，即便任意一臺Eureka Server宕機，其他的機器均可以照常工做，保證高可用性，可是不保證數據是一致的；
Zookeeper是一個CP的服務註冊中心，全部的服務註冊信息都存儲在leader的機器上，同步給其餘的follewer，能夠保證強一致性，若leader宕機，則不能提供服務註冊的功能了，須要從新選舉，沒法保證高可用性；
Nacos在 1.0.0 正式支持 AP 和 CP 兩種一致性協議並存。一個是基於簡化的 Raft 的 CP 一致性，一個是基於自研協議 Distro 的 AP 一致性。Raft 協議基於 Leader 進行寫入，其 CP 也並非嚴格的，只是能保證一半所見一致，以及數據的丟失機率較小。Distro 協議則是參考了內部 ConfigServer 和開源 Eureka，在不借助第三方存儲的狀況下，實現基本大同小異。

Eureka和Zookeeper都不能支持大量的服務實例，Eureka由於全部的服務實例在每一臺Eureka Server中都保存了，大量的服務實例會產生大量的心跳檢測等信息，致使Eureka Server沒法支持高併發的操做。
Zookeeper的話，會將服務實例的上線下線通知到每個服務實例，若是頻繁的上下線的話，會去通知大量的服務實例，致使短期網絡壓力增大，性能降低。
而Nacos 在開源版本中，服務實例註冊的支撐量約爲 100 萬，服務的數量能夠達到 10 萬以上。在實際的部署環境中，這個數字還會由於機器、網絡的配置與 JVM 參數的不一樣，可能會有所差異。

Nacos相比較於其餘的服務中心仍是有必定優點的。

Nacos服務註冊發現步驟

一、服務提供者將註冊信息寫入到Nacos註冊中心的服務註冊表中

二、服務註冊中心將服務提供者的實例交給Service Holder（服務持有容器）處理，服務實例將會掛載在Service Holder的空間下

三、服務註冊成功後，提供者將與服務中心維持心跳，未能及時發送心跳的服務將會被剔除

四、服務發現支持兩種場景

消費者能夠直接向註冊中心發送獲取某個服務實例的請求，這種狀況下注冊中心將返回全部可用的服務實例給消費者，可是通常不推薦這種狀況
服務的消費者向註冊中心訂閱某個服務，並提交一個監聽器，當註冊中心中服務發生變動時，監聽器會收到通知，這時消費者更新本地的服務實例列表，以保證全部的服務均是可用的。
原文連接：https://blog.csdn.net/LO_YUN/article/details/100181873