微服务注册与发现

为什么需要注册中心？

微服务中面对的问题就是不同的服务之间如何进行通信？在单体服务中如果不同的服务之间需要通信，一般是服务将接口进行对外暴露，然后其他的服务通过 http 进行请求，那么在微服务中其实也可以这样。

但存在的问题在于单体服务中我们请求的目标是在请求的 url 中写死的，服务少可以这样。而微服务中需要考虑的是存在大量服务时手动维护服务列表是否合适？如果服务横向扩展时如何通知其他的服务？服务宕机后，如何及时下线等等问题。即如果没有注册中心，微服务会面临如下的两个重要问题：

所以此时注册中心就来了。

简单一句话来说注册中心是服务框架背后最基础的服务，用来记录各个服务的实例信息，决定业务服务是否正常调用。

注册中心主要有三种角色：注册中心、服务提供者、服务消费者。

三种角色之间的关系流程如下所示：

三者之间的关系可以通过下图来描述：

简单来说注册中心的主要功能就是保存服务的具体信息，然后由服务消费者读取这些信息。注册中心的存在是为了更好更方便的管理应用中的每一个服务。

服务中心主要提供如下几个功能：

服务注册表：是注册中心的核心，用来记录各个微服务实例的信息，例如微服务的名称、IP、端口等。
服务注册与发现：动态的增减服务节点，服务节点增减后动态的通知服务消费者，不需要由消费者来更新配置。服务注册是指微服务在启动时，将自己的信息注册到注册中心的过程；服务发现是指查询可用的微服务列表及网络地址的机制
服务配置：动态修改服务配置，并将其推送到服务提供者和服务消费者而不需要重启服务。
健康检查：注册中心使用一定的机制定时检测已注册的服务，如发现某实例长时间无法访问，就会从服务注册表移除该实例。及主动的检查服务健康情况，对于宕机的服务将其删除服务列表。

简单来说服务发现就是通过服务唯一标识来获取服务地址的过程，它在 RPC 里扮演了重要角色。即当服务提供者的信息发生变化，服务消费者无须修改配置文件。通过服务发现即可查询服务提供者信息。

具体是指使用一个注册中心来记录分布式系统中全部服务的信息，以便让其他服务能够快速找到这些已经注册的服务。服务发现可以让服务消费者在服务提供者的 IP 地址发生变化的时候能够快速及时地获取到最新的服务信息。

没有服务发现的话，服务网络位置信息的配置会耦合在具体服务消费者的配置当中，会导致系统难以维护。

业界常用的服务注册中心对比

指标	Consule	zookeeper	etcd	eureka
服务监控检测	服务状态,内存,硬盘	长连接 keepalived	连接心跳	需要配置
多数据中心	支持	不支持	不支持	不支持
KV 存储	支持	支持	支持	不支持
一致性	gossip	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 集成	已支持	已支持	已支持	已支持

Consul 与其他常见服务发现框架对比

名称	优点	缺点	接口	一致性算法
zookeeper	1.功能强大，不仅仅只是服务发现 2.提供 watcher 机制能实时获取服务提供者的状态 3.dubbo 等框架支持	1.没有健康检查 2.需在服务中集成 sdk，复杂度高 3.不支持多数据中心	sdk	Paxos
consul	1.简单易用，不需要集成 sdk 2.自带健康检查 3.支持多数据中心 4.提供 web 管理界面	1.不能实时获取服务信息的变化通知	http/dns	Raft
etcd	1.简单易用，不需要集成 sdk 2.可配置性强	1.没有健康检查 2.需配合第三方工具一起完成服务发现 3.不支持多数据中心	http	Raft