@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 有的啊，先看下

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

这还不简单，直接模仿吸引你的那些作品就完了

都是成年人了，这还分是与非呢。

这图一看就很有 England 味儿 https://i.imgur.com/ee8Lq7H.png https://i.imgur.com/ZveiiGy.png

上社，5min 步行到天河公园。有城中村和小区，500-2000+。以前住那边跑了一个月步，挺好的。

能找美团 4 次，楼主也算是个人才了。

期待楼主的干货~

最终如何选择要根据架构体现出来的复杂度/可读性/业务可维护性等多方面来评价，楼主先自行比较一下再做考虑。

@lasuar #42 足=》不足

楼主看起来 web coding 经验还是足，其实你多加考虑后会发现，这与定义多个接口并没有本质上的区别（多个接口仍然可以统一使用 POST 方式）。

So ，没有必要引入楼上说的其他技术来增加复杂度。

显然，不建议实说。很多父母都喜欢对外吹嘘，薪资应该属于隐私，暴露出去没什么好处，跟私房钱一个道理。

@byzf 做这个抽象(template, values)是为了实现它的灵活性。这就是 helm 的用处啊。简单的应用它的部署模板自然就简单，那相对应的必然也有复杂的。
根据你的描述，我认为你还是没有理解 helm 的真正作用。
另外，在部署之前，你可以用他的一个验证命令打印出实际的 yaml 内容，确认无误之后再部署。
你也不能说是 helm 依赖上游的 chart ，因为 chart 这个东西应用的官方自愿提供的，如果一个东西没有作用，他没必要花精力来维护。helm 自身只是一个将 yaml 和配置分离的工具，这种工具在需要经常迭代应用的时候是非常有用的。
最后，我想说的是，阅读官方提供的 chart 模板是可以帮助部署人员进一步理解这个应用应该如何部署的，特别是对于那些不擅长部署应用的开发者人员。

第一点没看懂啊，values 没定义你不能自己加吗，官方给的 chart 不符合你的需求就自己修改模板不就完了？

复杂项目搭建生产，比如 MySQL 和 ES 你确实可以不用 helm 的，用就得读一遍文档和模板，这没法避免的。但实际你的工作并没有简化太多，因为你要自己去编写 statefulset.yaml ，这不一定有官方 chart 完善。

@wjfz #29 之前考虑过，但是整个文档中需要引用的模板实在太多了，都贴到文档里面会把篇幅搞得特别大。这边也是建议一边练习一边看哈。https://i.imgur.com/MA8YqTP.png