@
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 真是有病乱投医！