微服務注冊是微服務的核心元件，常見的有：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： 服務注冊中心和服務發現中心。
不論使用那種工具，服務注冊一定是要確定高可用的，否則重則的是所有的服務都沒法調用，輕則新的服務不能上線，是以一般都會考慮本地有緩存服務位址等方案。
更多資訊，點選全場景直播解決方案-航天雲網解決方案