服务注册和发现 服务注册和发现的基本原理 服务定义是服务提供者和服务消费者之间的约定，但是在微服务架构中，如何达成这个约定呢？这就依赖于服务注册和发现机制。
注册和发现的角色 在微服务架构下，服务注册和发现机制中主要有三种角色：
服务提供者 （RPC Server / Provider）服务消费者 （RPC Client / Consumer）服务注册中心 （Registry）
服务发现通常依赖于注册中心 来协调服务发现的过程，其步骤如下：
服务提供者将接口信息注册到注册中心。
服务消费者从注册中心读取和订阅服务提供者的地址信息。
如果有可用的服务，注册中心会主动通知服务消费者。
服务消费者根据可用服务的地址列表，调用服务提供者的接口。
这个过程很像是生活中的房屋租赁，房东将租房信息挂到中介公司，房客从中介公司查找租房信息。房客如果想要租房东的房子，通过中介公司牵线搭桥，联系上房东，双方谈妥签订协议，就可以正式建立起租赁关系。
主流的服务注册与发现的解决方案，主要有两种：
应用内注册与发现 ：注册中心提供服务端和客户端的 SDK，业务应用通过引入注册中心提供的 SDK，通过 SDK 与注册中心交互，来实现服务的注册和发现。应用外注册与发现 ：业务应用本身不需要通过 SDK 与注册中心打交道，而是通过其他方式与注册中心交互，间接完成服务注册与发现。
应用内注册与发现 应用内注册与发现 方案是：注册中心提供服务端和客户端的 SDK，业务应用通过引入注册中心提供的 SDK，通过 SDK 与注册中心交互，来实现服务的注册和发现。最典型的案例要属 Netflix 开源的 Eureka，官方架构图如下：
Eureka 的架构主要由三个重要的组件组成：
Eureka Server ：注册中心的服务端，实现了服务信息注册、存储以及查询等功能。服务端的 Eureka Client ：集成在服务端的注册中心 SDK，服务提供者通过调用 SDK，实现服务注册、反注册等功能。客户端的 Eureka Client ：集成在客户端的注册中心 SDK，服务消费者通过调用 SDK，实现服务订阅、服务更新等功能。
应用外注册与发现 应用外注册与发现 方案是：业务应用本身不需要通过 SDK 与注册中心打交道，而是通过其他方式与注册中心交互，间接完成服务注册与发现。最典型的案例是开源注册中心 Consul。
Consul 实现应用外服务注册和发现主要依靠三个重要的组件：
Consul：注册中心的服务端，实现服务注册信息的存储，并提供注册和发现服务。
Registrator ：一个开源的第三方服务管理器项目，它通过监听服务部署的 Docker 实例是否存活，来负责服务提供者的注册和销毁。Consul Template ：定时从注册中心服务端获取最新的服务提供者节点列表并刷新 LB 配置（比如 Nginx 的 upstream），这样服务消费者就通过访问 Nginx 就可以获取最新的服务提供者信息。
注册中心的基本功能 从服务注册和发现的流程，可以看出，注册中心是服务发现的核心组件 。常见的注册中心组件有：Nacos、Consul、Zookeeper 等。
注册中心的实现主要涉及几个问题：注册中心需要提供哪些接口，该如何部署；如何存储服务信息；如何监控服务提供者节点的存活；如果服务提供者节点有变化如何通知服务消费者，以及如何控制注册中心的访问权限。
元数据定义 构建微服务的首要问题是：服务提供者和服务消费者通信时，如何达成共识。具体来说，就是这个服务的接口名是什么？调用这个服务需要传递哪些参数？接口的返回值是什么类型？以及一些其他接口描述信息。
常见的定义服务元数据的方式有：
XML 文件 - 如果只是企业内部之间的服务调用，并且都是 Java 语言的话，选择 XML 配置方式是最简单的。IDL 文件 - 如果企业内部存在多个跨语言服务，建议使用 IDL 文件方式进行描述服务。REST API - 如果存在对外开放服务调用的情形的话，使用 REST API 方式则更加通用。
XML 文件 XML 配置方式通过在服务提供者和服务消费者之间维持一份对等的 XML 配置文件，来保证服务消费者按照服务提供者的约定来进行服务调用 。在这种方式下，如果服务提供者变更了接口定义，不仅需要更新服务提供者加载的接口描述文件 server.xml，还需要同时更新服务消费者加载的接口描述文件 client.xml。但这种方式对业务代码侵入性比较高，XML 配置有变更的时候，服务消费者和服务提供者都要更新，所以适合公司内部联系比较紧密的业务之间采用。支持 XML 文件的主流 RPC 有：阿里的 Dubbo （XML 配置示例：基于 Spring XML 开发微服务应用 ）、微博的 Motan。
XML 文件这种方式的服务发布和引用主要分三个步骤：
（1）服务提供者定义接口，并实现接口。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 service DemoService { rpc sayHello (HelloRequest) returns (HelloReply) {} } message HelloRequest { string name = 1 ; } message HelloReply { string message = 1 ; }
（2）服务提供者进程启动时，通过加载 xml 配置文件将接口暴露出去。
1 2 3 4 5 6 7 8 9 10 11 <beans xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo ="http://dubbo.apache.org/schema/dubbo" xmlns ="http://www.springframework.org/schema/beans" xsi:schemaLocation ="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd" > <dubbo:application name ="demo-provider" /> <dubbo:registry address ="zookeeper://127.0.0.1:2181" /> <dubbo:protocol name ="dubbo" port ="20890" /> <bean id ="demoService" class ="org.apache.dubbo.samples.basic.impl.DemoServiceImpl" /> <dubbo:service interface ="org.apache.dubbo.samples.basic.api.DemoService" ref ="demoService" /> </beans >
（3）服务消费者进程启动时，通过加载 xml 配置文件来引入要调用的接口。
1 2 3 4 5 6 7 8 9 <beans xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo ="http://dubbo.apache.org/schema/dubbo" xmlns ="http://www.springframework.org/schema/beans" xsi:schemaLocation ="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd" > <dubbo:application name ="demo-consumer" /> <dubbo:registry group ="aaa" address ="zookeeper://127.0.0.1:2181" /> <dubbo:reference id ="demoService" check ="false" interface ="org.apache.dubbo.samples.basic.api.DemoService" /> </beans >
IDL 文件 IDL 就是接口描述语言（interface description language）的缩写，通过一种中立、通用的方式来描述接口，使得在不同的平台上运行的对象和不同语言编写的程序可以相互通信交流。也就是说，IDL 主要用于跨语言的服务之间的调用 。支持 IDL 文件的主流 RPC 有：阿里的 Dubbo （XML 配置示例：IDL 定义跨语言服务 ），Facebook 的 Thrift ，Google 的 gRPC 。
以 gRPC 协议为例，gRPC 协议使用 Protobuf 简称 proto 文件来定义接口名、调用参数以及返回值类型。比如文件 helloword.proto 定义了一个接口 SayHello 方法，它的请求参数是 HelloRequest，它的返回值是 HelloReply。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {} rpc SayHelloAgain (HelloRequest) returns (HelloReply) {} } message HelloRequest { string name = 1 ; } message HelloReply { string message = 1 ; }
假如服务提供者使用的是 Java 语言，那么利用 protoc 插件即可自动生成 Server 端的 Java 代码。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 private class GreeterImpl extends GreeterGrpc .GreeterImplBase { @Override public void sayHello (HelloRequest req, StreamObserver<HelloReply> responseObserver) { HelloReply reply = HelloReply.newBuilder().setMessage("Hello " + req.getName()).build(); responseObserver.onNext(reply); responseObserver.onCompleted(); } @Override public void sayHelloAgain (HelloRequest req, StreamObserver<HelloReply> responseObserver) { HelloReply reply = HelloReply.newBuilder().setMessage("Hello again " + req.getName()).build(); responseObserver.onNext(reply); responseObserver.onCompleted(); } }
假如服务消费者使用的也是 Java 语言，那么利用 protoc 插件即可自动生成 Client 端的 Java 代码。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 public void greet (String name) { logger.info("Will try to greet " + name + " ..." ); HelloRequest request = HelloRequest.newBuilder().setName(name).build(); HelloReply response; try { response = blockingStub.sayHello(request); } catch (StatusRuntimeException e) { logger.log(Level.WARNING, "RPC failed: {0}" , e.getStatus()); return ; } logger.info("Greeting: " + response.getMessage()); try { response = blockingStub.sayHelloAgain(request); } catch (StatusRuntimeException e) { logger.log(Level.WARNING, "RPC failed: {0}" , e.getStatus()); return ; } logger.info("Greeting: " + response.getMessage()); }
假如服务消费者使用的是其他语言，也可以利用相应的插件生成代码。
由此可见，gRPC 协议的服务描述是通过 proto 文件来定义接口的，然后再使用 protoc 来生成不同语言平台的客户端和服务端代码，从而具备跨语言服务调用能力。
有一点特别需要注意的是，在描述接口定义时，IDL 文件需要对接口返回值进行详细定义。如果接口返回值的字段比较多，并且经常变化时，采用 IDL 文件方式的接口定义就不太合适了。一方面可能会造成 IDL 文件过大难以维护，另一方面只要 IDL 文件中定义的接口返回值有变更，都需要同步所有的服务消费者都更新，管理成本就太高了。
REST API REST API 方式主要被用作 HTTP 或者 HTTPS 协议的接口定义，即使在非微服务架构体系下，也被广泛采用。由于 HTTP 本身就是公开标准网络协议，所以几乎没有什么额外学习成本。支持 REST API 的主流 RPC 有：Eureka，下面以 Eureka 为例。
服务提供者定义接口
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 @RestController public class ProviderController { private final DiscoveryClient discoveryClient; public ProviderController (DiscoveryClient discoveryClient) { this .discoveryClient = discoveryClient; } @GetMapping("/send") public String send () { String services = "Services: " + discoveryClient.getServices(); System.out.println(services); return services; } }
服务消费者消费接口
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 @RestController public class ConsumerController { private final LoadBalancerClient loadBalancerClient; private final RestTemplate restTemplate; public ConsumerController (LoadBalancerClient loadBalancerClient, RestTemplate restTemplate) { this .loadBalancerClient = loadBalancerClient; this .restTemplate = restTemplate; } @GetMapping("/recv") public String recv () { ServiceInstance serviceInstance = loadBalancerClient.choose("eureka-provider" ); String url = "http://" + serviceInstance.getHost() + ":" + serviceInstance.getPort() + "/send" ; System.out.println(url); return restTemplate.getForObject(url, String.class); } }
元数据存储 注册中心本质上是一个用于保存元数据的分布式存储。你如果明白了这一点，就会了解实现一个注册中心的所有要点都是围绕这个目标去构建的。
想要构建微服务，首先要解决的问题是，服务提供者如何发布一个服务，服务消费者如何引用这个服务。具体来说，就是这个服务的接口名是什么？调用这个服务需要传递哪些参数？接口的返回值是什么类型？以及一些其他接口描述信息。
服务的元数据信息 通常有以下信息：
服务节点信息，如 IP、端口等。
接口定义，如接口名、请求参数、响应参数等。
请求失败的重试次数
序列化方式
压缩方式
通信协议
等等
在具体存储时，注册中心一般会按照“服务 - 分组 - 节点信息”的层次化的结构 来存储。以 ZooKeeper 为例：
在 ZooKeeper 中，数据按目录层级存储，每个目录叫作 znode，并且其有一个唯一的路径标识。
znode 可以包含数据和子 znode。
znode 中的数据可以有多个版本，比如某一个 znode 下存有多个数据版本，那么查询这个路径下的数据需带上版本信息。
注册中心 API 既然是分布式存储，势必要提供支持读写数据的接口，也就是 API，一般来说，需要支持以下功能：
服务注册接口 ：服务提供者通过调用服务注册接口来完成服务注册。服务反注册接口 ：服务提供者通过调用服务反注册接口来完成服务注销。心跳汇报接口 ：服务提供者通过调用心跳汇报接口完成节点存活状态上报。服务订阅接口 ：服务消费者通过调用服务订阅接口完成服务订阅，获取可用的服务提供者节点列表。服务变更查询接口 ：服务消费者通过调用服务变更查询接口，获取最新的可用服务节点列表。
除此之外，为了便于管理，注册中心还必须提供一些后台管理的 API，例如：
服务查询接口 ：查询注册中心当前注册了哪些服务信息。服务修改接口 ：修改注册中心中某一服务的信息。
服务健康检测 注册中心除了要支持最基本的服务注册和服务订阅功能以外，还必须具备对服务提供者节点的健康状态检测功能，这样才能保证注册中心里保存的服务节点都是可用的。注册中心通常使用长连接或心跳探测方式检查服务健康状态 。
还是以 ZooKeeper 为例，它是基于 ZooKeeper 客户端和服务端的长连接和会话超时控制机制，来实现服务健康状态检测的。在 ZooKeeper 中，客户端和服务端建立连接后，会话也随之建立，并生成一个全局唯一的 Session ID。服务端和客户端维持的是一个长连接，在 SESSION_TIMEOUT 周期内，服务端会检测与客户端的链路是否正常，具体方式是通过客户端定时向服务端发送心跳消息（ping 消息），服务器重置下次 SESSION_TIMEOUT 时间。如果超过 SESSION_TIMEOUT 后服务端都没有收到客户端的心跳消息，则服务端认为这个 Session 就已经结束了，ZooKeeper 就会认为这个服务节点已经不可用，将会从注册中心中删除其信息。
服务状态变更通知 一旦注册中心探测到有服务提供者节点新加入或者被剔除，就必须立刻通知所有订阅该服务的服务消费者，刷新本地缓存的服务节点信息，确保服务调用不会请求不可用的服务提供者节点。注册中心通常基于服务状态订阅来实现服务状态变更通知。
继续以 ZooKeeper 为例，基于 ZooKeeper 的 Watcher 机制，来实现服务状态变更通知给服务消费者的。服务消费者在调用 ZooKeeper 的 getData 方法订阅服务时，还可以通过监听器 Watcher 的 process 方法获取服务的变更，然后调用 getData 方法来获取变更后的数据，刷新本地缓存的服务节点信息。
集群部署 注册中心作为服务提供者和服务消费者之间沟通的桥梁，它的重要性不言而喻。所以注册中心一般都是采用集群部署来保证高可用性，并通过分布式一致性协议来确保集群中不同节点之间的数据保持一致。根据 CAP 理论 ，三种特性无法同时达成，必须在可用性和一致性之间做取舍。于是，根据不同侧重点，注册中心可以分为 CP 和 AP 两个阵营：
CP 型注册中心 - 牺牲可用性来换取数据强一致性 ，最典型的例子就是 ZooKeeper，etcd，Consul 了。ZooKeeper 集群内只有一个 Leader，而且在 Leader 无法使用的时候通过算法选举出一个新的 Leader。这个 Leader 的目的就是保证写信息的时候只向这个 Leader 写入，Leader 会同步信息到 Followers，这个过程就可以保证数据的强一致性。但如果多个 ZooKeeper 之间网络出现问题，造成出现多个 Leader，发生脑裂的话，注册中心就不可用了。而 etcd 和 Consul 集群内都是通过 Raft 协议来保证强一致性，如果出现脑裂的话， 注册中心也不可用。AP 型注册中心 - 牺牲一致性（只保证最终一致性）来换取可用性 ，最典型的例子就是 Eureka 了。对比下 Zookeeper，Eureka 不用选举一个 Leader，每个 Eureka 服务器单独保存服务注册地址，因此有可能出现数据信息不一致的情况。但是当网络出现问题的时候，每台服务器都可以完成独立的服务。
以开源注册中心 ZooKeeper 为例，ZooKeeper 集群中包含多个节点，服务提供者和服务消费者可以同任意一个节点通信，因为它们的数据一定是相同的，这是为什么呢？这就要从 ZooKeeper 的工作原理说起：
每个 Server 在内存中存储了一份数据，Client 的读请求可以请求任意一个 Server。
ZooKeeper 启动时，将从实例中选举一个 leader（Paxos 协议）。
Leader 负责处理数据更新等操作（ZAB 协议）。
一个更新操作成功，当且仅当大多数 Server 在内存中成功修改 。
通过上面这种方式，ZooKeeper 保证了高可用性以及数据一致性。
注册中心的扩展功能 多注册中心 对于服务消费者来说，要能够同时从多个注册中心订阅服务；
对于服务提供者来说，要能够同时向多个注册中心注册服务。
并行订阅服务 如果只支持串行订阅，如果服务消费者订阅的服务较多，并且某些服务节点的初始化连接过程中出现连接超时的情况，则后续所有的服务节点的初始化连接都需要等待它完成，这就会导致消费者启动非常慢。
可以每订阅一个服务就单独用一个线程来处理，这样的话即使遇到个别服务节点连接超时，其他服务节点的初始化连接也不受影响，最慢也就是这个服务节点的初始化连接耗费的时间，最终所有服务节点的初始化连接耗时控制在了 30 秒以内。
批量注销服务 在与注册中心的多次交互中，可能由于网络抖动、注册中心集群异常等原因，导致个别调用失败。对于注册中心来说，偶发的注册调用失败对服务调用基本没有影响，其结果顶多就是某一个服务少了一个可用的节点。但偶发的反注册调用失败会导致不可用的节点残留在注册中心中，变成“僵尸节点”。
需要定时去清理注册中心中的“僵尸节点”，如果支持批量注销服务，就可以一次调用就把该节点上提供的所有服务同时注销掉。
服务变更信息增量更新 为了减少服务消费者从注册中心中拉取的服务可用节点信息的数据量，这个时候可以通过增量更新的方式，注册中心只返回变化的那部分节点信息。尤其在只有少数节点信息变更时，此举可以大大减少服务消费者从注册中心拉取的数据量，从而最大程度避免产生网络风暴 。
心跳开关保护机制 在网络频繁抖动的情况下，注册中心中可用的节点会不断变化，这时候服务消费者会频繁收到服务提供者节点变更的信息，于是就不断地请求注册中心来拉取最新的可用服务节点信息。当有成百上千个服务消费者，同时请求注册中心获取最新的服务提供者的节点信息时，可能会把注册中心的带宽给占满，尤其是注册中心是百兆网卡的情况下。
所以针对这种情况，需要一种保护机制，即使在网络频繁抖动的时候，服务消费者也不至于同时去请求注册中心获取最新的服务节点信息 。
我曾经就遇到过这种情况，一个可行的解决方案就是给注册中心设置一个开关，当开关打开时，即使网络频繁抖动，注册中心也不会通知所有的服务消费者有服务节点信息变更，比如只给 10% 的服务消费者返回变更，这样的话就能将注册中心的请求量减少到原来的 1/10。
当然打开这个开关也是有一定代价的，它会导致服务消费者感知最新的服务节点信息延迟，原先可能在 10s 内就能感知到服务提供者节点信息的变更，现在可能会延迟到几分钟，所以在网络正常的情况下，开关并不适合打开；可以作为一个紧急措施，在网络频繁抖动的时候，才打开这个开关。
服务节点摘除保护机制 服务提供者在进程启动时，会注册服务到注册中心，并每隔一段时间，汇报心跳给注册中心，以标识自己的存活状态。如果隔了一段固定时间后，服务提供者仍然没有汇报心跳给注册中心，注册中心就会认为该节点已经处于“dead”状态，于是从服务的可用节点信息中移除出去。
如果遇到网络问题，大批服务提供者节点汇报给注册中心的心跳信息都可能会传达失败，注册中心就会把它们都从可用节点列表中移除出去，造成剩下的可用节点难以承受所有的调用，引起“雪崩”。但是这种情况下，可能大部分服务提供者节点是可用的，仅仅因为网络原因无法汇报心跳给注册中心就被“无情”的摘除了。
这个时候就需要根据实际业务的情况，设定一个阈值比例，即使遇到刚才说的这种情况，注册中心也不能摘除超过这个阈值比例的节点 。
这个阈值比例可以根据实际业务的冗余度来确定，我通常会把这个比例设定在 20%，就是说注册中心不能摘除超过 20% 的节点。因为大部分情况下，节点的变化不会这么频繁，只有在网络抖动或者业务明确要下线大批量节点的情况下才有可能发生。而业务明确要下线大批量节点的情况是可以预知的，这种情况下可以关闭阈值保护；而正常情况下，应该打开阈值保护，以防止网络抖动时，大批量可用的服务节点被摘除。
白名单机制 在实际的微服务测试和部署时，通常包含多套环境，比如生产环境一套、测试环境一套。开发在进行业务自测、测试在进行回归测试时，一般都是用测试环境，部署的 RPC Server 节点注册到测试的注册中心集群。但经常会出现开发或者测试在部署时，错误的把测试环境下的服务节点注册到了线上注册中心集群，这样的话线上流量就会调用到测试环境下的 RPC Server 节点，可能会造成意想不到的后果。
为了防止这种情况发生，注册中心需要提供一个保护机制，你可以把注册中心想象成一个带有门禁的房间，只有拥有门禁卡的 RPC Server 才能进入。在实际应用中，注册中心可以提供一个白名单机制，只有添加到注册中心白名单内的 RPC Server，才能够调用注册中心的注册接口，这样的话可以避免测试环境中的节点意外跑到线上环境中去。
静态注册中心 因为服务提供者是向服务消费者提供服务的，服务是否可用，服务消费者应该比注册中心更清楚。因此，可以直接在服务消费者端，根据调用服务提供者是否成功来判定服务提供者是否可用。如果服务消费者调用某一个服务提供者节点连续失败超过一定次数，可以在本地内存中将这个节点标记为不可用。并且每隔一段固定时间，服务消费者都要向标记为不可用的节点发起保活探测，如果探测成功了，就将标记为不可用的节点再恢复为可用状态，重新发起调用。
参考资料
