爲何須要服務註冊和發現?

 

假設在微服務系統中有一個服務隨着業務發展，服務器負載愈來愈高，須要新增服務器。若是沒有服務註冊與發現，就要把新的服務器地址配置到全部依賴模塊的服務，而後從新部署，這顯然是不合理的。

服務註冊與發現就是保證當服務上下線發生變動時，服務消費者和服務提供者可以保持正常通訊。

有了服務註冊和發現機制，消費者不須要知道具體服務提供者的真實物理地址就能夠進行調用，也無須知道具體有多少個服務者可用；而服務提供者只須要註冊到註冊中心，就能夠對外提供服務，在對外服務時不須要知道具體是哪些服務調用了本身。

 

 

 

在服務啓動時，服務提供者會向註冊中心註冊服務，暴露本身的地址和端口等，註冊中心會更新服務列表。服務消費者啓動時會向註冊中心請求可用的服務地址，而且在本地緩存一份提供者列表，這樣即使註冊中心宕機了，仍然能夠正常調用服務。

若是提供者集羣發生變動，註冊中心會將變動推送給服務消費者，更新可用的服務地址列表。

典型服務發現組件的選型

三種典型的服務發現組件，分別是 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 還提供了配置管理、元數據管理和流量管理等功能，而且提供了一個可視化的控制檯管理界面。