微服務注冊最全詳解(圖文全面總結)
微服務注冊是微服務的核心組件，常見的有：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： 服務注冊中心和服務發現中心。
不論使用那種工具，服務注冊一定是要確保高可用的，否則重則的是所有的服務都沒法調用，輕則新的服務不能上線，所以一般都會考慮本地有緩存服務地址等方案。
