7大维度看国外企业为啥选择gRPC打造高性能微服务？

Bugsnag（注：一家云端bug监控服务商）天天处理数以亿计的错误信息，为了处理这些数据，考虑优先构建一个可扩展，性能强大的后端系统，并从中学到不少有挑战性的技术。最近，咱们推出了新版本的仪表板，这个项目要求扩展系统，来处理服务呼叫的显著增长，这些呼叫是跟踪用户发布和会话所需的。

仪表板的发布在进行中，工程团队将Bugsnag的后端功能分解成称之为管道（pipeline）的微服务体系。将管道扩展到支持发布，意味着增长新的服务，并修改现有服务，也可预见到许多新的服务器和客户端的交互。为了处理上述架构的变化，须要采用一致性的方式来设计，实施和集成企业的服务。Bugsnag是一家多语言的公司，服务是用Java，Ruby，Go和Node.js等多语言编写，所以企业须要一种与平台无关的方法。

本文将介绍为何咱们最终选择了gRPC做为Pipeline的默认通讯框架。

达到REST API设计的极限

现有系统传统上使用具备JSON有效载荷的REST API进行同步通讯。这种选择是基于占压倒性比例的成熟度、熟悉度和工具的可用性作出的，可是随着跨洲际工程团队的增加，企业须要设计一致的，基于RESTful API的工具。

不幸的是，这感受就像试图将简单的方法调用变成一个数据驱动的RESTful界面。这知足了RESTful接口的verb，header，URL标识符，资源的URL和有效载荷的神奇组合，并作了一个清洁，简单，看起来几乎不可能实现的功能界面。RESTful有不少规则和解释，在大多数状况下会致使REST ish接口，这须要花费额外的时间和精力来保持其纯度。

最终，考虑到RESTAPI的复杂性，咱们找到了替代方案。但愿微服务尽量相互隔离，减小交互和解耦服务。它可让企业在很短的时间内创造出一个可行的服务，并防止跳过hoops。

评估REST的替代方案

不要轻易选择通讯框架。大型组织（如Netflix）能够拥有超过500+个微服务的后端系统。迁移这些服务以取代不充分的服务间通讯会花费大量时间，从后勤和财务角度看这很不切实际。花时间从一开始就考虑正确的框架，能够省去不少将来的浪费。

咱们花了大量的时间来制定评估标准和研究、选择。Bugsnag到底长什么样子呢？

技术标准

在研究可用选项时，使用了一些特定的标准来评估。要考虑的事情是基于微服务架构的最有效的方法。主要目标是自由地使用通讯，消除通讯的复杂性，了解每项服务的责任所在。其中的一些技术问题是：

速度 - 对于大量的请求/响应API调用，须要将调用自己的延迟做为性能和用户响应速度的最小因素。延迟的主要组成部分是链接成本，传输成本和消息编码/解码时间。

基础架构兼容性 - 框架在基础架构中扮演的角色如何？主要是关于负载平衡和自动扩展？咱们使用托管在Google云端平台上的Kubernetes服务，所以须要框架来兼容这种环境。

开发工具 - 在实现框架时，提供尽量小的摩擦将会使开发人员更快捷。哪些工具能够帮助编码，本地测试端点，以及单元和集成测试的stubbing/mocking？当事情出错时，咱们须要可以看到包括内容在内的请求信息。消息格式等因素也可使调试更容易依赖于工具，例如JSON消息是人可读的，可是二进制消息将须要额外的努力来解码。

成熟度和采用 - 对于初创公司来讲，资源是有限的，须要花费在公司的核心业务上，而不是修复，测试和加强第三方框架。诸如框架的普及，大规模使用的例子，社区的活跃程度以及框架自己的成熟度等因素都是稳定性的良好指标。须要强调的是，选择一个解决具体问题的框架，而并不是选择最新最热的。

多平台支持 - 在真正的微服务思惟中，使用最适合其目的的语言编写企业的服务，目前包括Java，Ruby，Go和Node。框架是否为现有的语言选择提供了一流的支持，同时提供了用其余语言编写新服务的选项？

代码量 - 框架应该有助于下降工程成本。企业须要编写和维护多少代码才能使其工做？与业务逻辑相比，这是多少样板代码？

安全 - 全部的内部通讯都应该被认证和加密。咱们须要可以使用全部通讯的SSL / TLS（或等价物）。

