gRPC在Swift中：何时真正需要它

gRPC在Swift中：何时不是赶时髦，而是真需要

想象一下：您正在编写一个用于管理智能家居的iOS应用。命令每秒都在发送，延迟100毫秒就已经是灾难了。或者您正在做一个流媒体服务，视频、音频和遥测数据同时传输。REST在这里会开始“卡顿”并靠边站。认识一下——Swift中的gRPC。

但说实话：gRPC不是银弹。有时简单的HTTP/1.1上的JSON效果更好。在本文中，我们将分析何时gRPC在iOS中值得使用，何时最好保留REST，以及它在Swift实际代码中的表现。

我不会灌水。只有实践、示例和具体场景。开始吧。

什么是gRPC（非常简短，给错过的人）

gRPC是Google的RPC框架，使用Protocol Buffers（protobuf）进行数据序列化，使用HTTP/2进行传输。它支持：

\n
• 一元调用（像普通REST）
\n
• 服务器端流式传输
\n
• 客户端流式传输
\n
• 双向流式传输
\n

在Swift上，有官方库grpc-swift（Swift Package Manager），它允许客户端和服务器都在Swift上运行。是的，您可以用gRPC在Swift上编写服务器——这不是玩笑。

何时Swift中的gRPC是您最好的朋友

1. 高负载和低延迟

如果您的应用每秒发送数百个请求（例如，交易、游戏、IoT），gRPC通过以下方式胜出：

\n
• HTTP/2 — 多路复用、头部压缩
\n
• 二进制协议 — protobuf解析比JSON更快
\n
• Keep-alive连接 — 无需每次都进行TCP握手
\n

实际例子：服务器监控应用。每秒收到1000个指标。在REST上——1000个TCP连接，在gRPC上——一个长连接。电池负载差异——数倍。

2. 数据流式传输

REST及其“请求-响应”模式无法进行流式传输。而gRPC可以。如果您需要：

\n
• 实时接收货币汇率更新
\n
• 流式传输音频/视频
\n
• 实时接收服务器日志
\n

那么gRPC是您的选择。以下是Swift中服务器端流式传输的样子：

// 在.proto中定义\nservice StreamService {\n    rpc SubscribeToUpdates(Empty) returns (stream Update) {}\n}\n\n// Swift客户端\nlet client = StreamServiceAsyncClient(channel: channel)\nlet updates = client.subscribeToUpdates(Empty())\n\nfor try await update in updates {\n    print("收到更新: \\(update.message)")\n}

注意：for try await — 这是Swift Concurrency。gRPC-Swift与此配合得很好。

3. 基于Swift的微服务（是的，这存在）

您可以用Swift（Vapor、Hummingbird）编写整个后端，并使用gRPC进行微服务之间的内部通信。优点：

\n
• 共享模型代码（protobuf生成Swift结构体）
\n
• 强类型
\n
• 内置超时、重试、负载均衡支持
\n

// Swift服务器\nfinal class GreeterProvider: GreeterAsyncProvider {\n    func sayHello(request: HelloRequest, context: GRPCAsyncServerCallContext) async throws -> HelloReply {\n        return HelloReply.with { $0.message = "你好，\\(request.name)!" }\n    }\n}

这段代码是一个完整的gRPC服务器，可以在任何Linux/macOS服务器上运行。

4. 当您有严格的契约系统时

Protobuf文件是单一事实来源。您在.proto中描述了API，为Swift、Go、Python生成了代码——所有人都说同一种语言。没有“哦，这个字段是可选的，那个不是”的情况。

对于大型团队来说，这是救星