注册中心

介绍
微服务之间彼此独立部署，具有清晰的边界，服务间通过远程调用来构建复杂的业务功能。而服务注册中心在微服务项目中扮演着非常重要的角色。
注册中心是微服务架构中的纽带，类似于“通讯录”，它记录了服务和服务地址的映射关系。
在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址并进行调用。
注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的，更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。
因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。
核心功能
服务注册：服务实例将自身服务信息注册到注册中心；
服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供服务；
服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到；
注册中心解决的问题：

  • 屏蔽、解耦服务之间相互依赖的细节：
    • 服务之间的远程调用必须要知道对方IP、端口。但是将调用方式存在明显的问题，如被调用的IP、端口变化后，调用方也要同步修改。通过服务发现，将服务之间IP与端口的依赖转化为服务名的依赖，服务名可以根据具体微服务业务来做标识。
  • 对服务进行动态管理
    • 在微服务架构中，服务数量多且依赖错综复杂，无论是服务主动停止、意外挂掉，还是因为流量增加对服务扩容，这些服务状态上的动态变化，都需要尽快的通知到被调用方，被调用方才采取相应的措施。所以，对于服务注册中心要实时管理服务的数据与状态，包括服务的注册上线、服务主动下线，异常服务的剔除；
  • 降低服务端负载均衡中间件的压力：
    • 当服务越来越多时，服务URL配置管理变得非常困难，服务端负载均衡中间件，F5、Nginx压力越来越大。通过服务注册中心，就可以实现动态地注册和发现服务，使得服务的位置透明，并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对服务端的负载均衡中间件，也能减少部分成本。

服务的发现与注册的实现模式：

  • 服务端的发现模式：
    • 服务端的发现模式是通过使用一个中间的服务器，来屏蔽被调用服务的复杂性与变动性，当有新的服务加入或老服务剔除时，只需要修改中间服务器上的配置即可，此模式的显著特点是：引入独立的中间代理服务器来屏蔽真实服务的具体细节。image.png
    • 配置集中在独立的中间服务器端完成，对代码没有任何入侵，不存在跨平台语言的问题。但是所有的请求都需要穿透中间服务器，所以中间服务器会成为单点，对性能有影响。
  • 客户端的发现模式
    • 不需要通过中间服务，而是自己进程内维护了服务B的信息，再通过负载算法选择一个服务节点进行调用，引入服务注册中心，当服务A启动后会向注册中心注册自己的信息，然后服务B就会去注册中心上获取所有的注册服务，找到自己需要调用的服务即可；image.png
    • 不需要穿透中间服务器，性能消耗比较小，但是内部需要维护服务注册信息、负载算法等，有代码侵入，跨语言支持不太友好。

服务注册表
在微服务架构中，所有的服务启动后都通过注册中心来注册自己，同时把注册中心的服务信息拉取到本地，如果要调用其他服务时，直接检查本地的服务和节点信息进行服务节点的调用。每个服务节点都会来注册中心进行服务注册。这些注册信息都存在注册表中，服务注册的时候把自己的信息上报，注册中心把注册表返回到客户端，这样就可以感知其他的服务节点。
注册表需要随时更新，实现高可用。服务注册表中包含若干服务端，使用复制协议保持一致性。服务注册表不是单点的，否则会单点故障。当服务注册表有多台服务器时，需要考虑服务注册表的信息在多台机器上保持实时同步和一致。

常见的注册中心

Zookeeper
基于ZAP协议实现保证每个节点数据同步的问题，中心化思想集群模式，分为Leader和Follower。当zk的Leader因为某种原因宕机的情况下，会自动触发重新选一个新的领导角色，整个选举的过程为了保证数据的一致性问题，在选举的过程中整个zk环境是不可使用的。意味着微服务采用该模式情况下，可能无法实现通讯【本地缓存除外】。注意可运行的节点必须满足过半机制，zk遵从的是CP原则【一致性和容错性】；
结构
树形结构
zk一般维护的数据：客户端会话session状态，数据节点（dataNode）信息。
zk在内存中构造了DataTree的数据结构，维护着path到dataNode的映射以及dateNode间的树状层级关系。为了提高读取性能，集群中每个服务节点都是将数据全量存储在内存中，一般适用于读多写少且轻量级数据的应用场景；
持久节点：一旦创建，该数据节点会一直存储到zk服务器上，即使创建该节点的客户端与服务端的会话关闭了，该节点也不会被删除；
临时节点：当创建该节点的客户端会话因超时或发生异常而关闭时，该节点也相应的在zk上被删除。
Eureka
采用AP【可用性和容错性】的设计理念架构注册中心，完全去中心化思想，也就是没有主从之分，每个节点都是均等的，采用相互注册的原理，你中有我我中有你，只要最后有一个eureka节点存在就可以保证整个微服务可以实现通讯；
Nacos
同时支持AP和CP，默认是AP，与SpringCloud Alibaba兼容性好，同时支持K8S集成。集群保证一致性算法采用Raf协议模式，采用心跳机制实现选举的。