微服务注册是微服务的核心组件，常见的有：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： 服务注册中心和服务发现中心。
不论使用那种工具，服务注册一定是要确保高可用的，否则重则的是所有的服务都没法调用，轻则新的服务不能上线，所以一般都会考虑本地有缓存服务地址等方案。
