在服務啟動時，服務提供者會向注冊中心注冊服務，暴露自己的地址和端口等，注冊中心會更新服務列表。服務消費者啟動時會向注冊中心請求可用的服務地址，並且在本地緩存一份提供者列表，這樣即便注冊中心宕機了，仍然可以正常調用服務。
如果提供者集群發生變更，注冊中心會將變更推送給服務消費者，更新可用的服務地址列表。
典型服務發現組件的選型
三種典型的服務發現組件，分別是 ZooKeeper、Eureka 和 Nacos。
ZooKeeper
ZooKeeper 主要應用在 Dubbo 的注冊中心實現，Dubbo + ZooKeeper 的典型服務化方案
服務提供者在啟動的時候，會在 ZooKeeper 上注冊服務。以 com.dubbo.DemoService 為例，注冊服務，其實就是在 ZooKeeper 的 /dubbo/com.dubbo.DemoService/providers 節點下創建一個子節點，並寫入自己的 URL 地址，這就代表了 com.dubbo.DemoService 這個服務的一個提供者。
服務消費者在啟動的時候，會向 ZooKeeper 注冊中心
訂閱服務列表，就是讀取並訂閱 ZooKeeper 上 /dubbo/com.dubbo.DemoService/providers 節點下的所有子節點，並解析出所有提供者的 URL 地址來作為該服務地址列表。
zookeeper的原理，leader+follower，leader寫，同步到follower，follower可以讀，保證順序一致性，就是基本盡量保證到數據一致的，主動推送，典型的CP，leader崩潰的時候，為了保證數據一致性，盡量不要讀到不一致的數據，此時要重新選舉leader以及做數據同步，此時集群會短暫的不可用
比如這里的評審員服務是provider service，舉報服務是consumer service，大致流程是這樣的：
Eureka
在 Spring Cloud 中，提供了 Eureka 來實現服務發現功能。Eureka 采用的是 Server 和 Client 的模式進行設計，Eureka Server 扮演了服務注冊中心的角色，為 Client 提供服務注冊和發現的功能。
Eureka Client 通過客戶端注冊的方式暴露服務，通過注解等方式嵌入到服務提供者的代碼中，當服務啟動時，服務發現組件會向注冊中心注冊自身提供的服務，並周期性地發送心跳來更新服務。
如果連續多次心跳不能夠發現服務，那么 Eureka Server 就會將這個服務節點從服務注冊表中移除，各個服務之間會通過注冊中心的注冊信息來實現調用。
eureka的原理，peer-to-peer，大家都能寫也都能讀，每個節點都要同步給其他節點，但是是異步復制的，所以隨時讀任何一個節點，可能讀到的數據都不一樣，任何一個節點宕機，其他節點正常工作，可用性超高，但是數據一致性不行，AP
比如這里的評審員服務是provider service，舉報服務是consumer service，大致流程是這樣的：
Nacos
Nacos 是阿里開源的，可以方便地集成 Spring Cloud 框架。nacos現在用的越來越多，以后也會是一個大的趨勢，但是現在可能還沒那么的普及
Nacos是基於raft算法的CP模型，同時也支持配置成類似eureka的AP。其實CP或者AP也都行，CP就是偶爾可能短時間不可用，AP就是可能數據不一致，兩個都有問題，但是在生產環境下，無論CP還是AP其實都用的很多
除了服務注冊和發現之外，Nacos 還提供了配置管理、元數據管理和流量管理等功能，並且提供了一個可視化的控制台管理界面。