Aresxue

当然可以用 class 只是 interface 的耦合更低，一般优先推荐 interface ，内部服务能确定不需要给别的服务复用的注入 class 也没啥问题。

flink 没玩过，但是 canal 绝对是个坑，一个是 cpu 老是莫名其妙跑满，还有对主从模式很多地方都没有支持非常坑。

写一个 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 的节点里面新增一个依赖检测的节点就好