@
coderxy #25
> grpc 可以直接动态的完成 client 调用,grpcurl 可以看一下,grpc 协议也不是跟 protobuf 强绑定了,也可以用 json 作为编码格式。
那这个开发动态的可以方便些,但是 json 也更慢了一点。
而且不管开发怎么方便,仍然是新的成本,使用 api gateway 相比于 nginx 也未必是优势。
> 链路追踪很多时候是用来记录 io 操作的,所以 redis mysql 等也会被记录进来,在开发和线上排查问题特别好用(例如线上一个接口比较慢,但看不出哪里阻塞的,链路追踪可以一眼看出症结)。
这可不只是记录 io 哦,重要的业务,也会带上业务信息,例如电商订单 ID ,可以按订单 ID 查询所有相关流程日志、快速定位问题。
> 还有,绝大多数大一点的公司都有 api gateway 这一层的,它能做很多事情(接口配置、鉴权、限流、灰色发布、流量染色、数据清洗、编排等等等等),只不过目前你们还没感受到罢了。
这些用 nginx 好像也可以搞吧?
所以这并不是我们自己感受不感受的问题,而是选型上我们就不认为这个相比于传统方案具有优势。
别说的好像不自己定制开发就活不下去了似的
> 技术,简单的场景有简单的方案,复杂的场景有复杂的方案。
咱别凭空把自己认为的优势就是优势,至少把原因讲出来,我前面抵触这种 gateway 都是带了说明的、而且是说明具体原因,而不是像你这样说大公司都有拿来背书,好像大公司有就是好的、别人没有就是不好的一样,劣币驱逐良币也好、推广力度不同造成用户数量不同的事情多了去了,所以不同的事物对比、可别拿 xxx 都在用这种逻辑来辩论、这可不是直接的因果关系啊。
当然,如果我家业务确实需要定制,那我也会去定制开发,但绝大多数团队,没必要,包括很多大公司的项目多加这一层也是画蛇添足
> 我个人认为,技术人员,不应该让自己抵触某种技术,毕竟不会跟会但是不用是两码事。 至少面试的时候别人会让你回答怎么造飞机。
不管会不会,我倒是无所谓被面试官欺负,反正习惯了自己造。至于 grpc 我到底会不会,我得说明一下。
grpc 我个人不怎么用,我用自己的:
https://github.com/lesismal/arpc这是 benchmark 对比,但这个只是性能 benchmark ,arpc 性能还可以,至少比 grpc 强很多,因为谁叫 grpc 爹非要选 http2 做网络层呢,对于内网之间的 rpc 、http2 就显得比较多余和浪费了、直接 tcp 性能好得多:
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/不只是性能,实际使用上 arpc 还有很多便利:
比如不只是 server 之间可以用、client 也可以请求 server
比如 server 也可以直接推送数据给 client 、client 也可以只推送数据不需要 server response
比如可以做的业务类型也不限于微服务,游戏、IM 、推送各种业务都可以做
比如 arpc 不限制序列化方式,相同或者不同的 method 的每次请求都可以是不同的序列化,甚至也可以直接使用一段 buffer
中间件之类的也都支持,而且是支持两个维度的中间件:编解码、路由,用户可以自己定制、扩展更多东西
grpc 对我而言性能和易用性都太弱,复杂点的业务、功能它实现起来很麻烦
我也不只是做 web 这种相对简单的服务,所以我个人一是不稀罕用 grpc 因为性能差、二是它确实无法满足我的需求,即使用它、仍然要引入更多轮子来实现它搞不定的业务功能
因为不怎么用 grpc 、所以我也确实对 grpc 只了解基本使用而已、不像你们那样对它那么熟悉
确切地说,我不只是抵触 grpc gateway ,我连 grpc 都抵触的 😇😂