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

主要是 spring boot ，还有就是 java object header 占用。
前者市面上应该有很多代替品
后者的话，JEP 450: Compact Object Headers (Experimental) 发布了会有重大改善

golang ，对我来说，一直只是玩玩，直到被 grpc 震惊……

给某师上了台 Intel 8380h*2/512G / 960ssd *2 和 intel 4310*2/256G/4TB*4 ， 跑的 java 服务崩了
居然说服务器和系统问题，
这 java………………

@zhjunjun

我 就算你不写 框架也会写
两条路 第一反射 第二代码生成
代码生成比较麻烦 代码量也变多了

回到正题不管什么语言全自写才是最省内存和 cpu 资源的

既然 golang 这么好，有没有推荐的 golang web 开发实践之类的呢，java 转 golang web ，写后端处理 err 有点难受，以及参数检验也好原始

@zhjunjun 你不用， 不代表别人不用。

随便说一个场景，golang 里面要上传超大文件， 文件达到 几个 g ，如果网络传输超快， 这是时候如果你再写入一个新文件，耗时增加一倍， 如果将临时文件 rename ， 上传时间减少一半，对于有性能有 kpi 的项目， 标准库里面没有暴露临时文件字段，这个时候反射就很有作用了。 当然你也可以自己上传的解析。

@fox0001 grpc 有啥可震惊的... 主要就是靠着谷歌爹的光环, 另外就是郭德纲那句: 同行(thrift 那些垃圾)衬托

grpc 除了跨语言优势, 性能不值一提:
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/

@lesismal

我用标准 rpc 确实不错 应该算是标准库偏少数拿的出手的 不过还是因为我不想用复杂的东西

@newaccount 不会还觉得写 go 多复杂吧

@jeesk #108 这倒是个不错的思路，我看了下，用不到反射，只需要简单的断言就可以了。

func saveFile(upload *multipart.FileHeader, dst string) error {
srcFile, err := upload.Open()
if err != nil {
return err
}
defer srcFile.Close()

if file, ok := srcFile.(*os.File); ok {
return os.Rename(file.Name(), dst)
}

dstFile, err := os.Create(dst)
if err != nil {
return err
}
defer dstFile.Close()

_, err = io.Copy(dstFile, srcFile)

return err
}

@bv 这样不好, 2 次复制了. 最好一次第一次直接解析临时文件, 然后 rename, copy 对于磁盘的性能占用很大,特别上 g 的大文件.

@jeesk #113 🤔file.seek 也可以吧，直接 seek 写，全部接收完了 rename

@jeesk #113 注意看：如果断言是 *os.FIle 就 os.Rename() 。不是才走 io.Copy 。

@bv
@guanzhangzhang

看到了， 断言好像是必要的。

最开始我记得也是自己 rename, 发现不太行， 才用的反射。

@bv 这里直接使用 rename 是不行的。 我自己手动设置了临时的缓存目录一样不行。 后面拿到真是的文件对象才能 rename 。

@jeesk #117 不明白你为何不行，至少我这边自测是成功的。
同时也测试出了 rename 存在一个限制：在 Linux 中，不同分区/分区格式不同时，会报错：rename <src> <dest>: invalid cross-device link ，这并不是上面的代码使用方式不对，只是系统低层的限制。rename 出错最好不要直接返回错误，而是要退化到 io.Copy 去兜底。

@bv cross-device link 错误后,直接拿到文件去 rename 即可.

go 里面尽量少用反射，本身和 java 的机制也不一样，没必要拿 java 那套来写 go ，这样本末倒置。

@helone #83 还真不一定，晋升总得搞点数据，没办法。提升 XX 就是最好的数据

@chendy 我的云服务器，1 核 1G ，一个 java 的 web 实例，一个 java 的端口转发程序，redis 、svn 、mysql ，你说呢？

@lambdaq #9 我一台 1c1g 的一样跑几个项目，redis 用的是 kvrocks 替代，内存是绰绰有余
@momowei 推荐你也把 redis 换成 kvrocks ，你就发现 4G 内存还可以多跑几个项目

@jeesk #119 就是 rename 才报的 invalid cross-device link 错误，不明白你说 “cross-device link 错误后,直接拿到文件去 rename 即可.”要表达什么意思？

如果你有什么解决思路，不妨分享一下代码，或者详细的描述一下思路。

@newaccount #5 语言不是壁垒，很多 javaer 看几天就可以上手了，还有 gpt 的加持，没什么太大难度。但是 go 实打实的节省 cpu / mem 确实香很多

@Narcissu5 #67 他们不听的,什么空间换时间时间换空间反正内存占用低就行了

