我曹，1w 行代码。。。

@QlanQ 就重构花费的成本和风险，足以让多数人望而却步了

刚失业的时候:下一份工作不能换城市，不能是外包
失业三个月的时候:下一份工作不能换城市
失业半年:哪个城市都无所谓，有活干就行。
失业一年:城市无所谓，外包也可以，有份工干着就行

正好杭州回湖北农村，差不多 900KM ，带老婆孩子，已经打算开车了。

无脑选交通银行，经济再差都不会裁到你。
以后 10 年是经济下行区，码农 35 岁毕业不是和你开玩笑。

linux 下直接 split 指令，或者自己直接手写一个也行。

问题没看懂。
1.有两个下载流程。一个是文件从 obs 到服务器，第二是文件从服务器到 win 本地。不知道你说的是哪个下载流程。
2.如果 obs 和服务器的出口网速有限制的话，你再努力也是白搭阿。
3.大批量下载文件的方法无非就是批量下载阿。你可能只是想求一个批量下载的工具？

这是一个批量接口，目的是接口接收数据，数据交给协程存入 Kafka ，接口立即响应成功，越快越好，请求频率每秒 70 次，一次请求数组携带 1000 条数据。单次请求数据大小 500kb 。
============================
先说最简答的方案，加机器。后端服务本来就是无状态的，kafka 也绝对不是瓶颈。而且你自己也说了后端服务内存压力很大，那直接加机器就好了。

其次，在不加机器的情况下，你的代码还有可以继续优化的空间。后端收到请求后不校验，直接完整的将 http 请求写入 kafka ，省去序列化( http 请求到 struct)和反序列化(struct 到 kafka 的 body)的 cpu 。由后续的消费者去一次消费 1000 条消息做处理/校验。

技术没有银弹，完全看你怎么取舍。以前我可能采取第二种方案，现在年龄大了，不想折腾了，我只想会加机器。

感谢！

@424778940 +1
c/cpp/rust 楼主你有很多种选择的

可以换个思路。
1.一天 20 个文件每天都会有人下载吗？直接用播放器在线播放行不行？需要留存的在下载。
2.如果是监控视频的话，可以把静态的部分直接处理掉。

@avalon8 Python 上限高，Java 下限高
========================
我觉得你恰好说反了，应该是 Python 下限高，Java 上限高。
现在已经没有 AI 相关的职位给本科生了，除非你是清北毕业。剩余的职位就是 web 相关了，直接去 boss 直聘搜下就行了。

能考公就考公，考不上在做码农，35 岁毕业真不是开玩笑。

目前遇到的问题是，如果 server 返回 error 并关闭连接，proxyB 上负责接收 client 方向请求的 goroutine 会卡在 client 方向的 stream 的 RecvMsg 这里，需要接收一次来自 proxyA 的请求才能退出。同理，proxyA 也需要 client 发送一次请求才能退出。
=======================================================================
proxy 就是应该完全透传收到的请求阿。proxyB 都收到 server 的 error ，并且和 server 的连接都断开了，理所当然的 proxyB 应该和 proxyA 的连接也断开。
ps1:grpc 是长连接没办法做负载均衡的，不知道你为什么要用 proxy 来做？难道是网关？
ps2:proxyB 对长连接的处理直接用两个 io.copy 就完事了。任何一个 copy 出现问题，都可以手动断开两边的连接。

加油！

闲得蛋疼才重构。

https://imgur.com/a/NNn8cau

工作 5 年一会用 mac book ，后来换了 windows,上了 i5 13600k+64G 内存+2T 的硬盘，才脱离定期清理硬盘的恐惧。你问我开发体验怎么样？我只能说早用早就爽飞了。