开源注册中心架构
- 客户端 注册中心
- 服务端 注册中心
一般分为应用内注册和应用外注册
- 应用内注册与发现：注册中心提供服务端和客户端的 SDK，业务应用通过引入注册中心提供的 SDK，通过 SDK 与注册中心交互，来实现服务的注册和发现。
- 应用外注册与发现：业务应用本身不需要通过 SDK 与注册中心打交道，而是通过其他方式与注册中心交互，间接完成服务注册与发现。
![在这里插入图片描述]()
- Eureka Server：注册中心的服务端，实现了服务信息注册、存储以及查询等功能。
- 服务端的 Eureka Client：集成在服务端的注册中心 SDK，服务提供者通过调用 SDK，实现服务注册、反注册等功能。客户端的
- Eureka Client：集成在客户端的注册中心 SDK，服务消费者通过调用 SDK，实现服务订阅、服务更新等功能。
![在这里插入图片描述]()
- Consul：注册中心的服务端，实现服务注册信息的存储，并提供注册和发现服务。
- Registrator：一个开源的第三方服务管理器项目，它通过监听服务部署的 Docker 实例是否存活，来负责服务提供者的注册和销毁。
- Consul Template：定时从注册中心服务端获取最新的服务提供者节点列表并刷新 LB 配置（比如 Nginx 的 upstream），这样服务消费者就通过访问 Nginx 就可以获取最新的服务提供者信息。
注册中心选型
主要看应用场景
高可用性
- 集群部署
- 多IDC部署
从下面的官方架构图中你可以看到，一方面，在每个数据中心（DATACENTER）内都有多个注册中心 Server 节点可供访问；另一方面还可以部署在多个数据中心来保证多机房高可用性。
![在这里插入图片描述]()
数据一致性
数据一致性问题一般是 采用cap原理 C（Consistency）代表一致性，A（Avalibabilty)可用性 ，P（Partition Tolerance)代表分区容错性
分布式集群如何保证数据一致性
问题描述：
- 分区有可能网络问题导出整个网络被切割成互不连通的区域，出现分区一个区域的节点就没有办法相互访问，最好的办法就是把数据复制到其他区域内的节点，这就是数据的容错性。
- 但是把数据复制到多个节点上有可能出现数据不一致的问题，这就是一致性。要保证一致性，就要等所有节点上的数据都更新成功才可以，这就是可用性。
- 总的来说数据节点越多，分区容错性越高，但是数据一致性就越难保证。为了保证数据一致性，会带来可用性问题。
cp型注册中
牺牲可用性来保证数据的一致性，最典型的就是zookeeper，etcd,Consul.Zookeeper集群内部只有一个Leader，而且在leader无法使用是会通过Paxos算法选举出一个Leader.这个leader就是为了保证写信息的时候只向这个Leader写入，Leader会同步信息到Followers，这个过程就可以保证数据强一致性。但如果多个Zookerper之间出现网络问题，造成多个Leader，发生脑裂的话注册中心就不可用
Ap型注册中心
牺牲数据一致性，保证服务的可用性，最典型的急速Eureka