微服务架构与 gRPC 和 REST 的集成挑战

摘要

本文旨在解释 gRPC 和 REST 等技术为端到端微服务架构带来的集成挑战。它总结和提出了解决当前在实现微服务时明显的问题，主要包括

• 服务之间的内部通信，这种一般使用 RPC 通信。

• 外部第三方系统需要通过 Http Rest 方式访问服务，这些服务可能只提供了 RPC 接口。

介绍

微服务架构的采用率正在上升，并因其带来的灵活性（包括可维护性和可扩展性）而被广泛接受。随着容器化，微服务架构变得更加强大，允许用户创建专注于其功能而不是解决依赖关系的应用程序。云原生应用程序开发由使用容器的微服务架构提供支持。

分布式系统设计复杂，并且随着业务需求的不同性质而变得更加复杂，为了实现端到端业务能力，需要互连或调用多个微服务。集成技术的选择变得至关重要，目前采用的常用方法是任何服务间通信利用 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 相同的内容，以供第三方系统使用。

这种方式需要处理 gRPC 和 REST 的额外编码复杂性和依赖管理。

选项 2：

遵循微服务聚合器模式，

• 创建一个聚合器服务，该服务将通过聚合来自不同服务的响应或实现包装器 REST API 服务来公开 REST API 功能。这也将具有与其他内部服务通信以聚合响应所需的 gRPC 客户端实现。此处将包含用于从协议缓冲区创建 API 响应实体。

gRPC 和协议缓冲区迫使开发人员严格遵守契约，以确保消息安全且不会在通信之间丢失。虽然定义 RPC 的契约优先性质和共同开发的方法在相关服务之间是好的，但聚合器服务带来了额外开销。

总结

架构师在设计分布式系统时花了很多心思。定义有效的集成模式是解决方案成功的关键。

以下是对各种集成选项和挑战的总结：

• 在内部和外部将数据公开为 REST（基于 JSON）：这种方法最流行，但遗憾的是不能满足所有要求。由于 JSON 有效负载和 HTTP 协议的限制，这对于数据密集型服务间通信来说并不理想。

• 在内部和外部公开 gRPC：数据交换以二进制格式发生，人类不可读。gRPC 依赖于 HTTP2.0，它对现代浏览器的支持有限。

• 创建 REST 和 gRPC：正如前面选项中所解释的，额外的编码和集成开销。来自任何广泛采用的开源框架的跨技术（如 java、python、node）缺乏成熟的 gRPC 实现。

在我们考虑设计下一个基于微服务的解决方案时，考虑并设计这些不同的集成模式很重要。

推荐

A Big Picture of Kubernetes

Kubernetes入门培训（内含PPT）

---

原创不易，随手关注或者”在看“，诚挚感谢！