volo
volo copied to clipboard
cloudwego
不知道是否支持grpc web
你好，Volo-gRPC 实现了标准的 gRPC 功能，gRPC-web 只是需要你在 Volo-gRPC 前部署一层 envoy 即可。
你好，恰恰正是这层envoy会导致很多架构上的复杂性，tonic支持的gRPC-web就非常好用。当然这个envoy在字节可能是没有问题的，部署成本也基本可以忽略。但是对于很多小公司而言，就变成了拦路虎。 开源项目其实笼络小公司的人心反而是最高效的手段，因为你让阿里放弃dubbo-3用volo，他们基本不会做的。但是你让小公司用volo，其实就非常有诱惑力。 支持gRPC-web的工作量其实应该还好，尤其是已经支持了gRPC的情况下。
收到，gRPC-web 和 gRPC-gateway 都在我们的规划之中，不过可能会稍晚一些。 你这边是计划在公司内生产环境使用 Volo 嘛？
收到，gRPC-web 和 gRPC-gateway 都在我们的规划之中，不过可能会稍晚一些。 你这边是计划在公司内生产环境使用 Volo 嘛？
我们周围有几个创业团队，我们开始密集地使用gRPC-web，其核心因素是IDL生成代码可以节省掉原来很费时间的接口调试和前后端字段对齐，对开发效率是很好的提升，但是现在gRPC-web的支持还非常少，真正可行的大概有如下几个
- envoy代理，后面用标准gRPC，这个代理其实很别扭，C++的网关让改造几乎不可行，wasm支持的配置又别扭。
- tonic，比较好的一个解决方案，本来一直打算用，但是最近他们在经历hyper-1.0的升级，把很多东西搞得不可用，这就导致了我们开始寻找tonic的替代方案，而且深感tonic背后的团队其实还是缓慢而弱小的。
- armeria，这个是JVM中唯一支持gRPC-web的框架，可以和Spring一起用，但其实也很别扭。
总体，我们认为gRRC-web代表的新型开发流程，可以从本质上解决很多前后端联合调试的疑难杂症，但是google向来喜欢造概念但不喜欢精细化运营打造的风格，导致一个非常好的东西，长期得不到高水准的实现，实在遗憾。我们知道volo是字节的团队在全力维护，所以真心希望字节能带个头，把这个生态建立起来。
其实同时也别排斥一些其他公司做的不错的东西，比如阿里的nacos，整个dubbo3生态里面最有价值的就是这个东西。volo是我翻代码看到的rust最优秀的实现，但是在分布式上，建议兼容nacos。
我们能够设想的最理想的开发状态为：
- 一个支持gRPC-web的框架，让前后端能够火速连接，无痛调试
- 一个支持nacos的分布式框架，让后端之间无痛，尤其建议看看他们的r-nacos，那里有一个很优秀的rust实现，内置了分布式存储。 tonic的gRPC-web支持其实不错，但整个框架的质量一般，AFIT和RPITIT发布都很久了，那边还不知道如何融入到项目中去，甚至连个基本的提案和思路都没有，阿里的dubbo-rust不用看，做得很一般，但他们的那个r-nacos确实还不错，建议考虑兼容。
你好，非常感谢你的建议，能感觉到你对于相关生态都非常熟悉也做了深度的调研。这个建议对我们来说非常有价值。
我们目前有一个方案，可以直接让我们的 volo 框架使用基于 tower 的 layer/service，至于具体的 gRPC-web 的 Layer 的适配方案， @Millione 正在看这个事情，如果有进展会在这里及时同步。这个方案应该能解决你们的需求。
nacos 是一个服务注册和发现的中心？看起来这个和 volo 应该不存在兼容性问题？还是我的理解有哪些不正确的地方，欢迎指正。
另外，欢迎你们加入我们的用户群直接交流，如果企业用户需要支持的话也可以填写一下 https://wenjuan.feishu.cn/m?t=sH0dv11ZVGDi-5kda 这个问卷~
gRPC-web的实现方案可能不需要特别复杂，核心就2个点
- header正确处理掉，这个写一个middleware就可以拦截gRPC-web相关请求并修改header
- 转换request body和response body，因为hyper的Body现在是一个trait了，所以设计一个GrpcWebRequest和GrpcWebRequest并实现Body的trait就可以了。具体实现可以参考tonic，代码并不复杂
抱歉，这两周确实有些忙，我们争取下周内支持上
不过看你们回issue的速度，还是真的在蛮用心经营这个项目，希望越来越好，我自己有空的时候，也可以尽一些绵薄之力。
是的，我们的项目都是内外同源的，也就是说这个项目就是我们真正在内部使用的项目，不存在两套代码。
如果你对 grpc-web 比较熟悉，也十分欢迎你来贡献~
有进展吗，正在考虑要不要用，主要前端需要grpc-web
有进展的，目前实现的差不多了，主要是改造一下 volo-grpc 的中间件，使得可以直接复用上 tonic 的 grpc-web 中间件实现，https://github.com/cloudwego/volo/pull/466 具体使用可以看 volo-grpc 里的 examples
建议先发布出来：
- 代码不用一次追求完美，总还是可能迭代的，另外cors看你考虑没有，一般都需要的，很多时候grpc端口和正常的http服务端口并不一致，所以一般都有cors跨域支持
- 建议补充文档和example
- 建议去https://github.com/grpc/grpc-web里面提一个readme.md的PR，就说支持grpc-web的框架多了一个volo，因为多数接触grpc-web的开发者是从这个项目开始探索的
@jqiris @thegenius 有什么建议吗？已经开发完成了，目前是仅支持 grpc-web server
另外仅支持grpc-web server，是指不能同时开启普通http服务吗？
另外仅支持grpc-web server，是指不能同时开启普通http服务吗？
我理解不冲突，grpc-web server 是指可以处理以 http1 形式发过来的带 pb 编码的 body
@jqiris hello，你说的不成熟具体指的是哪块呀？
其实都是希望技术完全成熟了，才开始使用，不踩任何坑。 但是对公司的项目，个人的项目，创业的项目，可能是有不同策略的：
- 公司项目，尽量成熟，有坑不至于被骂
- 个人项目，尽量用新的，学东西是可能主要目标
- 创业项目，有坑不要紧，使用新的技术如果能带来领先优势，就先用
还有就是很多人估计不清楚为什么很多接触过envoy的就极度不喜欢envoy，是因为那玩意儿确实不是人读的，yaml加上缩进就是噩梦，给大家一个例子看看：
static_resources:
listeners:
- name: listener_0
address:
socket_address:
address: 0.0.0.0
port_value: 8080
filter_chains:
- filters:
- name: envoy.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
codec_type: AUTO
http_filters:
- name: envoy.filters.http.cors
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.cors.v3.Cors
allow_origin_string_match:
- safe_regex:
google_re2: { }
regex: "^(http|https)://www.example.com(/.*)?$"
allow_methods: GET, PUT, DELETE, POST, OPTIONS
max_age: "1728000"
expose_headers: Content-Length,Content-Type
allow_credentials: true
- name: envoy.filters.http.grpc_web
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb
- name: envoy.filters.http.grpc_http1_bridge
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.grpc_http1_bridge.v3.Config
upgrade_protobuf_to_grpc: true
ignore_query_parameters: true
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match:
prefix: "/"
route:
cluster: service_cluster
clusters:
- name: service_cluster
type: STATIC
lb_policy: ROUND_ROBIN
connect_timeout: 0.25s
load_assignment:
cluster_name: my_cluster
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: 0.0.0.0
port_value: 9090
这还只是配置的一部分，我觉得任何学习envoy和配置envoy都是在浪费宝贵的生命
而且envoy那帮人极度喜欢增加增加和调整参数结构，他们理所当然地认为所有人都应该陪着他们一起修改配置文件和升级系统， 你写好一份配置是1.29的，过两天发布个1.30，不好意思，重新研究重新写，因为他们的参数结构和层级命名都可能变了，你翻遍文档去找到要怎么改，有时候还会告诉你有个特性不支持了。
@thegenius Hello 你好呀，很抱歉回复晚了，我们 grpc-web 的支持已经发版啦~
衷心感谢你们把grpc-web特性作为了优先支持特性来处理，我自己会在项目中优先试用。 也希望grpc-web慢慢开始成为主流的开发流程，因为我们在项目中摸索使用（原来用tonic+armeria）发现 grpc-web已经能带来非常多的优势了：
- 不用写接口文档，client和server基于proto生成
- 性能远高于http的框架，尤其是用rust的情况下
- protobuf比json节省内存 如果grpc-web成为主流研发流程，volo成为grpc-web的rust默认最优框架，我相信会有光明的未来。
@thegenius 你前面有提到 armeria, 想问下armeria和spring boot 结合使用中有哪些别扭的地方？我个人使用中感觉还可以。说不定你有些坑我们还没有踩过。以及你们公司以前用armeria的QPS？
armeria，这个是JVM中唯一支持gRPC-web的框架，可以和Spring一起用，但其实也很别扭。
