用配置中心，国产的 nacos，apollo，外国的 consul 。纯用做配置管理的话 apollo 最好，但是 nacos 和 consul 还有个好处是它们还是服务注册中心，所以看你的项目技术栈选择。

17 楼方案加一
公认标准方案。
我试过几 T 的数据量都是这样迁移，不过只有几十张表，单表高达 21 亿条数据，依然很稳。

好奇问下，jdk 历史上有 breaking change 吗？

这波啊，这波是，开团开到娱乐圈了。

装 k3s 学 k8s，低配也能带，学命令足够了。

深色主题我最看重一点，注释要绿色的，官方默认就是绿色的，vscode 的默认的注释也是绿色的，但我喜欢 vscode 的配色方案多一点，刚好 idea 也有这个主题了--visual studio code dark plus theme。

有一张图，就是单机服务是一坨大 shi，然后拆成微服务是一堆小 shi。微服务只有配合容器技术，深度实践 devops 才值得，否则只是徒增成本。而且微服务不是全部，只是解决特定领域的问题的子集。

该走就走，反向思维，找工作最佳时机：年底。
金三银四虽然机会多，但是当备胎的几率也更高（求职者多，用人单位慢慢挑，offer 给得慢）。

我看这样吧，要不你别干了。

其实常见的解决办法是代码生成器，自定义代码模版，java 字段的注释来源于数据库表字段的注释。
即使不用代码生成器，这个注解也很正常，这个相当于顺手写，就算没有 @ApiModel 这个注解，按照规范，也要写字段注释。所以等于把这个注释拷贝到 @ApiModel 注解里面即可。

注册中心提一个 nacos，虽然是阿里的，可能会介意 kpi 产物，但用了一下发现很爽，服务发现注册速度很快，注册中心+配置中心做一起了，其中配置中心的功能比官方的 config 好多了。

@mysunshinedreams 由于 zuul1.x 性能不理想，且 zuul2 发布太晚，spring 官方自研 spring cloud gateway 作为新的网关组件，并且不会对 zuul2 做官方集成(所以没人愿意用)。

@laravel 除非 js 本身提供静态类型检查(但是不太可能)，那使用 ts 的必要性就很低了。

跟大厂走，比如 antd pro4.0 默认实现就是 ts，官方文档也是首推 ts。这是趋势。

sql 同理，只有 2 个字段的语句也必须一行一个字段。

个人倾向链式分行，我是分行狂魔，看到链式调用哪怕只有 2 个很短的函数连着都要每个点起一行，而且点必须对齐。

@karnaugh 对，很多情况下都是“专家盲点”，一个人掌握了某些事物以后，就忘记了当初自己一窍不通的感觉。

看情况的，很多东西没有绝对的对错，核心是以人(可读性)为本，多沟通，达成共识。比如 new().set()的用法，团队可以做一个规范，1.强制要求先 new，后 set。2.或者统一使用带参构造函数。3.或者不超过 1 个属性的时候可以使用连写的写法(因为较少属性的时候依然可以保持较高的可读性，不必排斥简短的写法)，否则使用 1 或 2 的写法。

换个思路吧，把异步放在 b 服务，a 服务还是同步调用 b 服务。