微服务架构与 gRPC 和 REST 的集成挑战
本文翻译 RakeshGirijaRamesanNair 和 InfosysLimited的发表的文章，译者能力有限，翻译不当处请见谅。
摘要：本博客旨在解释 gRPC 和 REST 等技术为 E2E 微服务架构带来的集成挑战。它总结了当前在实现微服务时存在的明显的问题，主要包括
服务之间的内部通信
外部第三方系统调用
它还从任何可用的开源框架中提供了关于跨技术堆栈缺乏标准化解决方案的独特见解。
介绍
微服务架构的采用率正在上升，并因其带来的灵活性（包括可维护性和可扩展性）而被广泛接受。随着容器化，微服务架构变得更加强大，允许用户创建专注于其功能而不是解决依赖关系的应用程序。云原生应用程序开发由使用容器的微服务架构提供支持。
分布式系统设计复杂，并且随着业务需求的不同性质而变得更加复杂为了实现端到端业务能力，需要互连或调用多个微服务。集成技术的选择变得至关重要，目前采用的常用方法是远程过程调用 gRPC（Google 远程过程调用）和任何面向客户端 REST（代表性状态传输）API。
gRPC – 遵循 RPC API 实现，利用 HTTP 2.0 协议和协议缓冲区进行消息交换。
REST – 架构遵循 HTTP 协议，用于消息传递的数据格式是 JSON 或 XML
问题陈述
设计和开发需要面对由服务在内部调用以及外部第三方系统调用的挑战
让我们考虑一个由订单管理器和产品库存微服务组成的订单管理系统的示例场景。
产品库存服务包含所有产品详细信息及其关系，包括各种类别。需要 REST API 将产品详细信息及其与外部系统和用户界面的关系公开。
Order Manager 服务与另一个数字渠道接口，该渠道充当客户订购的前端系统。这在内部调用产品库存服务来验证产品库存详细信息。
在当前的方案中，有多种方法可以解决这样的要求，下面详细介绍了一些这样的选项
选项 1
遵循任何服务间通信利用 gRPC 和任何面向客户端的服务利用 REST 的方法。
通过 gRPC 公开 Product Inventory 服务以进行服务间通信
我们为约定使用了 Protobuf 定义，并使用 java 来生成服务器端实现。
需要额外的编码，如创建一个 REST 控制器和响应翻译，以公开与 REST API 相同的内容，以供第3方系统使用。
用于处理 gRPC 和 REST 的额外编码复杂性和依赖管理。
遵循微服务聚合器模式
选项 2
创建一个聚合器服务，该服务将通过聚合来自不同服务的响应或实现包装器 REST API 服务来公开 REST API 功能。这也将具有与其他内部服务通信以聚合响应所需的 gRPC 客户端实现。此处将包含用于从协议缓冲区创建 API 响应的翻译代码。
gRPC 和协议缓冲区迫使开发人员严格遵守合同，以确保消息安全且不会在通信之间丢失。虽然定义 RPC 的契约优先性质和共同开发的方法在相关服务之间是好的，但聚合器服务带来了开销。
结论
架构师在设计分布式系统时花了很多心思。定义有效的集成模式是解决方案成功的关键。
以下是对各种集成选项和挑战的总结：
在内部和外部将数据公开为 REST（基于 JSON）：这种方法最流行，但遗憾的是不能满足所有要求。由于 JSON 有效负载和 HTTP 协议的限制，这对于数据密集型服务间通信来说并不理想。
在内部和外部公开 gRPC：数据交换以二进制格式发生，人类不可读。gRPC 依赖于 HTTP2.0，它对现代浏览器的支持有限。
创建 REST 和 gRPC：
正如前面选项中所解释的，额外的编码和集成开销。
来自任何广泛采用的开源框架的跨技术（如 java python 或节点）缺乏成熟的 gRPC 实现。
在我们考虑设计下一个基于微服务的解决方案时，考虑这些不同的集成模式很重要。
备注
原文连接：[https://www.cncf.io/blog/2022/02/11/integration-challenges-in-microservices-architecture-with-grpc-rest/]