然而自从 red hat 的 runtime 要求 java 17 而 Gradle server 在 Java 17 下连不上之后我就回到了 Intellij Gateway 上。。。

--dry-run, helm chart, skaffold, k9s, tanzu 总有一款适合你。
我司的 SRE 部门用的是 kustomize 以及各种 shell script

要不是公司电脑显卡不行我会想放 4+1 ，IDE 一个 Terminal 一个浏览器两个，最后笔记本放 Outlook+Slack

@xiaoyu2er 那个学校的官网上写的啊

希望实时那要不要考虑直捣 etcd 去 watch key ？

看了一眼你的文章，你确定你申请的这个 MSIS 是让你润的？为啥写了个 online degree ？

如果你觉得负载是个问题，你上了微服务可能负载依然是问题，因为你的 VPS 的可用资源没变，而且你可能还需要额外的开销去维持多个容器运行时，很有可能得不偿失。。。而且上微服务通常是是为了扩展性，而拥有扩展性的前提就是你有足够的计算资源去给它扩展。。。

@love2075904 那就看你们对于微服务的业务范围的定义了，这个都是要讨论看 trade-off 找平衡的

我司的做法是抽出来了一个单独的微服务负责所有的 send message ，需要同步的用 REST call ，不需要的用 Kafka event 处理

然而我们还有 Grails 的组件，自带到 2.5 ，且只宣称支持 up to 14 ，那么问题来了，我们的 Grails 组件谁给重写？
然而我们还在用 Gradle 5.6 以及相应的插件，别说升到 3 ，升到 2.6.3 就已经需要 Gradle 6.8.x/6.9.x/7.x 及以上了，那么问题来了，我们几十个 repo 的 gradle file 以及我们自己的插件谁给我们重写？

巧了，我司 toB 产品是商业软件，从 monolith 往微服务拆，装到 k8s 里的。
私以为，微服务架构和 k8s 本来也不该是替代关系而应该是同一个抽象思想在应用层和基础层的实践，所以替代二字本就不该谈起。对于存储，我们用了一个单独的 dbs service 来封装了存储层，然后就继续沿用原来的单点存储了，平滑过渡，也不是难事，而且生产环境还有一部分扔给了 AWS 。

有一种直接对脊柱下手的治疗手法，国外归 Chiropractor ，国内是有一部分中医院可能会有，主要是帮你把脊柱错位的一节或几节按回去，通常情况下能缓解很多问题。可以上油管上找一个 Dr Rahim 的医生的治疗视频，他有一些视频里会很详细地讲解他的治疗手法，告诉患者病灶来源于哪一节的错位。按回去之后还有很多后续的针对肌肉代偿的恢复和生活方式的调整的讲解，还是很有意义的。我去年回国的时候有幸遇到了一位中医大哥，按完以后感觉整个人都不一样了，走路挺胸抬头的。

@fsdrw08 能写，能 build ，能测试，但是对 ant/gradle 一类的支持不如 intellij ，而且没有 remote debugger