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

[me1onsoda]

feign 是七层 http 协议，grpc 是四层 tcp 。
对性能来说，那肯定是 rpc 性能好，你见过和哪个中间件通信用 http 的？
易用性可维护性，那还是 feign 这种声明式更好。

[kenvix]

grpc 恶心是因为 protobuf 恶心，这个玩意生成的代码就是一坨屎，污染整个项目

[lambdaq]

grpc 的好处就是面向简历编程，以及技术选型有「 google 都在用」这个黄金招牌。

你选别的 rpc 方案，出了问题就是你选型的责任；

你选 grpc ，出了问题，那得你们公司反思为啥 google 能你们就不能。

这根 yylx 一样的底层逻辑。

[lambdaq]

@kenvix u1s1 ，pb 是有好处的。如果写 C 艹 ，没 pb 你会写出来更恶心的代码。

问题就在于 c 艹本来就是个很傻的生态。pb 属于补救，但是别的语言无脑套用 pb 这就纯跟风和巨厂号召力吧。

[hui9000]

@lambdaq 有道理，后期项目复盘，锅都是自己买的。太惨了，现在 tm 都是这样，有啥事都能把锅甩到技术上，你跟他们解释也解释不通，说白了，人家已经把答案写好了。

[flowerains]

我感觉代码恶心不恶心和人关系很大，和架构关系不大

[kenvix]

@lambdaq #24 RPC 领域，论生成的代码质量，thrift 比 grpc 好得多
论数据交换 msgpak 把 pb 按在地上打

[lambdaq]

@kenvix 所以这两者也有一定市场占有率吧。thrift 也自带巨长光环，让使用者自适应自带反思。

[coderxy]

grpc 最大的优点就是有一个好亲爹， 超强背书。

[migu]

@me1onsoda #21 请教一下，GRPC 不是基于 HTTP2 的吗，为什么是四层

[hui9000]

@flowerains 软件工程的思想在国内大部分公司都是没有的，基本都不会按照规范写，每个人的理解又不一样。又不是不能跑，要是有一个人在工程里拉了一坨大的，其他人是不会管的，因为谁都是看见屎都想吐。

[jsq2627]

目前公司用 grpc + thrift ，甩开了 protobuf 的负担，感觉体验良好。

有 schema 对项目长期维护很重要。
跨语言也很重要。因为保不准团队里就有人想用其他语言来写一部分服务。
我公司内主要是 go ，后来陆续引入了 java/python/nodejs ，大家都在 grpc+thrift 下工作良好。thrift 的代码生成效果也不错。
不过缺点是 thrift 生态还是比 protobuf 差了一些。