微服务中的服务注册与发现

背景知识

服务注册 & 发现

服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。
服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

CAP

CAP原则，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。

一致性(Consistency)：它要求在同一时刻点，分布式系统中的所有数据备份都处于同一状态。
可用性(Availability)：在系统集群的一部分节点宕机后，系统依然能够响应用户的请求。
分区容错性(Partition Tolerance)：在网络区间通信出现失败，系统能够容忍。

一般来讲，基于网络的不稳定性，分布容错是不可避免的，所以我们默认CAP中的P总是成立的。
所以我们只能选择 CP 系统 或者是 AP 系统。

几种实现

AP 系统

因为AP系统牺牲了一致性，从而获得了更好的可用性，表现在

• 单机数据可丢失，从而因此架构简单，软件可靠性高
• 单机的性能好，并发量高

Eureka

Eureka采用的是Server/Client的模式进行设计。Server扮演了服务注册中心的角色，为Client提供服务注册和发现的功能，维护着注册到自身的Client的相关信息，同时提供接口给Client获取到注册表中其他服务的信息。Client将有关自己的服务的信息通过一定的方式登记到Server上，并在正常范围内维护自己信息的一致性，方便其他服务发现自己，同时可以通过Server获取到自己的依赖的其他服务信息，从而完成服务调用。

Eureka中没有使用任何的数据强一致性算法保证不同集群间的Server的数据一致，仅通过数据拷贝的方式争取注册中心数据的最终一致性，虽然放弃数据强一致性但是换来了Server的可用性，降低了注册的代价，提高了集群运行的健壮性。

CP 系统

AP系统牺牲了可用性，从而获得更好的一致性，表现在

• 发现延迟较低
• 用户感知低

ETCD

etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。

CONSUL

Consul是一个服务网格（微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控）解决方案，它是一个一个分布式的，高度可用的系统，而且开发使用都很简便。它提供了一个功能齐全的控制平面，主要特点是：服务发现、健康检查、键值存储、安全服务通信、多数据中心。

实际应用

AP or CP

从实际的应用的场景看，极大规模的微服务系统因为组件极多且经常变化可能会选择 AP 系统，对于大部分用户来说选择 CP 系统是更常见的选择，首先因为微服务系统内的组件是一个相对固定不变的数量，因此微服务系统内部的服务注册中心的数量也是稳定的。

扩展性

Eureka是其中最差的，因为本身有服务的概念，导致在后续的拓展中是处处受阻的，因此在后续的服务发现的实现中，对于注册数据的筛选使用元数据的方式更为的合理。

采用类SQL的模式是相对比较的好的选择。

混合模式

对于中等规模的用户来说，更多的时候我们需要混合使用此模式，对于一些量大不敏感且可重试的附件，我们采用AP模式：比如视频目录服务等。而对于比较敏感的服务比如和金额相关的，建议使用CP模式。可喜的是有了部分如此组件的尝试，比如 nacos

*中间层

不同服务发现之间，因为协议的不同导致在后续的切换过程中需要更换客户端 client sdk，因此建议

• 使用服务端负债均衡 / ServiceMesh
• 增加独立抽象层