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

@coderxy

> #6 nginx->api gateway->grpc 服务，api gateway 用 go 自己写。

api gateway 自己写，你得先有 http handler 然后转成 grpc call 去请求原来的服务对吧？原来的 gin 服务得改造成 grpc server 、把以前的 gin handler 改成 grpc method 对吧？

> #18 一般 api gateway 写好了之后，后续增加接口只需要在 web 页面上配置一下 path+method 转发到哪个 service 的哪个 method

所以还得开发个 web 页面管理这个功能啊？
但是 grpc golang call 好像没有直接通过字符串调用方法的功能吧？所以你得首先生成了对应的 call 代码、然后再在你的 web 页面上配置才行吧，那么每次更新版本有新增、修改 grpc 协议相关，你都需要把 grpc gateway 也发版本、这也是运维成本
我看了下 grpc-gateway 也是要每次先按协议生成之后才能调用，按 proto 生成之后按道理就没必要自己再 web 页面上配置了、所以你说的 web 页面的开发和在上面人工配置的成本估计可以省掉，但每次改协议发版本也仍然是多余的浪费：
https://github.com/grpc-ecosystem/grpc-gateway?tab=readme-ov-file#4-generate-reverse-proxy-using-protoc-gen-grpc-gateway

另外，如果想全动态，当然也可以自己去把 grpc 协议格式弄出来自己去拼二进制的协议，也可以搞，但同样需要花不少时间去搞这个、而且这个一半的 CURDer 也搞不定。

另外，由于 grpc gateway 直接处理 client 的 http 请求，可能就难以避免偶尔对个别接口参数的定制，网关最好还是透明一些，grpc 用 pb 这种强类型定义相比于 json 没那么方便做到网关功能的透明
所以我持续抵制这种 to c 的 api 使用这种 api 转 rpc 的 gateway 的架构设计方案，微服务集群内部之间直接 rpc 就可以了也没太大必要加这种 gateway

> #18 还有，链路追踪这些跟微服务根本就没有啥必然关系，就算是单体服务，照样可以用链路追踪，它可以帮助你快速发现和排查问题。

这个我不是很同意：例如原本只有一个 gin server 的 api 流程（连网关、反代都不需要加）、只要查 gin server 日志就够了，没有多链路所以也无所谓链路追踪
但引入更多中间节点，链路就变长了、流程就变多了，当然也可以分散着各自去查各个节点的日志，但不够系统
当然，我也不是说必须增加，自己单独查 grpc gateway 日志也行


> #6 简单一点就是 nginx->业务服务

这句是好的建议

#16 `这时候你搞个几种的数据层服务` -> `这时候你搞个集中的数据层服务`

@RedBeanIce #12

OP 撒谎，明明没有感谢我。。。
我一声叹息的意思就是别做没必要的折腾了，自己都说了公司没有运维，这点规模的团队业务量估计也不会太大、性能足够、大不了硬件规格升级下也比负载均衡省事。如果真的业务量暴涨了，关键性能瓶颈基本都在数据库这层，即便扩容多节点的 gin 服务，cdn 回源到几个 nginx 、nginx 里均衡下 gin 服务就足够了，没必要非得叫什么 api 网关。

@dextercai @coderxy
前面有几个人建议引入 grpc 的，千万别信他们，引入一层，则每个接口都需要你把 grpc 那层、gin 这层都实现一道 grpc call 、method 的逻辑，本来 api 直达 gin handler 就可以，非要中间插一杠子、关键中间插这一道完全是多余的。
也建议那几位搞清楚 rpc 适合哪些地方，例如你搞数据中台，或者内部拆分的不同的服务之间的调用，rpc 比 http 性能高而且结构化之类的更规范方便，是可以的，这其中最适合的主要是数据量很大、可能数据层单点或者简单集群无法满足业务需要，或者你们微服务拆分的太多、如果都直连数据层、数据库之类的连接池数量压力就非常大，这时候你搞个几种的数据层服务、中台之类的是合理的，或者不同部门之间也都挺大、业务内容多，那么独立出来服务给其他部门调用。
但 OP 的这个场景是直接面向用户的 to c 的接口，这种在中间加一个 api 转 rpc ，纯纯是给自己加工作量、给公司增加成本浪费资源、并且出问题时候的纵向定位链条增加了、更麻烦，而且配套下来又要引入更多东西比如链路追踪。。。

@XCFOX #7 随便引入消息队列之类的更是离谱。消息队列用于解耦、削峰之类的 ok ，但你得是不要求消息队列消费后再返还结果的服务比较好。否则首先相当于改变了同步模式，因为你需要等待入队后消费方把结果再给你、你才能把结果返还给请求方。这本质上相当于回调，虽然你可以用 chan 之类的、进程内不同模块或者不同服务之间 rpc 之类的实现类似同步代码的封装、但还要处理超时失败之类的一系列配套处理，逻辑流程可比之前麻烦太多了。所以，如果是电商下单这种，例如你先插入了订单、然后 push 到消息队列里作为待处理订单、然后就可以响应用户下单成功了，后续的待处理由商户触发已发货、物流已出发、后续订单签收确认之类的是其他模块从待处理的消费队列里去一步步处理并丢入下一个流程的消息队列或者订单状态改变，本次请求不需要请求方等待消息队列消费后的结果，这是 ok 的，否则就是给自己找罪受

上来就推荐 k8s 同样的更是离谱，除了中大规模团队，上 k8s 新增的管理、软硬、人员成本，比带来的好处可高多了，入不敷出，别张口就来

@motecshine @zzhaolei @wkong 几位人间清醒比较值得赞，既往楼层的其他人（如果我没看错的话）统统不值得感谢、并且是误人子弟！ OP 真是有病乱投医！

内容挺好，很早就 star 了。
但主要内容是偏运维领域的，与开发的关系不是特别大。这几年 devops 流行，尤其国外，上云+devops ，开发也都要卷这些，让人挺心累的。

哎

1. DELL 2723QX 4K 全面屏
2. DELL S3221QS 4K 带鱼屏

都是 3000 左右，美术选 1 ，非美术选 2

@CRVV @EchoGroot #109

> for flag print sleep 的那个循环一直占用着 CPU ，sleep 的实现是忙等，而后面的 for 循环从来都没有执行到，这是一种符合 spec 的行为

sleep 的实现是忙等，这个不对吧？它可不是纯 cpu spin 那种吧？ print 也是有 io 的，也不是导致后面的 for 循环从来没有执行到的原因吧？
所以虽然后面的 for 被优化掉了，但我并不清楚具体什么原因导致的优化

> 两个 goroutine 同时对一个变量做读写操作，这个叫 data race ，当然是 undefined behavier
> 两个线程不能同时读写同一个变量，这个算基础知识吧

这个说法片面了吧~
data race 可能会造成不一致、undefined behavior ，但如果正确使用、并不会造成 ub 。
我代码里一些 flag 就是 data race 的，为了性能，一些简单的地方没必要都加锁，atomic 也是多余

OP 不用被气到，而且这跟煤矿辛苦没有关系：同样是煤矿，其他非编内人员，同样辛苦但待遇更差、仍然是不公平的。
我相信多数抱怨的人是觉得分配方案不够 average 和 balance ，并不是仇视你家人拿的多。
大家都心平气和些

用谷歌登录是不是也有同样的问题？这跟账号大一统没关系吧，相当于用于身份信息的那个中心 id 的故障问题，跟国内国外没关系。