2、微服务注册中心

一、服务注册中心基本概述

• 前面介绍的微服务相关知识可以知道，在微服务架构中，存在以下的挑战：

服务越来越多，配置管理复杂
服务间依赖关系复杂
服务之间的负载均衡
服务的拓展
服务监控
服务降级
服务鉴权
服务上线与下线
服务文档
… …

• 针对上述服务化产生的问题，必须要有一种解决方案，而这个解决方案就是服务治理。服务治理是微服务架构中最为核心和基础的模块，服务治理领域最重要的问题就是服务发现与注册，因此服务注册中心就显得非常重要。例如通过服务注册中心可以快速的实现集群的水平伸缩、快速将不可用的服务摘除等。

1、服务注册中心概念

注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。

服务注册中心

注册中心:用于服务端注册远程服务以及客户端发现服务
服务端:对外提供后台服务，将自己的服务信息注册到注册中心
客户端:从注册中心获取远程服务的注册信息，然后进行远程过程调用

2、服务注册中心主要功能

（1）服务注册 register

注册就是将服务的信息注册到注册中心，这里的信息主要是服务的 name、address、weight 信息。name 是服务的名字，address 是服务提供方的地址信息，包含 ip 和 port 信息，weight 是服务节点的权重信息，用来调节流量的，一般配合负载均衡模块一起使用。

（2）服务反注册 unregister

反注册说的是服务提供方机器下线、进程退出的的时候，能够提前将注册中心的相关节点信息删除或者通过相关状态标识出来，表明该服务节点已经不提供服务，这样调用方 Invoker 在发现服务的时候就可以排除掉这个节点，不会将请求发过来。

（3）服务订阅 subscribe

订阅说的是服务调用方，在调用前需要根据订阅服务的 name 从注册中心获取到所有相关服务的注册信息，比如 address、weight。这样在调用前就可以根据 address 信息进行网络连接，然后发起调用，以及根据 weight 来使用负载均衡来调节流量大小。

（4）服务通知 notify

通知说的是相关服务注册和反注册时，注册中心信息变更，能够主动通知到服务订阅方，这样服务订阅方就可以了解到是新增了服务机器节点，还是下线了服务节点，亦或是服务权重变更，这样方便调用方自动控制服务调用流量的流向以及大小。

（5）服务健康检测

定时检测服务提供者的健康情况

3、服务注册中心工作原理

1）服务提供者在启动时，根据发布文件中配置的服务发布消息像注册中心注册自己提供的服务

2）消费者在启动时，像注册中心订阅自己所需要的服务，消费者刷新自己的本地缓存路由表

3）注册中心返回服务提供者的地址列表给消费者，如果有变更，注册中心推送变更数据给消费者，消费者更新自己的本地缓存列表

4）服务消费者根据得到的服务提供者地址列表，基于负载均衡算法选择其中一台server为自己提供服务

4、服务注册中心设计要点

高可用、容错性、易用性（提供统一的抽象）、安全性、数据一致性问题、等

（1）高可用和可靠性

要求：
1）对等集群，一台宕机不影响服务使用
2）全部宕机，不影响服务，但是没办法注册新的服务或者下线服务
手段：
1）支持对等集群
2）通过长连接心跳检测服务提供者的健康状态

（2）安全性

1）链路的安全性:指的是服务中心对客户端进行安全认证，策略很多，最简单的就是基于IP的黑白名单校验，更加复杂的是基于用户名+密码的认证或者是基于秘钥+数字证书的认证
2）数据的安全性:主要是对数据进行权限控制，不同的人有不同的访问权限

（3）订阅发布机制

• 对服务的监听，内容变更时，可以收到注册中心的消息推送；服务提供者可以动态的修改服务名称、内容等可以将变更推送给监听它的消费者

（4）提供统一的抽象接口

• 客户端连接到注册中心之后要能够对注册中心的数据进行增(发布或订阅新的服务)删(去注册已发布的服务)改(修改已发布的服务属性，进行动态服务治理)查(查询当前系统的服务消息和订阅的消费者消息)等操作

二、注册中心分类

Feature	Consul	zookeeper	etcd	euerka
服务健康检查	服务状态，内存，硬盘等	(弱)长连接，keepalive	连接心跳	可配支持
多数据中心	支持	—	—	—
kv存储服务	支持	支持	支持	—
一致性	raft	paxos	raft	—
cap	ca	cp	cp	ap
使用接口(多语言能力)	支持http和dns	客户端	http/grpc	http（sidecar）
watch支持	全量/支持long polling	支持	支持 long polling	支持 long polling/大部分增量
自身监控	metrics	—	metrics	metrics
安全	acl /https	acl	https支持（弱）	—
spring cloud集成	已支持	已支持	已支持	已支持

• 服务的健康检查
  Euraka 使用时需要显式配置健康检查支持；Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。
• 多数据中心支持
  Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步；而且其他的产品则需要额外的开发工作来实现；
• KV 存储服务
  除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务，所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务，也能够较好的转化为动态配置服务哦。
• 产品设计中 CAP 理论的取舍
  Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。其次 CA 类型的场景 Consul,也能提供较高的可用性，并能 k-v store 服务保证一致性。 而Zookeeper,Etcd则是CP类型 牺牲可用性，在服务发现场景并没太大优势；
• 多语言能力与对外提供服务的接入协议
  Zookeeper的跨语言支持较弱，其他几款支持 http11 提供接入的可能。Euraka 一般通过 sidecar的方式提供多语言客户端的接入支持。Etcd 还提供了Grpc的支持。 Consul除了标准的Rest服务api,还提供了DNS的支持。
• Watch的支持（客户端观察到服务提供者变化）
  Zookeeper 支持服务器端推送变化，Eureka 2.0(正在开发中)也计划支持。 Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知；
• 自身集群的监控
  除了 Zookeeper ,其他几款都默认支持 metrics，运维者可以搜集并报警这些度量信息达到监控目的；
• 安全
  Consul,Zookeeper 支持ACL，另外 Consul,Etcd 支持安全通道https.
• Spring Cloud的集成
  目前都有相对应的 boot starter，提供了集成能力。总的来看，目前Consul 自身功能，和 spring cloud 对其集成的支持都相对较为完善，而且运维的复杂度较为简单（没有详细列出讨论），Eureka 设计上比较符合场景，但还需持续的完善。