设计上的考虑，并不是都与技术有关

服务API是最重要的接口之一，由于在开发过程当中对设置服务指望相当重要。解决服务API的设计是一项艰巨的任务，当不一样的团队负责所涉及的不一样服务时，该任务会被放大。最大限度地减小因为预期不匹配而浪费的时间和精力，与缩短编码时间同样有价值。因为Bugsnag拥有跨地区的工程团队，所以沟通时间有限。必须经过简化沟通，确保事情不用那么多解释，不然错误很容易产生，事情很容易被拖延。

如下是在选择框架时的一些设计考虑因素：

强类型 - 消息是不是强类型的？若是经过服务边界发送的消息清晰可见，那么能够消除因为类型而形成的设计和运行时错误。

打开解释 - 可以直接从服务API规范生成客户端库，减小了误解的问题。错误条件 - 有一套明肯定义的错误代码能够更容易一致地交流问题。

文档 - 服务API应该是易读易懂的。定义服务API的格式应该尽量清楚，准确地描述端点。

版本控制 - 更改是不可避免的，这是一个很好的选择，在某些时候，服务API将须要修改。所使用的消息传递格式和服务定义能够影响修改API并将其部署到生产的容易程度。是否有明确的路径来增长版本及其相应的库，并推出更改？

微服务最佳实践，为何可扩展性是重要的

除了上面列出的标准外，还须要选择一个易于扩展的框架。随着微服务的发展，企业须要愈来愈多的“开箱即用”功能，发展的同时，为系统增长了更多的复杂性。所以企业但愿的功能包括：

异常处理 - 在请求级别提供一个处理异常的机制。它容许捕获有关请求的重要上下文元数据，例如发出请求的用户，能够用例外报告。咱们使用Bugsnag轻松地监视这些异常。

智能重试 - 在特定条件下重试请求，例如仅在5xx状态码上。这包括支持各类退避策略，如指数退避。

服务发现配置 - 将通讯框架链接到流行的服务发现应用程序（如Zookeeper，Eureka或Consul）的选项能够提供一种快速简便的解决方案，以绕过企业的架构来请求路由。

度量、跟踪和日志记录 - 可观察性对于复杂的分布式系统是必不可少的，可是应该当心监视的内容。在服务边界自动收集指标和跟踪信息能够快速回答常见问题，例如“个人服务对请求响应缓慢吗？”以及“请求失败的频率如何？”。

熔断 - 这种模式能够经过自动检测问题和快速失败来防止级联服务故障。也能够由长时间缓慢的请求来触发，以提供响应降级的服务而不是不断地超时。

缓存和批处理 - 经过使用缓存或批处理请求来加速请求。

大多数框架不会提供全部功能，但至少它们应该是可扩展的，以便在须要时添加。

什么是gRPC和协议缓冲区？

没有一个框架是万能的。咱们探索的一些选项包括Facebook的Thrift，Apache Hadoop的Avro，Twitter的Finagle，甚至使用JSON模式。

咱们的需求更接近于远程程序调用（RPC），给予所须要的细粒度控制。使用RPC的另外一个吸引力是使用接口描述语言或IDL。IDL容许以独立于语言的格式描述服务API，将接口与任何特定的编程语言分离。他们能够提供一系列的好处，包括服务API的一个单一的事实来源，并可能被用来生成客户端和服务器代码来与这些服务进行交互。IDL的例子包括Thrift，Avro，CORBA，固然还有ProtocolBuffers。

最后，明确的获胜者是基于协议缓冲区的gRPC。

什么是gRPC？

咱们选择了gRPC，由于它知足了咱们的功能需求（包括将来的可扩展性），背后的活跃社区以及HTTP / 2框架的使用。

gRPC是由Google开发，设计用于传统的RPC调用。该框架使用最新的网络传输协议HTTP / 2，主要用于经过使用流的单个TCP链接来实现低延迟和多路复用请求。与REST over HTTP / 1.1相比，gRPC很是快速和灵活。

gRPC的性能对于设置管道来处理仪表板发布的大量增长相当重要。此外，HTTP / 2是下一个标准化的网络协议，能够利用为HTTP / 2开发的工具和技术（如Envoy代理），并为gRPC提供一流的支持。因为多路复用流支持，gRPC支持双向通讯，不限于简单的请求/响应呼叫。

什么是Protobufs（协议缓冲区）？

