@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 的故障问题，跟国内国外没关系。

@codehz #100

其实就是语言定位、取舍问题。c/cpp 这些是要把底层能力尽量留给开发者、开发者可以“肆意”掌控和进行性能优化，编译器自己优化性能的效率比肉眼要高得多。golang 的定位本来也不是像 c/cpp 那样极致性能与控制力，而是尽量在工程上让开发者能够舒服地做业务逻辑，所以写 go 也不需要考虑那么多。