服务器通信REST、gRPC，Swagger/OpenAPI，Consul

服务间的通信方式是在采用微服务架构时需要做出一个最基本的决策。默认的选项是通过 HTTP 发送 JSON，也就是所谓的 REST API。我们也是从 REST 开始的，但最近我们决定改用 gRPC。

gRPC是谷歌开发的一个远程调用框架，现在已开源。尽管它已经出现了多年，但网上关于人们为什么要用它或者为什么不用它的信息并不多。于是，我决定写这篇文章分享一下我们为什么要使用 gRPC。

gPRC 的一个很明显的优势是它使用了二进制编码，所以它比 JSON/HTTP 更快。虽然说速度越快越好，但我们也要考虑另外两个因素：清晰的接口规范和对流式传输的支持。

Swagger/OpenAPI

当然，如果使用的是 JSON/HTTP，Swagger或者OpenAPI也提供了类似的东西。下面的例子与上述的 gRPC API 相当。

流式传输

今年早些时候，我开始为我们的搜索服务设计一个新的 API。在我使用 JSON/HTTP 设计了第一版 API 之后，我的一个同事告诉我说，在某些情况下，我们需要流式传输搜索结果，也就是在有第一批结果时就开始传输。而我之前设计的 API 只返回一个单独的 JSON 数组，在服务器端收集到所有结果之前是不会向客户端发送任何数据的。

我们的 API 要求客户端轮询搜索结果，先是发送一个 POST 请求发起搜索，然后再不断发送 GET 请求获取搜索结果。响应消息中包含了一个用于表示搜索是否已完成的字段。这种方式虽然没有什么问题，但还不够优雅，而且要求服务器端将中间结果保存在数据存储（如 Redis）中。

注意事项

gRPC 也有一些不足之处，不过它们都与相关的开发工具有关，并不是 gRPC 本身的问题。

如果我们使用 JSON/HTTP 开发 API，就可以使用 curl、httpie 或者 Postman 进行简单的手动测试。gRPC 也有一个类似的工具叫作grpcurl，不过它使用起来并不是很方便，你要么需要在服务器端添加gRPC 服务器反射插件，要么需要在每个命令后面附上.proto 文件。

另一个是 Kubernetes 负载均衡器问题，负载均衡器可以支持 HTTP，但对 gPRC 支持得并不好。gPRC 要求应用层的负载均衡，而不是在 TCP 连接层。为了解决这个问题，我们参考了这篇文章搭建了 Linkerd。

Consul 是 HashiCorp 出品的开源服务发现工具。

Consul 提供了诸如服务发现，健康检查，KV 数据库等功能，方便你使用它构建自己的服务集群。

基础概念

Agent: agent 就是实际运行的 consul 服务，启动时可选以 server 或者 client 模式运行，每个集群至少有 1 个 server，由于使用了 Raft 算法，所以对于每个集群你应该把它的 server 数设置成 3 或 5 个。

Server: 核心的 consul 服务，存储了所有服务注册的信息，响应查询操作，跨数据中心通信等。

Client: 用来在集群中每个机器上运行，进行服务注册 / 健康检查的进程。

Cluster: 集群，由多台共同提供服务的机器组成的集合称为集群，agent 在集群的每个成员上都要运行。

DataCenter: 数据中心。consul 支持跨数据中心组成集群。

Node: 安装了 agent，接入集群的机器称为 node。

Service: 你的服务，即服务注册和服务发现之类操作的对象。通过提供 config 文件或者调用 consul 的 HTTP API 来定义一个服务。