@rrfeng 我也想过这个方法。就是语义没那么明朗。

原来大家都是不依赖 CI 工具的语法写 CI Job 的~~


@FlytoSirius 关于 secret ，至少我感觉 Jenkins 里的 secret 不是很好用。才萌生了把配置放入加密代码中的想法。

@CivAx 谢谢~ 我去了解下。

说得很对，主要就是 PromQL 还不熟。 之前在生产环境上，把服务搞 OOM 过。准备自己搭一个学习环境 来玩一玩。

@Frankcox grafana 里我看了下，主要都是根据 namespaces 的维度来看资源使用情况的，刚好没有节点的。metrics 我相信是收集了，只是没有配置对应的图表。 后续去看看怎么配置。

@salmon5 w(ﾟДﾟ)w 哇哦！ 感谢，感谢~

企业大到一定程度，肯定是要追求私有化部署的。别致盯着国内看，你看看国外，Google 会把服务部署在 AWS 上吗？


你说的更多的是中小型企业，据我上一份工作的经验，这类企业大部分是接受 SaaS 的。

我自己觉得 DSL 多了，要记的东西就太多了。不同的 DSL ，等于有不同的编程语法。

但是矛盾就在于，DSL 本质上是沉淀的结果，总不能每次写个新东西都从二进制开始吧？

只能说希望同领域、同场景的 DSL 语法最好趋于相近，能有一个统一；不同领域、不同场景的 DSL 的语法，能遵循一定的规律。

据说，候补多的话，会动态加开列车。有人这样买到票吗？

这样挺好的。成熟化的软件领域就得是这样。假使，每次要写个 web 项目，都要先写一个 web 框架、db 框架、甚至要写个新的操作系统。

总还会有新的领域会出现，等待有识之士去占领。

@maocat 之前 2022.1 出的时候，升级之后也是各种 bug ，我才退回到 2021.3 ，结果就一直用到现在也没什么大问题。

哈哈哈~

@yinheli @ss098 这个倒是，我也是这样做的，resource “代码化”，进而方便管理。

@arloor “掌控感” 用得很精准，我也是这样觉得。那么多参数看起来会紧张。

@ho121 感谢。恍然大悟！

写得真好！

看到 2 楼喷 session+cookie 我就想笑。

Web 场景下，你 jwt 放哪里？不还是得放在 http-only + secure 的 cookie 里？

什么？你不放 cookie 里，你要放在 localStorage 里？注入的 js 攻击分分钟偷走你的宝贝 jwt 。

@musi 这玩意没办法给你完全解决。你说，API 请求到的对象，就是不安约定的来一定要少个字段，这种无解。 但是其它大部分情况，都能在 build 时报错提醒你某某字段可能是 nil ，你需要处理好。

另外，纠正一下，溢出的是 JS Runtime ，不是 JSON 。在你把一个 int64 转成 JSON 格式的时候，它并没有“失真”，可以在其它支持 int64 的语言里试试。

之前看 Twitter 的前端代码的时候，偶然发现他们有 `id_str` 这样的字段，今天翻了下文档，果然是为了处理大数溢出问题。https://developer.twitter.com/en/docs/twitter-api/v1/data-dictionary/object-model/tweet