grpc 到底好处在哪里？

[hui9000]

我这边没用过 grpc ，之前用过 dubbo ，维护过一个大型 ToB 项目，简直折磨，如果大家都按照规范来，我觉得还好，但是这项目 5 年了，经历了好几代程序员的维护，现在打开都恶心。 后来所有的新项目都搞 Feign 了。但是这个也有点恶心的。最近新开了一个大型项目也是 ToB 。在做技术选型和对比，团队人员目前比较稳定，大概 40 人左右。 想问一下，有没有用 grpc 做过大型项目或维护过这种项目的，有多少坑，坑大小？对比 Feign 好处有哪些。 PS: 别杠，你杠就你对。

[workqing2023]

grpc 也好，dubbo 也好，feign 也好，和项目恶心应该关系不大。。。。没啥区别，看公司内部对哪个的支持力度更大一点就好了

[deorth]

你说得对

[yannxia]

滥用都好不到哪里去，因为 API 瞎定义的事情是框架解决不了的。
GRPC 对比 Feign 的好处就是性能好一点，区别也不是很大，其实我觉得项目规模不大的情况下，我喜欢 HTTP ，容易调用。

[lsk569937453]

grpc 的 protobuf 比 json 啥的占用空间小，传输速度快。所以对性能要求很高的可以用 grpc,其他的 Feign( http 协议+json)就可以了。

[tool2dx]

不太一样，feign 就只是 HTTP API 的声明，而 grpc 是对于 Protobuf 的封装。

如果你们以前项目里不怎么用 Protobuf ，那用处并不是很大。

[cheng6563]

性能较高，没了。对于管理比较混沌的团队还是忍着恶心用 Feign 吧

[28Sv0ngQfIE7Yloe]

@cheng6563

方便说下 feign 恶心在哪里吗？

[QlanQ]

区别不是很大，那点性能可能对你的新项目也没多少影响，建议用团队以前用熟悉的

[cheng6563]

@Morii 不是 Feign 恶心，是项目恶心。

[yeyang5211]

如果是个咸鱼项目 没多少人用 feign spring 全家桶风险小, 并发大 有异构调用的需要可以考虑 grpc

[Goooooos]

toB 项目，如果对序列化性能没要求，还是建议 http+json

[pkoukk]

项目恶心用什么都很恶心
grpc 就是性能高，没啥别的

[bianhui]

没啥特别突出的地方吧，就是优化了一些 rpc 的诟病吧，比如说序列化（类型？ json 也有 Schema 版本），通讯（可以用 http3 ？），开箱即用，性能没有想象那么高，最业界比较公认性能有意的是 facebook 的 Thrift ，坑也挺多的。如果跑在内网可以，跑公网不建议（比如说 udp 国内丢包你懂得），就 json+http 最省心了，或者 Protobuf +http 也行吧。

[datoujiejie221]

主要 grpc 对多语言支持比较好，如果其他语言比如 python 或者 go 用 feign 调用的话就比较麻烦了
还有就是 grpc 支持流式传输，feign 就不太了解了

[hui9000]

@yannxia
@pkoukk
@cheng6563
主要是啥东西刚开始都挺好的，无论是 dubbo 还是 grpc ，还有 feign ，过几个月就完了。老实回去用 http+json 吧

[hui9000]

@QlanQ ToB 的对快没什么太大需求，主要是有些传输内容较大，而且需要稳定。这样是不是就不适合了。

[justplaymore]

可以读一下《凤凰架构》的远程服务调用章节

https://icyfenix.cn/architect-perspective/general-architecture/api-style/rpc.html#%E5%88%86%E8%A3%82%E7%9A%84-rpc

[OMGZui]

还是继续 Feign 吧

[shilyx]

gRPC 在 C++环境下尤其烂

污染性很强，完全不如 thrift

[Akitora]

一个是跨语言，一个是自带 schema