服务间的通信方式是在采用微服务架构时需要做出一个最基本的决策。默认的选项是通过 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。