go 的内存优势在部分场景比想象中多

[momowei]

不是吵架帖子，但经常看 go 和 java 比较的时候，经常有人说，go 节省点的内存跟程序员相比根本不值得一提，我越想越觉得不对劲，对于最常规的 crud 来说，不得不说 java 确实比 go 还是要一些的，不过事实是 java 或者 php 程序员转 go 其实狠快根本没那么难，而且现在环境下程序员不一定就很贵了。

go 和 java 我自己都在写，一般来说对于不差钱的国企和政府以及企业市场，java 确实是最适合的，但是我也自己做一些小产品和项目给一些小公司，我能感觉到 java 和 go 对你拿单的成本影响是很大的，比如我有一个订票（城际定制商务车业务）小程序，有时候是我自己提供云服务器，我不得不说物理机的内存确实狠便宜，可是云服务器的内存真的很贵，新用户还不明显，老用户续费狠明显，在一台 2 核 4g 的云服务器上，我一般自建数据库和 redis,然后再配合 go 的应用，因为可能面对好几个客户，会有一些自定义需求，所以部署个五六个是狠轻松的，因为每个应用的访问量并不大，但如果是 java 是很难这样子搞得，这样给了自己很大得利润空间以及拿单成本。

说了这么多，我只能说 go 其实更适合个人开发者和成本敏感型得小团队，因为一般这样团队，都自己写程序，最大得成本就是云服务得开支了，最后再说一句云服务器得内存,cpu,宽带真得很贵，动不动类似 spring 全家桶那样得架构真得狠费机器。

[lesismal]

@fox0001 grpc 就是因为强制 HTTP2 才拉垮的, rpc 场景多数是内网可信的环境, HTTP2 的 TLS 就成了性能的累赘. 如果不是强制 HTTP2, 而是可选传输协议, 让用户自己选择是否直接使用 TCP 或者使用 TLS 等加密通道, 则会好得多.

[lesismal]

@fox0001 @lesismal #141 但 grpc 即使让用户可选传输协议是否 TLS, 也只是相比于它自己好得多, 仍然只是个 rpc 罢了. 我的 arpc 其实是通用网络框架, rpc 只是一个功能罢了

[lesismal]

@james122333 #140

标准库 rpc 对于多数人可能足够用了, 性能上虽然没有什么额外的优化例如 pool 或网络的优化, 但也比很多垃圾框架要强了

另外, 你可能把 arpc 想简单了, arpc 是通用网络框架, rpc 只是一个功能罢了, 比标准库 rpc 丰富多了, 性能也更强

而且, 标准库 rpc 可能还是需要有一些额外的坑需要处理的, 我没做测试只是基于简单扫了下标准库 rpc 代码的猜测, 不一定准确: 比如最基本的例如 timeout/context 好像是不支持, 如果只用普通默认参数没有设置 TCP Keepalive, 赶上 server 设备意外掉电或者维护重启没有 TCP EOF 则 client 的 Call 就可能死等着阻塞了, 自己做一些额外的封装也不麻烦, 只是如果这样子, 还不如别人都支持了的方便
当然, 只要满足你们的需求足够用就可以了

[james122333]

@lesismal

看了看它就不只是个 rpc... 是长连线 也可以做完断线 呼叫满满的 http style 拿来当 http server 也无不可 不应该以 rpc 为名

[lesismal]

@james122333 #144

> 看了看它就不只是个 rpc... 是长连线 也可以做完断线 呼叫满满的 http style 拿来当 http server 也无不可 不应该以 rpc 为名

大多数人对网络交互都局限在 web 相关那一套了, web 的人最多, 命名 arpc 一是为了讨好社区, 因为其他领域的受众太少了, 二是, rpc 也确实是一个大的功能项, rpc 也是 arpc 的主力功能之一而且把 arpc 用作 rpc 只比其他的 rpc 强(单说 golang, 其他语言我没那么多精力去实现和维护)

按 rpc 的定义, http 本身也是一种 rpc, 所以 http style 这种说法不准确, 至于拿来当 http server, http 做静态资源服务的话肯定是不适合用 rpc 来做, 至于 api, 确实可以用 rpc 替代, arpc 支持这么做的

最重要的是, 更广阔的场景, 其他 rpc 很难支持, 比如做 IM, 游戏, 推送服务, 用其他的 rpc 就不那么适合了, grpc 的 stream 一定程度上可以做一些, 但是 grpc 使用起来太麻烦了而且也局限, 远不如 arpc 灵活

网络交互, 就像我在 arpc readme 里写的, 主要就是 req-res(请求+响应), notify/push 不需要相应, 两个方向 client -> server 和 server -> client, arpc 都支持, 更多的业务场景, 一套全搞定. 不需要很多项目需要 server 推送那样再单开一个 ws 来做, arpc 当 rpc+server push 随便弄

[lesismal]

@james122333 如果有兴趣, #109 里的链接 "2022 Go 生态圈 rpc 框架 Benchmark" 这个帖子的性能对比可以看下, 性能强的基础上, 功能也比其他的 rpc 更丰富, 场景支撑能力更强, 扩展性也极强, codec, 中间件, 协议编解码都可以扩展. star 不如他们多不代表库没有他们好, 写得晚, 而且我个人没有大厂团队那么大的能量去推广罢了

[Rorysky]

要 redis 干嘛，直接 shm 写文件；数据库就用 sqlite3 估计还能再跑几个应用

[realpg]

@chendy #2
golang 的项目
api server 4G8G 的计算节点 *12
单机 api server 10K QPS
内存闲置 6GB
实在看着闹心
直接本机跑 redis cluster
每个节点拿出 5GB ram
形成了一个一个 30GB 的 生产 redis cluster