一般来说，在Kubernetes 集群内进行服务之间的相互通信时，我们有多种协议可供选择。比如gRPC 和 REST。

今天，我们来看看二者在性能方面有什么样的差别。

所有代码放在了GitHub上: https://github.com/ohstackoverflow/RESTvsGRPC

基准测试如下

• REST API：

$ cd RESTvsGRPCRestAPI
$ dotnet run -p RestAPI.csproj -c Release

• gRPC API：

$ cd RESTvsGRPCGrpcAPI
$ dotnet run -p GrpcAPI.csproj -c Release

• 基准性能测试项目：

$ cd RESTvsGRPCRESTvsGRPC
$ dotnet run -p RESTvsGRPC.csproj -c Release

执行结果如下

当你用 REST 获取较小数据时，它比 gRPC 快。

$ RestGetSmallPayloadAsync |            100 |    14.99 ms |  0.2932 ms |  0.2743 ms |

$ GrpcGetSmallPayloadAsync |            100 |    19.60 ms |  0.3096 ms |  0.2896 ms |

我认为这是因为 .NET Core 团队已经优化了核心中 JSON 处理的性能。但如果我们用 REST 运行大数据，它就没有效果了。见下文

$ RestGetLargePayloadAsync |            100 | 1,181.00 ms | 13.9860 ms | 12.3982 ms |

$ GrpcGetLargePayloadAsListAsync |   100 |   187.93 ms |  1.7881 ms |  1.6726 ms |

当我们处理大块数据时，可以看到 gRPC 相对 REST 性能提升了500%以上。

总计一下

.NET Core针对REST JSON小负载数据处理进行了特别优化，其性能甚至gRPC高出了20%左右。但是对于大数据负载，gRPC 仍然是这个领域的赢家。

我并不是说哪个比另一个更好。我要说的是，我们需要适当的策略来将哪种协议用于你的业务案例。

通常在与外部世界的通信中，使用 REST 通信，例如外部服务集成、与前端应用通信等等，而在Kubernetes 内部，基于HTTP/2的强大能力，通常选用gRPC。gRPC建立在HTTP / 2的长期连接上，为服务间通信创建高性能。

虽然我们也可以在 Kestrel 上使用 REST 配置 HTTP/2，但它会带来更多成本并且效率低下，因为我们需要在 Kestrel 中维护证书。

在下面的 Kubernetes架构图中，标识了服务间通讯通常所建议配置使用的传输协议