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服務注冊發現步驟
1、服務提供者將注冊信息寫入到Nacos注冊中心的服務注冊表中
2、服務注冊中心將服務提供者的實例交給Service Holder（服務持有容器）處理，服務實例將會掛載在Service Holder的空間下
3、服務注冊成功后，提供者將與服務中心維持心跳，未能及時發送心跳的服務將會被剔除
4、服務發現支持兩種場景
消費者可以直接向注冊中心發送獲取某個服務實例的請求，這種情況下注冊中心將返回所有可用的服務實例給消費者，但是一般不推薦這種情況
服務的消費者向注冊中心訂閱某個服務，並提交一個監聽器，當注冊中心中服務發生變更時，監聽器會收到通知，這時消費者更新本地的服務實例列表，以保證所有的服務均是可用的。
原文鏈接：https://blog.csdn.net/LO_YUN/article/details/100181873