想求快就 mqtt ，有一定自研能力且后期有定制化改造可能就用 tcp 自己撸

还有 IM

开发 app 的后端业务

16 年 苏州 实习 2000 996

ping 跟 tcp 是两个协议 可以用 tc 直接丢弃到某个 ip 的所有包就行了

优势： 降低成本、方便团队随时扩张或收缩
缺点： 人员管理复杂，沟通成本变高，外包的项目质量不佳

我在松江，今年退租后房东转租还涨了 200 ， 我当时租 3300 ，他 3500 租出去了。。

你是 web 应用还是 app 啊？ app 的话可以接口加签名。

你多大啊？ 看你还有几年退休，如果 10 年内要退休了，可以交，不然建议暂时不交了， 因为不交，你还能领点失业金，一进一出，差的还挺多的。 而且后面真的有可能会改出最低 20 年社保才可以，到时候你就欲哭无泪了。

你具体用啥功能呃，高德 百度有些基础的功能是有免费额度的。

@lesismal 本来想再反驳两句的，后来想了想每个人都有自己的思想，无关对错也没有对错。 另，祝你成功，再见！

@lesismal 兄弟，你说的这个就是 grpc 的双向数据流模式啊，你去看看文档吧。。唉，闭门造车说的一点不假。 你这要是跟别人技术交流的时候这么讲，就要被人喷了。

@lesismal
比如不只是 server 之间可以用、client 也可以请求 server
-你这个指的是 grpc 编译生成 client?
比如 server 也可以直接推送数据给 client 、client 也可以只推送数据不需要 server response
-grpc 的双向数据流模式
比如可以做的业务类型也不限于微服务，游戏、IM 、推送各种业务都可以做
-grpc 一样做吧，这个业务场景跟协议没啥关系。IM 都可以用 grpc 的双向数据流模式写，如果你想的话。
比如 arpc 不限制序列化方式，相同或者不同的 method 的每次请求都可以是不同的序列化，甚至也可以直接使用一段 buffer
-grpc 的自定义编码集
中间件之类的也都支持，而且是支持两个维度的中间件：编解码、路由，用户可以自己定制、扩展更多东西
-grpc 的 Interceptor?

或者这么说吧，正常大家能想到的常用的场景，grpc thrift 这种级别的项目基本上都已经有了，都不用想的。 所以，切勿闭门造车。

@lesismal 你抵触 grpc 我觉得没问题，但你抵触 api gateway 我就无话可说了， 因为 api gateway 这个东西怎么说呢，稍微大点的公司里面都有的，它是证明了自己的价值的。 还有，为啥要抵触呢？特别是你也是想自己做 rpc 的，更应该看一下现有的几个比较出名的 rpc 方案的优缺点，这样才能集大成于一体，而不是闭门造车，不是吗？
还有 grpc 用的广有一个很重要的原因是因为它名气大，适配的语言也多，遇到问题网上现成的答案也多，rpc 方案里能与它竞争的也只有 thrift ，在未公司项目做技术选型时选择一门成熟的、名气大的、适配语言多的、社区活跃的也是一个很重要的原因，它能帮你规避很多坑。
能自己手撸 rpc 协议乃至 7 层协议的很多，不稀奇，但是在微服务领域，一般除非是顶尖大厂（顶尖大厂为了规避法律风险、漏洞等未知风险、极致性能等原因），绝大多数都是用现成的，因为好维护、组建团队都比较方便。

@lesismal grpc 可以直接动态的完成 client 调用，grpcurl 可以看一下，grpc 协议也不是跟 protobuf 强绑定了，也可以用 json 作为编码格式。 链路追踪很多时候是用来记录 io 操作的，所以 redis mysql 等也会被记录进来，在开发和线上排查问题特别好用（例如线上一个接口比较慢，但看不出哪里阻塞的，链路追踪可以一眼看出症结）。 还有，绝大多数大一点的公司都有 api gateway 这一层的，它能做很多事情（接口配置、鉴权、限流、灰色发布、流量染色、数据清洗、编排等等等等），只不过目前你们还没感受到罢了。

技术，简单的场景有简单的方案，复杂的场景有复杂的方案。 我个人认为，技术人员，不应该让自己抵触某种技术，毕竟不会跟会但是不用是两码事。 至少面试的时候别人会让你回答怎么造飞机。

@version 我猜你说的 grpc 负载均衡的坑是在 k8s 环境下，新伸缩出的节点与老节点负载不均的问题吧？

今年确实很便宜，上海这边大白菜 6 毛 8/斤， 确实有点菜贱伤农的感觉。

@lesismal 看你写了很多，我就反驳你一条吧。

我看你写了“则每个接口都需要你把 grpc 那层、gin 这层都实现一道 grpc call 、method 的逻辑”

一般 api gateway 写好了之后，后续增加接口只需要在 web 页面上配置一下 path+method 转发到哪个 service 的哪个 method ，谁还需要一个个接口硬编码去转发？
还有，链路追踪这些跟微服务根本就没有啥必然关系，就算是单体服务，照样可以用链路追踪，它可以帮助你快速发现和排查问题。

还有，给 OP 推荐这个方案是因为 OP 说要搞微服务+api 网关， 业务该不该上微服务是 OP 自己的判断，我只是按照 OP 的需求推荐方案。
就算退一万步说，公司的业务确实单体就够了，但是站在知识储备和个人发展的角度来说，做一点过度设计对自己的职业发展、对公司的后期拓展也不是啥坏事， 而不是一句公司业务不需要就拒绝这些技术方案。