@liian2019 业务代码和工具包有着根本的区别，前者是需要经常阅读和偶尔修改的，后者基本不需要你做修改亦不关心可读性。可以掌握，但注意使用场景。

把不擅长的工作交给别人？

业务里面禁止写这种花里胡哨的代码。

看发言应该是刚毕业没两年吧？ 事实上不是对阿里程序员敌意大，而是他们身上携带的阿里味，至于什么是阿里味，百度详查。
此外，评价人不能光论技术水平，还有人品素质、修养等方面。

go 的 net 库算是 low-level ，需要暴露这个方法。

已 star

有什么需要使用云主机才能完成的功能吗？没有的话就虚拟机可以了，不用瞎折腾。

@kissdata #8 哥们儿，你穿越了。。我会 go ，但不熟 asterisk ，刚回复你了都。

@kissdata #7 那是我朋友的需求，没人接。现在不清楚啥情况了。

@Cola98 #3 我今天花时间了解了 Loki 方案，下面是我的一点看法供参考。
- 查询语言对比：Loki 方案使用自己的 LogQL 查询语言来查日，这个查询语言类似 PromQL ，对新手的上手成本并不低，是一个考虑因素。而相对来说 EFK 的 KQL 查询语言就很容易上手了
- 资源消耗对比：Loki 通过使用少量标签索引来加速查询，同时降低了内存/磁盘消耗。这一点比 ES 优秀很多，在大型项目中是一个需要考虑的因素。（但全文搜索性能可能不如 ES ？）
- 知名度对比：Loki 技术栈知名度应该远不及 EFK 的，生态影响不足。这也会导致网上关于 Loki 的讨论热烈程度不如 ES ，以及免费教程/文档/书籍的数量
- 熟悉人群：这一点也受知名度影响。应该优先选择团队人员熟悉的技术栈。如果都不熟悉，而你熟悉，那你可以给大家培训你推荐的方案。

鉴于精力有限，我可能没法把它添加到文档中了 https://i.imgur.com/ZveiiGy.png https://i.imgur.com/VUWFktU.png 。

@Cola98 有的啊，先看下

- 持续演进的架构。这表示定期就需要重构一部分旧的架构以优雅支持新的功能
- 完善的文档。具有一定复杂度的项目必须要维护足够清晰的开发说明文档，对于核心维护者和新人都是极大利好的
- 充足的人员。显然，仅靠少数几位核心维护者是无法完成上面两个目标的，项目要持续迭代，必须招入充足的维护人员