微服務注冊是微服務的核心組件，常見的有：ZooKeeper，Consul，Nacos，Eureka...等等，下面我就重點來詳解微服務注冊@mikechen

微服務注冊

服務注冊指的是將自身服務信息注冊到注冊中心，服務信息包括：服務所在主機IP、服務的端口號Port、暴露服務協議等信息。

如下圖所示：

圖片

Service B 把自己注冊到注冊中心，這就叫 服務注冊。

服務注冊作用

服務注冊就是維護一個登記簿，它管理系統內所有的服務地址。

當新的服務啟動后，它會向登記簿交待自己的地址信息，服務的依賴方直接向登記簿要服務地址就行了。

同時服務注冊還要負責一件事情，服務狀態的維護，假如一個服務突然down掉，它應該能夠感知，并把down掉的服務摘掉，然后主動或被動的把這個信息告知服務消費方。

服務注冊實現

服務注冊有兩種形式：客戶端注冊和代理注冊。

1.客戶端注冊

客戶端注冊是服務自己要負責注冊與注銷的工作，當服務啟動后注冊線程向注冊中心注冊，當服務下線時注銷自己。

圖片

這種方式的缺點是注冊注銷邏輯與服務的業務邏輯耦合在一起，如果服務使用不同語言開發，那需要適配多套服務注冊邏輯。

2.代理注冊(第三方注冊)

代理注冊也叫第三方注冊，指的是一個單獨的代理服務負責注冊與注銷。

當服務提供者啟動后以某種方式通知代理服務，然后代理服務負責向注冊中心發起注冊工作。

圖片

第三方注冊的優點非常明顯，就是服務跟服務注冊表是分離的，不需要為每種編程語言和架構完成服務注冊邏輯，替代的，服務實例是通過一個集中化管理的服務進行管理的。

這種方式的缺點是多引用了一個代理服務，并且代理服務需要配置管理一個高可用的系統。

微服務注冊框架

當下用于服務注冊的工具非常多ZooKeeper，Consul，Etcd, 還有Netflix家的Eureka等等。

1.ZooKeeper

這里服務注冊的實現會運用Zookeeper的watch機制來實現。

比如：客戶端注冊監聽他關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增加刪除）時，Zookeeper會通知客戶端。

client端會對某個znode建立一個watcher事件，當該znode發生變化時，zk會主動通知watch這個znode的client，然后client根據znode的變化來做出業務上的改變等。

如下圖所示：

圖片

2.Consul

Consul 是 HashiCorp 公司推出的開源工具，用于實現分布式系統的服務發現與配置。

Consul架構，如下圖所示：

圖片

圖片上 datacenter 分成上下兩個部分， 但是這兩個部分又不是完全隔離的，他們之間通過 WAN GOSSIP 進行報文交互。

3.Etcd

Etcd是使用Go語言開發的一個開源的、高可用的分布式key-value存儲系統，可以用于配置共享和服務的注冊和發現。

Etcd架構如下圖所示：

圖片

從 架構圖中我們可以看到etcd 主要分為四個部分：

• HTTP Server

用于處理用戶發送的 API 請求，以及其它 Etcd節點的同步與心跳信息請求。

• Store

用于處理 Etcd支持的各類功能的事務，包括數據索引、節點狀態變更、監控與反饋、事件處理與執行等等。

• Raft

Raft 是強一致性算法的具體實現，是 Etcd的核心。

• WAL

Write Ahead Log，預寫日志系統，是 Etcd的數據存儲方式，Etcd就通過 WAL 進行持久化存儲，這個與MySQL持久化存儲機制類似。

Write-Ahead Logging 是數據庫中一種高效的日志算法，對于非內存數據庫而言，磁盤I/O操作是數據庫效率的一大瓶頸。

在相同的數據量下，采用WAL日志的數據庫系統在事務提交時，磁盤寫操作只有傳統的回滾日志的一半左右，大大提高了數據庫磁盤I/O操作的效率，從而提高了數據庫的性能。

4.Eureka

Eureka 作為 Spring Cloud 微服務框架的注冊中心，與之對應的是 Dubbo 框架的ZooKeeper。

Eureka基本架構，如下圖所示：

上圖簡要描述了Eureka的基本架構，由3個角色組成：

1.Service Provider： 暴露服務的服務提供方。

2)Service Consumer：調用遠程服務的服務消費方。

3)EureKa Server： 服務注冊中心和服務發現中心。

不論使用那種工具，服務注冊一定是要確保高可用的，否則重則的是所有的服務都沒法調用，輕則新的服務不能上線，所以一般都會考慮本地有緩存服務地址等方案。