@
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 都抵触的 😇😂