【翻译】gRPC 的动机和设计原则

原文: https://grpc.io/blog/principles/

动机

十多年来，Google 一直在使用一个名为 Stubby 的通用 RPC 基础设施来连接数据中心内和跨数据中心运行的大量微服务。我们的内部系统长期以来一直采用今天流行的微服务架构。拥有统一的跨平台 RPC 基础架构可以在整个组织范围内推广效率、安全性、可靠性和行为分析，这对于支持该时期令人难以置信的增长至关重要。

Stubby 有许多很棒的特性——但是，它不基于任何标准，并且与我们的内部基础设施耦合太紧密，不适合公开发布。随着 SPDY、HTTP/2 和 QUIC 的出现，许多相同的特性已经出现在公共标准中，以及 Stubby 不提供的其他特性。很明显，是时候重新设计 Stubby 以利用标准化技术，并将其扩展到移动、物联网和云的使用场景下。

原则和需求

采用服务而非对象，采用消息而非引用

推广系统间粗粒度消息交换的微服务设计理念，同时避免分布式对象的陷阱和无视网络的谬误。

覆盖率和简单性

该技术栈应该在每个流行的开发平台上都可用，并且人们可以轻松地为他们选择的平台构建。 它在 CPU 和内存有限的设备上应该是可以使用的。

自由和开放

让所有人自由使用所有基本功能。 将所有工件作为开源工作发布，并带有应促进而不是阻碍采用的许可证。

互操作性和可达性

有线网络协议必须能够穿越常见的互联网基础设施。

通用性和高性能

与特定于场景的技术栈相比，该技术栈应适用于广泛的场景，同时几乎不会牺牲性能。

分层

技术栈的关键方面必须能够独立发展。 对格式的修订不应破坏应用层绑定。

消息内容不可知

协议和实现必须允许不同的服务使用不同的消息类型和编码，例如protocol buffers、JSON、XML和Thrift。 同样，数据压缩的需求因用例和数据类型而异：协议应允许可插拔的压缩机制。

使用流

存储系统依靠流和流控制来传输大型数据集。其他服务，如语音到文本或股票行情，依靠流来表示时间相关的消息序列。

阻塞和非阻塞

支持客户端和服务器交换的消息序列的异步和同步处理。 这对于在某些特定平台上的伸缩和流处理至关重要。

撤销和超时

运维是昂贵且长期的——撤销允许服务器在客户端运行良好时回收资源。当跟踪工作中的调用链时，可能会出现级联撤销。客户端可能会提示调用超时，这允许服务根据客户端的需要调整行为。

优雅关闭

必须允许服务器通过拒绝新请求而优雅地关闭，并同时继续处理正在进行的请求。

流控制

客户端和服务器之间的计算能力和网络带宽往往不平衡。流控制允许更好的缓冲区管理以及对过度活跃的对端提供 DOS 保护。

可插拔

协议只是功能性 API 基础设施的一部分。 大型分布式系统需要安全、健康检查、负载平衡和故障转移、监控、跟踪、日志记录等。 其实现应当提供扩展点以允许这些功能的插拔，并提供默认实现。

作为 API 扩展

服务之间必要协作的扩展应该尽可能使用 API 而不是通过协议。这类的扩展可能包括健康检查、服务自省、负载监控和负载均衡分配。

元数据交换

常见的横切关注点，如身份验证或跟踪，依赖于不属于服务接口声明的数据交换。部署依赖于它们以不同于服务暴露的单个API的速度演进这些特性的能力。

标准化状态码

客户端通常以数量有限的方式响应 API 调用返回的错误。应当限制状态代码的命名空间以使处理这些错误的策略更清晰。 如果需要支持丰富的领域特定状态，则可以使用元数据交换机制来提供。

（完）