[大家的项目] 基于rust的，gRPC动态代代理，无需proto文件自动http转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动态代理的想法