@wryyyyyyyyyyyy 试试看 EFCore 这种使用语言标准库语法的 ORM，你就不觉得自己封装的 SQL 好用了。这东西除了性能比较差外基本没有什么缺点。当然极端复杂 SQL 自动生成比手写的差这个 ORM 共性还是免不了。

@Muninn gorm 这个呢，就是用起来还行，但是总会有各种不爽的地方。另外一个好用的 ORM 不光要能映射查询结果，还要能自动 diff 差异然后 save，这点上 Go 没有能做的。另外就是受限于语法，查询条件怎么写都很难看和繁琐，最后还得依赖 codegen 生成一大堆 QueryXXX 的方法。

@abersheeran 什么合适用啥，我很喜欢用 go 写工具，部署起来那叫一个爽。但是写业务是不行，我有点受不了。业务我们换 C#了，忙的时候还能从客户端借人

@abersheeran 主要是这得手动搞，依赖一多很烦。另外注入的话另一个好处是免去手动构造对象，在参数变化的时候少一点麻烦。其实说白了就是我懒，自动档开惯了不喜欢手动档。

@balabalaguguji 其实还有一个我不喜欢的地方，因为 go 没有 attribute 或者 annotation 类似物，所以路由基本都是集中式。但是我非常不喜欢集中式路由。外加没有依赖注入，我不喜欢手动管理一大堆（指十几二十种以上）的依赖组件，这简直是折磨人。。。

@iPhone9 菜就菜吧，但是它节省了我的时间啊。

@iPhone9 那肯定没有我直接修改内存数据然后 save 一下了事香啊

@balabalaguguji 我喜欢 ORM 是因为很多时候真的不需要性能，而我又不想手写 update 语句。

@kidlj 我说的是没有好用的，不是没有能用的。

@balabalaguguji 比方说，没有好用的 ORM

其实就是 go 没有协变。

@ily433664 我觉得虽然不用精确到个位，但是给参考价格就还是尽量得百位准确吧，不然让人很难参考。5950x+unify 这种组合也不算丐了，不也就顶天 6k 出头么。

@ily433664 你这个价格我感觉是真的不准啊，有的高了有的低了。比如板 U 就算上到 5950x 我觉得也就 6000 出头，只要你不搞那些 3k4k 的板子。内存 3600 的 128G 4k 你拿不下来。SSD 1T 可以比 1k 高很多也可以比 1k 低，电源 500W 用不到 500，1000W 的 1000 你拿不来。

@Mohanson 那我觉得你很可能找不到适合的语言，主流语言里除了 Go 现在似乎没有不支持泛型的得了。

@GeruzoniAnsasu
一圈回复看下来，raii 都已经是时代的眼泪了。

@hopingtop
1. 关于配置的复杂与否，我觉得还是看是否熟悉这套东西。比方说如果从来没用过 mgo 的团队，重新了解一个新数据库的工作量也不小。
2. 不用分片复制集的话，数据安全怎么保证呢？
3. S3 存储不会有啥问题，它的日志存储模式就和一般的日志系统不太一样。碎片化是肯定不会有的，它的日志存储是会分块存储的，类似 HDFS 。
5. 这个我同意，但是报警本身就是一个很复杂的事情，过于简单的配置线上用起来感觉有点束手束脚的。我其实觉得 alert 那个都还是表达能力有点弱了 2333333
6. mgo 分片集的分散写问题，只需要加大一些批量写入的条目数问题就能解决了。如果没那么大量的话可以考虑不用 hash 模式来做分片。

关于数据存储的占用这块，Loki 的存储模式和数据库这种其实差异很大，最直观的例子就是你用时序数据库和常规的数据库比如 mgo 同样存储一些连续点数据，看看数据占用。这个是对比度最强烈的。

@hopingtop
1. Loki 的配置已经很简单了，会需要大规模日志收集的基本上也需要指标监控和追踪。在使用 prometheus 的前提下几乎没有啥额外成本。如果是全新上一套新的项目要引入的话那这件事本身就是一个 KPI 嘛。
2. 配置复杂这件事我觉得和 mgo 的分片复制集相比半斤八两。。。
3. 远端存储里，别的不谈，我还没见过云厂商有不提供 S3 兼容存储的。
4. Label 那块确实有坑，按一般理解来用的话会踩大坑倒是，不过那个最佳实践其实十分钟就能读完了。
5. 那个规则是可以实时变更的，至于写起来是否复杂我不能决定，这玩意就和语言一样看个人。
6. Loki 的存储压力比作为数据库的 mgo 的压力更小的，而且 mgo 需要做分片复制的关系压力其实更大，因为其是一个数据库没有针对性做优化。关于数据存储这块你可以继续参考官方文档，他们有不少优化。日志这种东西如果因为量大就删除的频繁我觉得不是个好主意。
7. 展示这个。。好吧他确实没有 Kibana 做的好。

那么问题来了，和 Loki 相对比有什么优势？

@css3
亲和性解决不了你的问题。亲和可以让 pod 尽量分散，但是无法绝对平衡 pod 分配。我觉得你应该从别的方向入手。比方说，为何同一个部署下会需要这么多 pod ？节点资源只有这么多，增加 pod 并不能增加吞吐。减小 pod 数量到 2 再用亲和就可以。如果说你的一个 pod 只能使用有限的资源导致利用率不满，那就给容器配置资源限制让 k8s 自己根据资源容量调度。