就我所知绝大部分 Golang 开发的偏基础设施与中间件的大型项目（ Kubernetes 、VictoriaMetrics……），以及包括 Go 语言 Runtime/Compiler 本身都没有使用 DI 框架。

所有的依赖都是自己手动处理的，通过一系列的 NewXXX 函数以及工厂方法。很多 struct 可能就是全局的，在 go 启动时候就创建起来，然后在 package 范围内可见。在一些场景里可能会用一个比较大的叫做 "xxxCtx" 的上下文 struct （注意这个只是 struct 起了个名字，而与 context 标准库无关），用来维护传进来的 dependencies ，供这个上下文的方法使用，对于内部的 struct 有点像一个 DI 容器吧，但这个 "DI 容器"的依赖本质还是自己维护的。

个人觉得手动管理依赖并不是邪恶的，Go 的隐式接口实现可以做到不少代码较好的解耦（虽然隐式接口实现有单独的槽点），Go 项目里这些 struct 的设计也大部分实现了依赖注入模式（构造函数注入、方法注入），足以支撑复杂的项目。

然后 Go 项目很少使用 DI 框架，这样大型项目手动维护一个 "Unit" 几十上百个依赖是不是太麻烦了？事实在于，Golang 这些项目的开发者不少都认为一个"Unit" 不应该和所有依赖进行交互，而应该专注于具体的事情，去看这些项目的 struct ，他们的依赖基本上也是可控的，大部分都是最最多十几个这样了。如果一个组件依赖过多，可能需要思考是不是该重构了。

当然对于大规模多人的业务需求迭代频繁的大型 Web 应用项目，我觉得依赖注入 DI 框架还是有价值的，因为这种迭代变化频繁的项目可能会有很多业务驱动的 Service ，用 DI 框架能够提升开发效率，让搬砖的 IT 民工（比如我）不需要关注很多细节，但另一方面微服务模式一定程度上也降低了单体的复杂度，缓解了此类问题

@kneo 我觉得整体的交流讨论本身还是有益的，像我之前也一直把 goroutine 称呼为协程（ coroutine ），虽然我知道现在 goroutine 是抢占式的，但这么叫也说明我自己对于计算机系统的理解不够深刻。

就中文互联网而言，看到的诸多讨论、书籍，包括我之前面试字节的时候面试官都直接将 goroutine 称为“有栈协程”，这个偏差认知在国内应该是很普遍深入了，但反而是有引导到正确认知的价值，后续我应该也会尽自己所能去传播这类正确的知识。

@trzzzz 是指定时器的 duration 会加上 10% 抖动的做法吗？

在补 Better Call Saul 风骚律师，到第五季拉罗登场了
比 Breaking Bad 更让人沉迷

@Flourite 嗯嗯，我觉得其实不少点在后续诸位老板的讨论输出的知识内容里已经比较清晰了（虽然有不少价值判断与情绪输出 hhh ），这样读到的人在了解之后对于这些编程语言都会有自己恰当的判断。

此外这套方案是通过牺牲数据完整性来提高性能的，因为这里很明显会有一批热数据还在内存里没写到磁盘的，所以如果发生断电等事故（程序没有优雅关闭）势必会有一些数据丢失，如果要保证数据完整性就需要引入 WAL 日志机制以及频繁的 fsync 同步写入来保证数据落盘，这个会非常影响性能，所以看自己权衡了，但 IoT 场景应该还好要求不高？

这里说个不用轮子如果自己实现的思路，可以参考 vmagent 的设计：

https://jiekun.dev/posts/vmagent-data-structures/

程序内部自己维护一个内存的数据队列（在 Golang 就是 Channel ），一批接收请求塞到队列里的 handler （ cpu num 个 goroutine ），以及消费内存队列数据块的 consumer

请求会以 round-robin 的形式分到这些 handler 里，handler 需要把接收到的请求里的数据组装成合适大小的 block （可能是几十兆？这个是调优参数），然后当 block 足够大或者每隔一定时间后，handler 就把 block 刷到内存队列里

塞进队列之前，会有一批 worker （应该也是 cpu num 个）会序列化（ protobuf 或者自己定义的二进制协议）并基于 snappy 或者 zstd 算法压缩这批数据 block ，压缩的关键在于大大减小原始负载的数据大小，进一步增加后续磁盘写入 IO 的吞吐

consumer 会将内存队列里的 block 拿出来顺序写入到本地文件中，多个数据条目拼装的 block 且经过压缩，落盘的吞吐还是比较理想的。

你需求的数据量其实也就每秒 2M 左右，如果压缩一下甚至这个数据量会更小，所以理想情况下应该比较低配的机器就能够满足你的要求。

核心就是组装（其实就是 buffer 的思路）和压缩，来尽量提高顺序 IO 的写入吞吐，这是容易产生的瓶颈。

当然这套方案只考虑了写入，在查询上是没有什么优化的（没有索引），所以如果要实现比较好的查询的话可能还是要考虑开源的轮子，基于 MergeTree 的 Clickhouse 以及 VictoriaMetrics ，或者 InfluxDB 等时序数据库方案应该能很好满足这方面需求，但思路还是要注意写入数据库时数据的合并来实现对于 IO 吞吐的友好

