- 1、为什么需要注册中心
在一个繁杂的业务中，传统的单体工程不仅难以支撑，而且给团队协作开发造成很多不便，这时分布式系统顺势而生
分布式:将一个大的业务拆分成许多小的服务，各个服务之间可以相互调用
如下图所示，假设先将一个项目拆分成服务A、服务B、服务C，三个服务之间可以相互调用。这时如果服务B调用服务A，只要服务B中有服务A的相关信息(如服务A的ip、端口号等)就能直接通过发送http请求或者走tcp连接即可。
然而，各个服务之间需要保存其它服务的相关信息，当服务信息改变时又得修改各自的配置信息，具有很高的耦合度，这时如果有一个第三者，各个服务只要将各自的信息注册在上面，如下图所示，服务A、服务B、服务C都将各自的信息注册到服务D，当服务B需要调用服务A时，服务B只要从服务D中找到服务A对应的连接信息即可，服务D即注册中心。
目前主流的注册中心技术有:Zookeeper、Eureka、Consul、Nacos
- 2.主流注册中心介绍
Zookeeper
Zookeeper是一个开源的分布式协调服务，其设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一些简单的接口提供给用户使用。Zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据订阅/发布、负载均衡、命名服务、集群管理、分布式锁和分布式队列等功能。
在ZK中引入了三种角色，分别是:Leader、Follower、Observer，Leader为客户端提供了读写服务，而Follower和Observer只提供了读服务，Follower和Observer中的数据由Leader进行同步。当Leader服务挂了之后，则需要重新选举新的Leader。
在分布式系统中，有一个很重要的定理，即CAP定理，C代表一致性，A代表可用性，P代表分区容错性，CAP原则指出最多只能满足这三者中的其中两个。
而ZK恰好满足了CP,即一致性和分区容错性，将ZK当作注册中兴，如下图所示
服务B将自己注册到leader，而leader进行数据同步，服务A则可以通过leader或follower拿到服务B的信息，但是由于ZK满足了CP，即保持一致性，从而牺牲了可用性，当leader挂掉之后需要重新进行选举leader，这时系统处于不可用。
Eureka
eureka是Netflix开发的服务发现框架，SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。Eureka满足了三大条件中的AP，即尽可能满足了可用性而弱一致性，如下图所示
在上图中部署了三个Eureka服务，而这三个Eureka都能提供读写操作，如上图，当A服务1往eureka2注册时，一定时间内将同步到其它两台eureka服务，当A服务2往eureka3中注册时，一定时间内将同步到其它两台eureka服务，由于eureka之间是异步复制，即一定时间内eureka中可能出现数据不一致，B服务有可能读取不到数据。
Consul
consul采用 Raft 算法,用来保证服务的高可用,即满足了三大条件中的CP
Nacos
Nacos也是基于Raft算法的CP模型，同时也支持配置成类似Eureka的AP模型，同时Nacos还能作为配置中心
- 3.结束语
对于注册中心的技术选型，可以根据自己的业务特点和CAP来选择。而我想说的是Nacos作为阿里巴巴的开源项目，既可以作为注册中心而且可以作为配置中心，未来可期。并且spring cloud alibaba作为spring cloud的第二代，能更好的兼容Nacos，以及社区比较活跃，大力推荐。
