企业微服务分布式注册中心原理

随着互联网的发展，对应用服务的要求也在发生着变化。有原来的大而臃肿的单个大型应用服务解耦拆分成由很多微服务共同调用来实现其功能。单个大型应用它自身集合了所有的功能，如有单个模块有问题就需要整个应用重新打包上线和测试，影响大耗时费力。而分布式微服务调用每个服务只负责单一功能模块，更新模块功能只需更新对应功能模块的微服务即可。但分布式微服务相互之间要怎么远程调用呢？就需要用到注册中心。目前所有互联网公司都采用分布式微服务方式，所以注册中心都是必须且必要的。

注册中心角色

注册中心主要有三种角色：

服务提供者（RPC Server）：在启动时，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。
服务消费者（RPC Client）：在启动时，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。
服务注册中心（Registry）：用于保存 RPC Server 的注册信息，当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地内存中缓存的服务节点列表。

最后，RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。

注册中心原理

微服务网络远程调用为RPC调用，而RPC服务注册/发现过程如下：

服务提供者启动时，会将其服务名称，ip地址注册到注册中心。
服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的IP地址列表，并缓存到本地，以供后续使用。当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。
当服务提供者的某台服务器宕机或下线时，相应的ip会从服务提供者IP列表中移除。同时，注册中心会将新的服务IP地址列表发送给服务消费者机器，缓存在消费者本机。
当某个服务的所有服务器都下线了，那么这个服务也就下线了。
同样，当服务提供者的某台服务器上线时，注册中心会将新的服务IP地址列表发送给服务消费者机器，缓存在消费者本机。
服务提供方可以根据服务消费者的数量来作为服务下线的依据。

注册中心功能

根据注册中心原理的描述，注册中心必须实现以下功能。

CAP

CAP理论

CAP理论是分布式架构中重要理论

1
2
3

一致性(Consistency) (所有节点在同一时间具有相同的数据)
可用性(Availability) (保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

CAP理解

P的理解是在整个系统中某个部分挂掉或者宕机了，并不影响整个系统的运作或者使用，是网络层面的，通常认为网络是顺畅流通的。

A可用性是系统的某个节点挂了，但并不影响系统的接受请求或者发出响应。

C一致性是客户端请求系统中的任意节点，获取的返回结果都是一致的。系统中各个节点会实时同步信息来保证，通常各种微服务和注册中心都不是单台的，通常都是有多台组成服务集群，那么各个节点的数据一致性就要考量。

CAP侧重

但CAP 3项不可能都取，只能取其中2两项，造成侧重点不同。

如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。

如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果一致就不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。

再如果，同事满足一致性和可用性，那么分区容错就很难保证了，只能是单点，也是分布式的基本核心。好了，明白这些理论，就可以在相应的场景选取服务注册与发现了

协议算法

一致性协议算法主要有Paxos、Raft、ZAB。

Paxos算法是Leslie Lamport在1990年提出的一种基于消息传递的一致性算法，非常难以理解，基于Paxos协议的数据同步与传统主备方式最大的区别在于：Paxos只需超过半数的副本在线且相互通信正常，就可以保证服务的持续可用，且数据不丢失。

Raft是斯坦福大学的Diego Ongaro、John Ousterhout两个人以易理解为目标设计的一致性算法，已经有了十几种语言的Raft算法实现框架，较为出名的有etcd，Google的Kubernetes也是用了etcd作为他的服务发现框架。

Raft是Paxos的简化版，与Paxos相比，Raft强调的是易理解、易实现，Raft和Paxos一样只要保证超过半数的节点正常就能够提供服务。这篇文章《ETCD教程-2.Raft协议》详细讲解了Raft原理，非常有意思，感兴趣的同学可以看看。