如何发布引用以及注册和发现服务

服务的发布和引用

要实现微服务，就要有服务，服务从那里来，要到哪里去。这个问题的答案是服务提供者发布一个服务，服务消费者引用一个服务。下面介绍一下最常见的三种

服务发布和引用的三种方式：

• RESTful API
• XML配置
• IDL文件

RESTful API 介绍
主要用作于HTTP和HTTPS协议的定义接口，由于HTTP协议是公开的协议，众人熟知。比较适合用于跨平台之间的服务协议。

XML配置 介绍
私有的RPC框架会选择使用XML配置这种方式。原因是私有的RPC协议比HTTP协议的性能要高。但是这种方式对业务代码的侵入比较高，XML配置变动的时候，服务提供者和服务消费者都需要更新配置。比较适合内部联系比较紧密的业务部门来使用

IDL文件 介绍
IDL是接口描述的语言，用中立的方式来描述接口，可以在不同平台上运行的对象和不同语言编写的程序可以互相通信交流。比较常见的为：Fecebook开源的Thrift和Google开源的gRPC。比较合适用作于跨语言平台服务之间相互调用。

总结

如果只是企业内部之间的服务调用，并且都是 Java 语言的话，选择 XML 配置方式是最简单的。如果企业内部存在多个服务，并且服务采用的是不同语言平台，建议使用 IDL 文件方式进行描述服务。如果还存在对外开放服务调用的情形的话，使用 RESTful API 方式则更加通用。

服务描述方式	使用场景	缺点
RESTful API	跨语言平台，组织内外皆可	使用了HTTP作为通信协议，相比TCP协议，性能较差
XML配置	Java平台，一般用作组织内部	不支持跨语言平台
IDL文件	跨语言平台，组织内外皆可	修改活着删除字段不能向前兼容

服务的注册和发现

注册中心原理

微服务架构中，服务发现组件是个非常关键的的组件，由服务提供者（RPC Server）、服务消费者（RPC Client）和注册中心（Registry）来完成，这三者的关系如下：

• RPC Server 提供服务，在启动时，根据服务发布文件 server.xml 中的配置的信息，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。
• RPC Client 调用服务，在启动时，根据服务引用文件 client.xml 中配置的信息，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。
• 当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地内存中缓存的服务节点列表。
• RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。

注册中心的功能

注册中心API：

• 服务注册接口
• 服务反注册接口
• 心跳汇报接口
• 服务订阅接口
• 服务变更查询接口
• 服务查询接口
• 服务修改接口

集群部署：

注册中心为服务提供者和服务消费者之间唯一的联系方式。一般采用集群部署来保障高可用性，并通过分布式一致性来确保集群中不同节点之间的数据保持一致性。

目录储存：

注册中心存储服务信息一般采用层次化的目录结构。

服务健康状态检测

具备对服务提供者的节点的健康状态检测功能，确保注册中心里面存储的服务节点都是可用的。

服务状态变更通知

一旦注册中心探测到服务提供者有新的节点加入或节点删除，需要通知所有订阅次服务的服务消费者，刷新本地缓存的服务节点信息，却不服务消费者调用不可用的服务节点。

白名单机制

确保服务在发布的时候，在多套环境下，不会出错。