@lesismal #11

> 通常的定时功能没必要加抖动, 这个库的具体内容我没看. 定时加抖动有可能是为了避免同时创建大量具有相同超时时间的内容, 后续同时到期去创建大量协程异步删除内容导致 goroutine 过多造成不稳定, 或者其他什么特殊的需要

应该是这样，像 Kubernetes 项目里也会用到很多 Jitter 去避免相同的超时时间（ https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apimachinery/pkg/util/wait/backoff.go#L203 ），像 kubelet ， 以及几个组件的 LeaderElection 都会用到，确实还蛮常见的。

fastcache 也是分片锁的思路，切成 512 个 buckets ，进一步最主要就是针对 GC 做了优化，索引用 map[int]int noscan 来减小 GC 扫描开销，实际 key,value 放在一个自己手动 mmap 分配管理的 chunks （[][]bytes ）里，跳过了 golang 自己的堆 gc 。这套思路上生产很多场景应该是够用了

@lesismal 所以一般定时要求不严格的话很多 Golang 开源项目会给定时 duration 加个 10% 左右的随机抖动吧
例如 VictoriaMetrics 的 timeutil.AddJitterToDuration - https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/lib/timeutil/timeutil.go

我觉得不一定是拉踩，针对 Golang 的这一情况可以添加更多的说明会好一些。

如 @lesismal 老板所说，这里 golang 的开销应该是有栈协程的开销，一个 goroutine 栈默认最小是 2K ，1000,000 * 2K / 1024 / 1024 = 1.9G ，算上 sudog 等其他的结构加起来可能差不多吧。

实际 golang 处理异步任务的时候确实不会开这么多协程，更多是把协程池化然后基于 channel 通信来处理。

在实际 Golang 开发过程中确实会有每个 conn 对应一个 goroutine 大量连接导致内存过高的 case ，然后社区里确实有对应魔改 netpoll 以及 nbio 这样的方案来解决类似的问题。

@duebasser 主要我觉得作为闭源商业方案其性能与稳定性问题不想着如何解决，反倒变成了绑架与讹诈客户的工具，还是挺逆天的。

之前达梦的 .Net 驱动有很严重的问题，驱动执行一些 Insert SQL 失败会吞掉偶发异常，导致上层代码对于数据丢失不可知。

甲方对于达梦数据库的性能以及稳定性意见非常大，PG 32 核 64 G 的配置可以跑很稳妥的数据量到达梦这里好几倍的配置也经常崩溃以及丢数据，达梦那边给的回复是需要上集群版，张嘴报价几百 w…反过来绑架客户了

后面要求研发侧对于项目上国产数据库方案首推用人大金仓（好歹基于 PG ）了，如果有甲方要求用达梦会郑重劝告（ x

完成度很高👍

@qiuhang 其实我也猜测是这样，团队里没有专业一些的工程师。
但类似的专业度不足的问题过去几年已经出现过好几次了（ helang 、掰天线……），公司应该是盈利的，他的人脉哪怕只是找个顾问把个关应该也不难（不找其他 up 主，找个大厂上班的老同学或者学长之类也成吧），到现在还没解决这个问题只能说 emmm……

主要还是营销技术宅人设带来的反噬。

何的早期视频看出来属于是一个有自己创意的数码爱好者（果粉？）。但应该是 5G 视频之后为了接住这泼天的流量，何开始往“技术宅”人设开始转型，然而问题在于和手工耿、稚晖君不同，他自身的专业水平是不足以支撑这个人设的。

如果何同学团队具有一般软件工程师的专业知识储备，就会知道：
1. ascii generator 本身很简单，就算是自己写的也没啥了不起的，没必要抄别人的项目
2. 如果基于别人的开源项目实现也 OK ，但要遵循别人项目的开源协议，哪怕是非常宽松的 MIT
3. 哪怕再恶劣些，我抄了别人的项目说是我做的，但只要我视频里没有证据也不会有什么舆情，因为还是那句话 ascii generator 很简单，自己会写也不奇怪。

最烂的情况就是现在：我拿了别人项目声明是自己写的，然后把证据放到视频里还不自知。

之前看过何同学关于自己在互联网舆情的访谈，我觉得多少是可以理解的，但我也确实没想到 2024 年快结束了他们团队还会犯这种基础的专业性错误，确实有点自业自得了。

主要就是 @CLMan 老板提到的接口类型约定的是方法调用，所以大部分场景不需要检查接口的值是否为 nil ，要检查通过类型断言或者方法内部来检查。

Go 的语法细节确实有很多实际运行起来不符合直觉的地方，很多时候一定要结合它的内部机制甚至看源码才能顺畅理解， 虽然这些机制大部分理解了也确实比较简单吧（所谓“大道至简”…

感觉控制协程数量的场景属于内部造轮子可以解决的轻量需求，如果是我的话大概率也是自己造轮子来定制（参考开源实现）而不是引入第三方依赖。