本文主要介绍了 gRPC, 网络现状及测试的简介, 好不好用等相关内容.
上篇文章回顾: golang 中的切片操作
gRPC 是什么?
gRPC 是谷歌开源的一款不那么快的基于原型缓冲区的 RPC 框架.
既然不那么快, 为什么还要提它呢? 相较于节俭, gRPC 会慢一点, 但是, 本文的着眼点并不在于 RPC 吞吐量的极限值, 也不是框架的通信时间减少几十几千纳秒, 本文要介绍的是除 GraphQL 外, JSON RPC 优化的另一个取向 --gRPCweb.
众所周知, GraphQL 着眼的优化点在于通过移交一部分查询的逻辑到客户端, 从而减少了数据的交换量, 而 RPC 则着眼于使用可压缩的二进制 / 文本协议, 减少 JSON 文本传输带来的不必要的协议损失. 本文着眼于此, 对比 gRPCweb 当前的进展, 对易用性, 便捷性, 成本方面进行了评价, 结论虽然有些武断, 但是仍然反映了当前 gRPCweb 仍然有待进一步发展的事实.
01gRPC Web 能给我们带来什么?
1. 传输数据量减少, 传输延迟降低
HTTP / 2 天生具有头压缩等特性, 解决了大量频繁的 RPC 交互通信带来的头部重复传输问题; 使用二进制流或压缩文本传输, 减少了一部分稀疏编码带来的字节空洞, 提高了信息密度. 传输速度更快, 数据量更小, 不仅降低成本, 而且可以减少延迟.
2. 可靠一致的 API 设计
客户端服务端使用相同的原文件进行接口定义, 双方接口暴露完全相同, 一致性更强, 相较于传统的招摇接口管理, 其数据结构更加直观精确, 不再需要维护接口 - URL 间的复杂对应关系, API 升级管理更加简单
3. 对传输基础设施无感知的通信协议
节俭不能推出类似 gRPCweb 的方案的原因也正在于此. Thrift 使用私有 Tprotocol 传输协议, 与 gRPC 的 HTTP / 2 相比起来通用性大打折扣, Nginx 的在最新的稳定版中已经提供了 grpc_pass 负载均衡支持, 我们可以无痛使用原有的四层 / 七层负载均衡器提供大规模的调用支持
4. 高效的序列化 / 反序列化支持
gRPC 相较于 JSON, 拥有更高的序列化 / 反序列化效率, 易于实现更高的吞吐性能
02gRPC Web 能不能用? 好不好用?
话不多说, 接下来我们就开始进行一套 gRPCserver + envoy 代理 + gRPCweb on TypeScript 的 echo 通信测试, 作为对比, 笔者将实现一套同样功能的 websocket 链路, 用以测试双方通信性能, 比较这些功能的实现难度并评价两种 "看似比较底层" 的网络通讯协议.
gRPC 网站测试
首先定义一个我们的回声服务的原型:
- syntax = "proto3";package chatman;
- message ChatRequest {
- string messages = 1;
- }
- message ChatResponse {
- string messages = 1;
- }
- service Chat { rpc chat (ChatRequest) returns (ChatResponse);
}
然后写服务器端代码, 此处使用的 Python 的实现:
生成服务器端的 protobuf 的的文件, 使用 gRPC 工具生成代码即可, 然后我们引入 grpcio 和这些的 protobuf 的库文件:
- import grpcimport service_pb2,service_pb2_grpc
- from concurrent.futures import ThreadPoolExecutorimport time
- class ChatServicer(service_pb2_grpc.ChatServicer):
- def chat(self,request,context): print(request.messages)
- return service_pb2.ChatResponse(messages="Server Received: %s" % request.messages)def server_start():
- server = grpc.server(ThreadPoolExecutor(max_workers=5))
- service_pb2_grpc.add_ChatServicer_to_server(ChatServicer(),server)
- server.add_insecure_port('0.0.0.0:8800')
- server.start()
- time.sleep(3600*24)if __name__ == '__main__':
server_start()
我们先测试下 HTTP / 2 二进制流模式的 gRPC:
Python 中的代码如下:
- import grpcimport service_pb2_grpcimport service_pb2
- channel = grpc.insecure_channel('0.0.0.0:8800')
- stub = service_pb2_grpc.ChatStub(channel)
- message = service_pb2.ChatRequest(messages="test message")
- msg = stub.chat(message)
print(msg)
返回消息:"Server Received:test message". 测试成功, 抓包结果如下:
可以看到, 两方使用 "不安全" 的 HTTP 协议交换了数据, 通信成功完成.
接下来, 我们使用 gRPC 的网络实现相同功能. 值得注意的一点是, 目前 gRPC 幅还不能直接运行在浏览器上, 因为浏览器尚未提供裸 HTTP 协议的接口, 因此需要进行一层简单的封装, 并通过代理剥去这层封装才能与真正的 gRPC 后端通信, 这种通信方式被称为 gRPC 的网页文本.
同理, 使用 gRPC 的工具生成打字稿文件, 生成文件包含一个原始的 JS 库, 一个描述文件以及一个 TS 客户端库, 编写代码:
- import { ChatRequest,ChatResponse } from './service_pb'import { ChatClient } from './ServiceServiceClientPb'const client1 = new ChatClient("http://127.0.0.1:8001",{},{});
- let req = new ChatRequest()
- req.setMessages("messages")
- client1.chat(req,{},(err: any, res)=>{
- console.log(res);
});
在 html 中直接引用这个 JS, 并使用特使代理进行 gRPC 的网页文本到 gRPC 协议的转换, 配置如下:
- admin:
- access_log_path: /tmp/admin_access.log
- address:
- socket_address: { address: 127.0.0.1, port_value: 9901 }
- static_resources:
- listeners:
- - name: listener_0
- address:
- socket_address: { address: 127.0.0.1, port_value: 8080 }
- filter_chains:
- - filters:
- - name: envoy.http_connection_manager
- config:
- codec_type: auto
- stat_prefix: ingress_http
- route_config:
- name: local_route
- virtual_hosts:
- - name: local_service
- domains: ["*"]
- routes:
- - match: { prefix: "/" }
- route:
- cluster: echo_service
- max_grpc_timeout: 0s
- cors:
- allow_origin:
- - "*"
- allow_methods: GET, PUT, DELETE, POST, OPTIONS
- allow_headers: keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,custom-header-1,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-Web,grpc-timeout
- max_age: "1728000"
- expose_headers: custom-header-1,grpc-status,grpc-message
- enabled: true
- http_filters:
- - name: envoy.grpc_web
- - name: envoy.cors
- - name: envoy.router
- clusters:
- - name: echo_service
- connect_timeout: 0.25s
- type: logical_dns
- http2_protocol_options: {}
- lb_policy: round_robin
hosts: [{ socket_address: { address: 127.0.0.1, port_value: 8800 }}]
现在进行测试, 访问刚才的网页, 可以看到通信情况:
一看就知道是的的 base64 编码, 果断解码:
果然不出所料, 是一个封装在 HTTP 里的 HTTP 通讯
Web Socket 的测试
接下来, 使用的 WebSocket 的进行对比:
编写服务端程序:
- console.log("Server started");
- var Msg = '';
- var WebSocketServer = require('ws').Server
- , wss = new WebSocketServer({port: 8010});
- wss.on('connection', function(ws) {
- ws.on('message', function(message) {
- console.log('Received: %s', message);
- ws.send('Server received:' + message);
- });
});
使用节点启动后, 在浏览器的控制台里连接并访问:
- const ws_echo = new WebSocket("ws://127.0.0.1:8081/")
- ws_echo.addEventListener('message', (event) => {
- console.log(event.data);
- })
ws_echo.send("Hello!")
控制台返回服务器收到: 您好!
通信完成, 查看协议:
可以看到, 经过一次通信后, 服务器直接返回升级升级连接的报头, 随后双方使用的 WebSocket 的进行通信, 比起 gRPC 的协议, 更加简易直白.
结论
在测试前我一直在思考, gRPCweb 究竟是一个怎样的存在第一眼看到 gRPCweb 文本这个词, 我的第一感觉是这个?
在 Gmail 中的邮箱里, 充满了这种极其类似的的 protobuf 的 XHR 请求, 当看到需要使用专用代理进行转发的时候, 我一度以为是这种高度压缩的文本协议正式出现在了通用的框架里, 然而事实是, 不论是 gRPC-Web 还是 gRPCweb-text, 不论是易用性还是请求响应体长度, 比起 jon over brotli over websocket 都仍然有很大的进步空间, 要实现通过 CDN 分发 JS 节省 API 服务器带宽的构思目前仍然需要自己造轮子, gRPCweb 并不是银弹, 至少目前不是.
本文首发于公众号 "小米运维", 点击查看原文.
来源: https://juejin.im/post/5c778600e51d453ebd4c8378