不同的语言有不同的适用环境，没事儿一个个的非得 at 我愣是死夸这东西啥都好是不是脑子有问题？
但凡是个脑子清楚的正常开发，做个三五年之后什么语言不是三五天上手随便写？
但能够理解这个语言主导的开发思想和框架生态，没个三五年沉浸进去就别妄称会用
一门语言是不是值得学习，一个重要标准就是它是否能够拓宽你的视野，进而转变你的开发思路
OP 原本已经说的非常好了，go 适合的是个人开发者和成本敏感的小团队
假设配置三个后端，至少得配一个前端和一个设计，五个人的情况下，考虑的主要是人员变动后，是否更方便的补齐
招 java ，整体环境非常成熟，谁来写都是那一套，大差不差的，进来培训一下业务就可以上手了
go ？市场上人靠谱的人难找，又没有什么成熟的标准，几乎一个项目一个玩法，光让人适应这个团队的编码方法就得额外多花时间
等一年半载的培训好了，人家又觉得本事大了看不上小庙，那公司就是出钱培训是吧
对于一个能正常盈利的中小企业来说，服务器不值钱，而且对于 IT 团队是有一个正常的试错成本的，基本上每年十万以内的异常消费都不用跟上级额外说明，怕出错只会让人畏手畏脚不敢试错，最终造成更大的问题

@Charlie17Li 做项目看一看看这些，
go-zero https://go-zero.dev/ 是一个集成了各种工程实践的 web 和 rpc 框架。通过弹性设计保障了大并发服务端的稳定性，经受了充分的实战检验。
Kratos https://go-kratos.dev/docs/ 一套轻量级 Go 微服务框架，包含大量微服务相关框架及工具。
GoFrame https://goframe.org/display/gf 一款模块化、低耦合设计的开发框架，包含了常用的基础组件和开发工具，既可以作为完整的业务项目框架使用也可以作为独立的组件库使用。
gin-vue-admin https://www.gin-vue-admin.com/ 是一款基于 GIN+VUE+ElementPlus 开发的全栈基础开发平台
如果是做项目这几个都可以看看，都比较完善，社区活跃度也都不错，基础语法基本不用看，一边猜一边学就够用，其他问题 #127 newaccount 总结的很好了

@importmeta 老哥，那个 Bun 能不能把 nodejs 的项目打包成一个可执行文件呢？打包后程序体积大不大？比如一个简单的 koa 服务

@byte10 Webpack 可以, Bun 没试过, 方式参考 https://juejin.cn/post/7065724860688760862

@importmeta 虽然用 Webpack 打包了, 但是 Bun 可以运行打包之后的文件.

常年用 PHP-FPM ，用过一段时间 GO ，打包二进制后，爽歪歪，后来用了 PHP 的 workman 之类的非 php-fpm 后，重新拿起 PHP ，反正对我来用哪个都行，关键是开发出来的产品能不能挣到钱才是关键，所以现在关注的是快，所以我选择 PHP

@helone 32# 大厂 KPI 项目多如牛毛，中小厂 team 或个人也会自己设定目标做性能优化，但是往往止步于提高了多少性能，却很少提到减少了多少台服务器。国内服务器数量最多的公司是阿里，集团主流开发语言仍然是 Java 。

@wupher Spring 成就了 Java 的开发效率，但也是启动慢，吃内存大户的推手。很多人对 Java 项目的印象就是打包几百 M,启动几十秒甚至分钟级。其实现在轻量级 Java 框架，小项目秒启动，100M 内存也能跑，早不是动辄大几百 M 上 G 内存。不过还是得承认，对初学者来说，Java 很容易按照网上的资料写出笨重的项目来，好多人甚至吐槽阿里的 AI 写的 Go 也是 Java 那味儿。

@helone 这只是一方面吧，还有一方面是 KPI 问题

说得好 不过自己项目有前后端直接 nextjs+supbabase 一把全梭了 公司项目公司用啥就用啥

@james122333 标准库 rpc 算是中规中举，各方面一般。也可以看下 #109 我贴的连接，测评是鸟窝老师做的，最快的那个应该算是我的 arpc ，更快，使用简单，而且功能丰富得很，可以支持的业务场景也更多，包括推送、游戏、IM ，普通 rpc 是很难做这些场景的，欢迎体验

@james122333 arpc 的例子，可能比标准库 rpc 用起来还要简单些吧，像 net/http 一样简单：
https://github.com/lesismal/arpc?tab=readme-ov-file#quick-start

@helone #32 字节的 http 和 rpc 的 benchmark 数据是自称的，第三方测评跟他们官方的数据不太一致，最好是把测试条件对齐、自己跑下实际代码看看真实数据。另外，他们这些基于自家 netpoll 的库，在一些场景消耗不太正常，甚至用空间换时间、内存消耗比其他框架高的多、稳定性也存疑（我压测的时候就遇到过多次卡死、但其他框架都没事），如果生产上允许比较高的 cpu 那可能影响业务稳定性，如果只允许有限的连接数，那每个节点又没法省更多（跟其他 go 框架相比）

@lesismal #109 我震惊，主要是因为一直用连接池（短连接）进行 HTTP 请求，而 grpc 基于 HTTP 2 ，保持 1 个长连接即可。

@lesismal

callback 流 其实差不多

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

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

@james122333 #140

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

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

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

@lesismal

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

@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 随便弄

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

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