搞一个grpc动态代理的想法，并初步实现

前言  沟通服务间接口内容(尤其是前后端接口)，是非常让人头疼的事。极其容易扯皮。接口文档写起来也很痛苦，每个字段的改动都需要及时更新，否则就会出问题。服务端通信如果用rpc通信的话，一般会有proto或者thrift文件。这个文件很长时间里被我们当成接口文档用，用着用着发现，真tm好用。既减少了扯皮，还不用写接口文档。那可不可以用grpc和前端通信那，一开始我们的做法是用grpc-gateway。把grpc的接口映射成http接口。但这种方式需要编译gateway的pb文件，对服务也是有侵入的。后来随着我在公司的时间越来越长，接手的服务越来越多(经常需要发版的项目就有十几个)，这种方式维护起来十分糟心，后一直想寻求一种一劳永逸的解决方法？  本人之前很长一段时间从事saas，paas的开发。对于一些服务而言，既要提供grpc访问的能力，也要对外提供http访问的能力(做saas就是这么卑微)。并且这种需求通常不是一开始就提出来的，而是对一个已经稳定运行的庞大的服务做改造。而这会导致爬屎山，鉴权不一致等一系列问题。那有没有一种无侵入的协议转换能力？   grpc是基于http2协议，而http2是长连接。这对k8s部署的服务非常不友好。在这我猜肯定有很多小伙伴说可以用linked,istio等基于service mesh的解决方案。一是这些技术是近两年才稳定下来的，以前问题很多，根本不敢用，当然现在istio已经流行起来了，可以很完美的做到grpc的负载均衡和很优秀的流量管理。但依然存在不满足实际需求的情况，比如对grpc流量做精细过滤，细到每个请求的精准控制。这种二次开发的需求是很难在istio上完成。尤其是对一些小公司而言。基于很多原因的考虑，最终诞生了搞一个grpc动态代理的想法，并初步实现。 grpc   在云原生，容器化，微服务的大背景下。rpc也彻底奠定了服务间通信协议的霸主地位。众多rpc框架中grpc和thrift是最流行最受欢迎的rpc框架。在实际开发中，我两个框架都有深入的使用过。相较而言，我更喜欢grpc的风格。背靠google大树(已经是cncf孵化项目)，多语言都支持，基于protobuf极致编码和急速传输，等等优点就不一一详述。有兴趣的可以看grpc官网，上面吹的比我吹的好。 实践 github地址 https://github.com/woshihaoren4/grpc-proxy 第一步 先将代码clone下来到本地，我这里用的mac系统 因为编译需要cargo环境，需要先安装rust，参考教程：https://www.rust-lang.org/zh-cn/ 上面有很详细的中文教程。我安装的是：rustc 1.66.0 (69f9c33d7 2022-12-12) 版本 第二步 先进入项目根目录，运行起测试例子 ./example/helloworld server 没有权限的话，需要先加权限，然后再运行 chmod +x ./example/helloworld 这个例子使用golang编写的简单的grpc服务，实现上没有啥特殊的部分，值得注意的是需要给grpc服务加上反射 //grpc的helloworld方法实现，就是在字符串上加一个 world func (s *service) helloworld(ctx context.context, req *proto.helloworldrequest) (*proto.helloworldresponse, error) { return &proto.helloworldresponse{response: req.request + world}, nil } //这里相当于main函数 func server(ctx *wdevent.context) error { ls, _ := net.listen(tcp, :8888) gs := grpc.newserver() proto.registerhelloworldserviceserver(gs, new(service)) reflection.register(gs) logrus.infoln(grpc server start workd ....) gs.serve(ls) return nil } 再看一下pb文件，需要注意的是在option里指明 需要映射的http的路径和方法 syntax = proto3; package proto; option go_package = ./proto; import google/api/annotations.proto; // helloworld service service helloworldservice { rpc helloworld(helloworldrequest) returns (helloworldresponse){ option (google.api.http) = { post: /api/v2/hello body: * }; }; } message helloworldrequest { string request = 1; } message helloworldresponse { string response = 1; } 第三步 修改配置文件如下，路径：./src/config/config.toml。当前项目中的配置文件已经写好了这些内容，不需要再配置什么了。当然不放心也可以查看一下。 [[proxy_sink]] name = hello addr = 127.0.0.1:8888 需要在addr中指明上面服务的地址和端口。 第四步 另起终端，编译并运行项目 cargo run -- run 国内没有科学上网的话会有些慢，主要是下载包比较慢，可以用清华源或者其他的，教程参考：https://www.w3cschool.cn/cargo_guide/cargo_guide-uxdg3l62.html 服务启动后会打印如下日志，说明服务启动成功  测试 发起一个http请求 curl --location --request post 'http://127.0.0.1:6789/api/v2/hello' --header 'content-type: application/json' --data-raw '{ request: hello }' 可以看到返回内容：{response: hello world} 并且在代理服务上产生访问日志：  到这里一个简单的演示就成功了 结构和原理 主要是根据grpc的反射的描述，生成http路由，并动态完成json和proto的映射。更进一步的原理和结构，未完待续~ 尾语 当前版本还只是一个比较初级的版本，功能还很初级。还有很多功能需要完善，架构也可能会有大的变动，所有上一节并没有详细描述。作者预计但不承诺会继续完成下面的内容。 restful支持：这个功能是p0级，在我go版本的grpc动态代理服务中经常被用到，在可预计的规划里一定会实现。 事件系统：该功能是为了方便二次开发，很有必要。也有可能用中间件模式，类似traefik 负载均衡/sidecar：负载均衡是为了用在服务网关上，sidecar是用在pod里，二者会选一个实现，我倾向于前者，和我之前写的rust-ingress联动上。这里自荐一波rust-ingress项目：https://gitee.com/yutiandou/rust-ingress 性能优化，这个会一直持续做下去，欢迎有性能极致追求的小伙伴能够共同前进 实时反射：目前是通过配置文件，在启动的时候加载服务源。好的(懒人)方案是proto文件变化后能够实时监控到，下一步会完成这个功能。 欢迎有兴趣的小伙伴提出建议，并热烈欢迎大家参与进来。

Adobe探索增强现实和网络购物 进行了AR原形演示
“2019年中国联通合作伙伴大会”的号角早已吹响
华为Mate40首批搭载鸿蒙系统，2年前手机将不支持
Intel被黑，i7-7700K处理器测试功耗和发热不理想
无线上网使用之GPRS
搞一个grpc动态代理的想法，并初步实现
华为走出“黑屋子”背后：行业危机倒逼开放
2018年新能源汽车现状如何 国内外车企对比
3C数字钥匙技术规范解读
元宇宙虚拟房产价格被“炒上天”
ADRF6820是一款高度集成的解调器和频率合成器
协议解析是什么？普通人如何理解？
2020年Q1季度小米智能手机的印度市场份额为30%，realme占据14%
微雪电子EP4CFPGANIOSII开发板介绍
德高速数字和光通信发展测试会总结 大数据时代来临
电子产品的命名有何逻辑 盘点那些「瞎命名」的数码产品
如何提高github访问速度
WTK6900H智能照明语音识别芯片方案
Cadence并购Forte Design Systems 强化高阶综合产品
中控智慧科技射频卡考勤机M300plus简介
地址：