gRPC-Web 通过特殊的网关代理，让浏览器实现了与 gRPC 服务的对接，这背后藏着哪些不为人知的细节？
记得第一次在浏览器中调用 gRPC 服务时，我愣了一下——这不就是后端的“玩具”吗？怎么能让浏览器玩得这么溜？答案其实藏在 gRPC-Web 的设计里。
gRPC-Web 的一大亮点是它不依赖于浏览器原生支持。你可能知道，gRPC 是基于 HTTP/2 的协议，而浏览器对 HTTP/2 的支持虽然已经很成熟，但直接使用 gRPC 还是有些障碍。比如，gRPC 使用的是二进制编码（Protobuf），而浏览器默认支持的是 JSON，这就造成了兼容性的问题。于是，gRPC-Web 出现了。
gRPC-Web 的核心机制是通过一个网关代理来实现浏览器与 gRPC 服务的对接。默认情况下，它使用的是 Envoy 这个强大的代理工具。Envoy 是一个高性能、可扩展的边缘服务代理，它不仅支持 HTTP/2，还支持多种协议转换，比如将 gRPC 请求转换为浏览器能够理解的 JSON 格式。
那这个网关代理到底做了什么？让我们拆解一下。当一个浏览器发起一个 gRPC-Web 请求时，请求其实是通过 HTTP/1.1 发起的。这个请求会被 Envoy 接收到，然后它会解析请求中的内容，比如方法名、参数、头部信息等。接下来，Envoy 会将这些请求转换成标准的 gRPC 请求，并转发给后端的 gRPC 服务。
这个过程虽然看起来简单，但其实有很多细节需要注意。比如，请求的编码方式，gRPC-Web 使用的是 JSON，而 gRPC 服务可能使用的是 Protobuf。Envoy 在这中间扮演了“翻译官”的角色，它会将 JSON 数据转换为 Protobuf 格式，再发送给后端服务。
此外，跨域问题也是 gRPC-Web 需要解决的一大难题。浏览器出于安全考虑，对跨域请求有严格的限制。Envoy 作为代理，可以处理 CORS 头部，确保浏览器能够顺利地与后端服务通信。
不过，Envoy 并不是唯一的选择。如果你不想用 Envoy，也可以选择其他支持 gRPC-Web 的代理工具，比如 NGINX 或 Kong。这些工具各有优劣，选择哪一种取决于你的具体需求和架构。
现在，我们来看看 gRPC-Web 的实际应用场景。比如，一个前端应用需要调用后端的服务，而这些服务是用 gRPC 实现的。在这种情况下，gRPC-Web 就成了连接前后端的桥梁。它不仅让前端能够调用后端的 gRPC 服务，还支持双向流和服务器流等高级功能，这在传统的 REST API 中是很难实现的。
但你可能会问，为什么不用 WebSocket？其实，WebSocket 也是一个不错的选择，但它有一些局限。比如，WebSocket 不支持 HTTP/2 的流控制和多路复用，而 gRPC-Web 则充分利用了 HTTP/2 的这些特性，提供了更高的性能和更低的延迟。
总的来说，gRPC-Web 是一个巧妙的设计，它解决了浏览器与 gRPC 服务之间的兼容性问题，同时又保持了高性能和低延迟的优势。如果你正在开发一个需要在浏览器中调用 gRPC 服务的应用，不妨尝试一下 gRPC-Web，看看它是否能为你带来新的可能。
网络编程, gRPC-Web, HTTP/2, Envoy, 网关代理, WebSocket, Protobuf, JSON, CORS, REST API