为什么须要注册核心
在理论生产零碎中，会有这样的一种状况：A 服务调用 B 服务，B 服务调用 C 服务（只思考同步调用，不思考异步调用，所以通过 mq 的形式这里排除）：
如果 A 服务想要调用 B 服务，咱们是须要晓得 B 服务的 IP 的，同理 B 服务也要晓得 C 服务的 IP：
看起来曾经解决了多个服务同步调用的问题，如果此时 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 的地址，尽管注册核心最终会因为同步而保持数据最终统一，然而在这个过程中，并不影响服务从注册核心获取被调用方的地址，尽管有可能获取到的数据并不是残缺的（数据没有强一致性）。
CP 模型状况下，能够看到只有 Leader 才能够注册，而后把数据同步到 Slave。这个就绝对于注册核心是单写了，所以写的性能就比 AP 的差。而且为了保证数据的一致性，要同步到其余 Follower 节点的时候才能够被读取到，另外如果 Leader 宕机了，整个服务在选举的时候是不可用的，晓得新的 Leader 被选举进去。
综上，AP 尽管就义了数据的强一致性，然而性能上比 CP 好。比方下面的例子，尽管 A 服务 1 只有 B 服务 1 的地址，然而也能够失常工作的，所以数据的强一致性其实是不太须要的。然而他也有一个问题，就是 B 服务宕机的时候，A 服务并不能及时的发现。
脑裂
在 CP 模型下，咱们假如 A 服务 1 和 A 服务 3 是同一个机房的，A 服务 2 是另外一个机房的，此时呈现了脑裂，导致两个机房不能相互通信。在这种状况下，为了保证数据的一致性，上面机房的注册核心此时是不能读写的，这样造成的结果如下：
- 如果此时上面机房新启动了 B 服务 3，是没方法注册到注册核心。
- 如果 A 服务 2 重启，缓存失落，或者 A 服务再加一个服务，他是没有方法从注册核心获取数据的。
所以明明是同一个机房的，却因为脑裂而不能对 B 服务扩容，甚至无法访问 B 服务。
综上，咱们应该抉择 AP 的注册核心。
大规模服务
不论是 CP 模型还是 AP 模型，在大规模服务下，注册核心都很难反对。
AP 模型下，他们会相互同步注册信息，导致大量的数据来各个节点传递，占用了网络带宽以及 CPU。
CP 模型下，每个服务的上线下线都要告诉各个服务，服务一多，网络带宽就被占用。