注册中心

为什么需要注册中心

在实际生产系统中，会有这样的一种情况：A服务调用B服务，B服务调用C服务（只考虑同步调用，不考虑异步调用，所以通过mq的方式这里排除）：

看起来已经解决了多个服务同步调用的问题，如果此时B服务的IP变了怎么办？A服务是不是就要做更改了，但是有没有想过，如果还有其他服务也调用B呢，那这些服务都要做变更，没及时变更的就不能正常调用了。

Nginx

有人说，用Nginx反向代理：

此时对B服务的调用都是通过NGINX_1，对C服务的调用都是通过NGINX_2，如果B服务的地址改了，我们只需要改NGINX_1的配置文件然后重启就好。看起来可以解决，我们示例只有3个服务调用，链路就这么长了，如果是更多的服务调用，那链路要多长，而且每次新增一个服务都要配置一个新的Nginx，那运维可能会打你。

DNS

有人说，那用DNS吧：

虽然屏蔽了IP，和上面一样，每次新增一个服务都要配置一个新的域名对应IP，更麻烦的是，在集群情况下，Nginx可以知道哪个服务不可用，并把请求转发到其他集群服务器，但是DNS不知道，而且DNS也不能根据一定的策略进行负载均衡，还有缓存等等问题。

注册中心

既然上面两种方式都不合适，我们可以用注册中心。
在服务B启动的时候，会往注册中心注册当前服务的ip以及端口，注册中心维护这些注册信息，A服务在调用之前，会通过注册中心拿到B服务的ip和端口，这样就可以直接调用B服务了，再也不怕服务B乱改地址、在集群里增减服务了。

CP还是AP

常见的注册中心有zookeeper、consul、eureka、nacos，前两个是CP，eureka是AP，nacos两个都支持，那我们是选哪一种呢？CAP概念见之前文章

性能

AP模型情况下，此时B服务1已经注册到注册中心1了，B服务2也注册到注册中心2了，A服务1是可以通过注册中心1获取B服务1的地址，A服务2也可以通过注册中心2获取B服务2的地址，虽然注册中心最终会因为同步而保持数据最终一致，但是在这个过程中，并不影响服务从注册中心获取被调用方的地址，虽然有可能获取到的数据并不是完整的（数据没有强一致性）。

综上，AP虽然牺牲了数据的强一致性，但是性能上比CP好。比如上面的例子，虽然A服务1只有B服务1的地址，但是也可以正常工作的，所以数据的强一致性其实是不太需要的。但是他也有一个问题，就是B服务宕机的时候，A服务并不能及时的发现。

脑裂

在CP模型下，我们假设A服务1和A服务3是同一个机房的，A服务2是另外一个机房的，此时出现了脑裂，导致两个机房不能互相通信。在这种情况下，为了保证数据的一致性，下面机房的注册中心此时是不能读写的，这样造成的后果如下：

1. 如果此时下面机房新启动了B服务3，是没办法注册到注册中心。
2. 如果A服务2重启，缓存丢失，或者A服务再加一个服务，他是没有办法从注册中心获取数据的。

所以明明是同一个机房的，却因为脑裂而不能对B服务扩容，甚至无法访问B服务。

综上，我们应该选择AP的注册中心。

大规模服务

不管是CP模型还是AP模型，在大规模服务下，注册中心都很难支持。
AP模型下，他们会互相同步注册信息，导致大量的数据来各个节点传递，占用了网络带宽以及CPU。
CP模型下，每个服务的上线下线都要通知各个服务，服务一多，网络带宽就被占用。