写一个 XxxBeanSerializerModifier 继承 com.fasterxml.jackson.databind.ser.BeanSerializerModifier 获取注解做修改

修改 spring mvc 序列化的 objectMapper 对象，objectMapper.setSerializerFactory(objectMapper.getSerializerFactory()
.withSerializerModifier(new XxxBeanSerializerModifier()));

因为这样信息更全面，不考虑 open tracing 的标准，仅从开发人员角度出发，如果业务代码中循环调用同一个 dubbo 服务不在消费端开一个 span 你很难一眼看清是第几次 consumer 出了问题其当前的调用对应的 provider 又是哪一个。从系统调用的层面看 http 入口是主调用，database 、mq 、cache 、rpc consumer 这些是子调用，而对于下游应用来说 rpc provider 则是入口，即满足 A 的子调用是 B 的主调用的链路逻辑，每个应用既是应用自闭环的同时还是全链路的一部分，举个比较极端的例子，A 是本业务域系统使用了 SkyWalking ，它消费的服务归属于另外业务域的系统 B 是没有 SkyWalking 的 agent 当然更不会上报链路信息，此时如果没有 DUBBO Consumer 没有新开一个 Span 将如何标识这一次 dubbo 调用呢？

数据库里不要用 not null 设个 default ''好了

一个是历史原因，dubbo 开始的时间挺早的，那个时候 AsynchronousServerSocketChannel 可能刚出现甚至没出现，第二个是 java 里面并没有真正的 aio ，很多时候 aio 的实践效果反而没有 nio 性能更好。

动态装载的类也是有它的开发环境和过程的，可以考虑在开发过程中把这个类使用的类打包为一个新的 jar ，装载时使用自定义的 classloader 去 load 这个 jar ，至于实际实现的话可以用静态分析（ import 的递归和对反射的分析）和动态分析（限定类的指定运行方法，开发时自己 run 一遍将 jvm 中所有类都记下来，将 jdk 和已有依赖的类排除其它的类合并为一个新的 jar ），这东西简单想想还行实际做起来确实挺复杂

指定编码格式为单字节编码，如"ISO-8859-1"

@idblife 是在发布流程里面利用 maven-enforcer-plugin 做检测，不是让应用工程引入，如
mvn org.apache.maven.plugins:maven-enforcer-plugin:3.0.1:enforce ，在发布流程中执行该插件，不满足规则则不允许发布，有 jenkins 在 jenkins 的节点里面新增一个依赖检测的节点就好

稍微大点的公司都是有基建的，很多都是基于 jdk8 的中间件去做二次封装和二次开发的，你让基建一下子全部适配高版本 jdk 几乎是一个不可能的事实，除非你要做一个独立性很强且足够简单的应用可以不依赖各种中间件和原有的登录、权限、账号体系，这样才算是真正的没有历史包袱的，否则上述每一个地方都会是拦路虎，到最后你可能会发现降级到 jdk8 是最佳方案。

依赖 devops 去做吧，加一个依赖检测环节，本质上基于 maven-enforcer-plugin 去做各种依赖校验就好，不通过就不给发布

简单点就 proguard ，复杂那可真就太复杂了

com.baomidou.mybatisplus.core.handlers.MetaObjectHandler

我买了汉。预算内买贵的一般都不会错，钱这个东西花哪哪儿好

users.stream().collect(Collectors.groupingBy(User::getKey);

链路用 skywalking （ pinpoint 要能接受比较高的性能损耗），线程池和父子线程的问题用 TransmittableThreadLocal + mdc 解决了，zipkin 是侵入式方案个人不是很喜欢，trace 、metric 、log 还是非侵入式的用起来更舒服，业务也没有感知。

生产级代码就别自己写了，用 https://github.com/baomidou/dynamic-datasource-spring-boot-starter 这个好了，唯一要注意的是分布式事务的部分需要自己重写一下，如果是为了学习也可以看一下人家的代码，也是 AbstractRoutingDataSource 这个路子

@ychost dragonwell8 中的实现还是非常重的，loom 其实不是传统的协程更应该叫纤程，之前听梁希他们分享过他们实现的协程，他自己也说会比较重，主要还是因为他们最开始做的时候 loom 还不存在所以想自己做一些开创性的东西，不过到业务系统层面除非是阿里那种规模的集群其它的大差不差了

@ipwx 这种是不是比较依赖 hash 算法，不然 hash 碰撞了不就 g 了吗？拿时间换空间？

说一下他们的差别好了, 有没有意义自己见仁见智吧
1.服务器上只有一个 jvm ，code cache 什么的只有一份，内存回收的效率比较依赖 gc ，g1 和 zgc 对大内存比较友好，如果是比较老的 jvm 可能会比较拉胯，值得注意的是超过 32G 以后 jvm 的指针压缩会失效导致内存利用率下降；
2.1 个 tomcat 启动 10 个 jvm 进程，这种我认为和第三种区别不大，唯一的区别是所以应用的配置比较容易保持一致，但你本身暴露端口之类的配置还是要在启动一个实例后修改（不然会端口冲突），个人角度认为没必要；
3.这种算是目前比较主流的方式，优点就是可以滚动升级服务没有不可用时间，同时如果代码有内存泄露等问题，能够先局部重启保证服务可用再保留部分应用慢慢排查问题，很多问题的影响范围可以被缩小，它的缺点是同样的 code cache 会有重复的多份比较浪费内存，一些内存级的缓存也都会被缓存多份，还有就是一些单 jvm 没有问题的代码可能会出现一些问题（这个属于代码的问题可以避免和修复）
题外话：一般的 java web 都是 io 型项目，其实 cpu 都是利用不充分的，32c 和 64g 基本上两者的利用率是对不齐的，可以再多请求一些内存资源

因为大多数业务应用都是 io 密集型，这样可以更方便的压榨 cpu ，这么做的有 tomcat 、dubbo 、spring 、netty 等，接收请求的线程和处理线程一般都是分开的，业务代码这么做要看情况而定。