Protocol Buffers或protobufs是定义和序列化结构化数据为高效的二进制格式的一种方式，也是由Google开发的。两者的有效结合，也是咱们选择gRPC的主要缘由之一。

之前有许多与想修复的版本相关的问题。微服务意味着必须不断更新，须要适应并保持向前和向后兼容的接口，protobufs对此很是有用。因为是二进制格式，因此它们也是经过wire快速发送的小型有效载荷。

Protobuf消息使用关联的IDL进行描述，它提供了一个紧凑的，强类型的，向后兼容的格式来定义消息和RPC服务。咱们使用最新的proto3规范，并在此处显示protobuf消息的实际示例。

全部字段proto3都是可选的。若是未设置字段，将始终使用默认值。这与字段编号相结合提供了一个API，能够很是抵抗打破变化。经过遵循一些简单的规则，向前和向后兼容性能够成为大多数API更改的默认值。

protobuf格式还容许定义RPC服务自己。服务端点与消息结构共存，在单个protobuf文件中提供RPC服务的自包含定义。对于咱们的跨洲际的工程团队来讲，这很是有用，他们能够从一个文件中了解服务如何工做，生成客户端并开始使用它。如下是咱们的服务之一：

该框架可以生成代码来使用protobuf文件与这些服务进行交互，这是另外一个优点，它能够自动生成须要的全部类。这个生成的代码负责消息建模，并提供一个存根类，其中包含与您的服务端点相关的重复方法调用。

支持多种语言，包括C ++，Java，Python，Go，Ruby，C＃，Node，Android，Objective-C和PHP。可是，使用protobuf文件维护和同步生成的代码是个问题。咱们已经可以经过使用Protobuf文件自动生成客户端库来解决这个问题，会在即将发布的下一篇博客文章中分享更多的内容。

gRPC最好的特性之一是支持中间件模式，被称为拦截器。它容许扩展全部的gRPC实现（这对企业来讲很重要），可以轻松访问全部请求，从而实现本身的微服务最佳实践。gRPC还内置了对一系列认证机制的支持，包括SSL / TLS。

gRPC社区

咱们正处于gRPC采用的开始阶段，期待社区提供更多的工具和技术。很高兴可以加入这个充满活力的社区，并对将来的项目有一些想法，咱们但愿看到这些项目是开放源代码或咱们本身写的。

gRPC工具的当前状态

gRPC比较新，缺少可用的开发工具，特别是与经验丰富的REST over HTTP / 1.1协议相比。搜索教程和示例时，这一点尤为明显，由于只有少数有用的信息。二进制格式也使消息不透明，须要努力解码。虽然有一些选择，例如JSON代码转换器能够帮助，但预计须要作一些基础工做，以便为gRPC提供顺畅的开发体验。

咱们喜欢用Apiary 来记录外部API。使用服务协议缓冲区（protobuf）文件自动生成交互式文档的等价物，将是理想的有效的内部通讯gRPCAPI。protobuf文件的静态分析在运行时能捕获更多的bug。使用Checkstyle做为Java代码，而且把它用做相似于protobuf的文件。自定义拦截器能够提供跟踪，日志记录和错误监视功能。咱们但愿开源咱们的Bugsnag gRPC拦截器，以自动捕获并向Bugsnag报告错误。gRPC的增加和采用

在过去几年中，gRPC的普及度大幅增加，Square，Lyft，Netflix，Docker，Cisco和CoreOS等公司大规模采用。Netflix Ribbon是基于RPC调用使用REST的微服务通讯框架的事实标准。今年，他们宣布，因为其多语言支持和更好的可扩展性/可组合性，他们正在向gRPC过渡。该框架最近也于2017年3月加入了CNCF基金会，支持重量级的Kubernetes和Prometheus。gRPC社区很是活跃，与开源gRPC生态系统 列出了许多gRPC激动人心的项目。

另外，gRPC有咱们认同的原则

Lyft在转向gRPC方面作了大量的讨论，这与咱们的经验很是类似：使用Protocol Buffers和gRPC生成统一的API。值得一试。

gRPC如今还处于初期阶段，存在一些明显的磨合问题，但将来前景光明。总的来讲，咱们对gRPC如何整合到后端系统很是乐观，而且很高兴见证这个框架的发展。

原文连接：

https://blog.bugsnag.com/grpc...