Spring Boot自动装配多数据源SDK，如何有效解决Dubbo性能瓶颈？

Spring文章专栏：https://juejin.cn/column/7511884538579877939 明明学了自动装配，却鲜有机会实战？当我面对Dubbo性能瓶颈时，一个自定义Starter的构想让我开启了Spring Boot条件化装配的奇妙之旅。 引言：那些年我们学过的自动装配 记得毕业那会刚开始学习Spring Boot的时候，自动装配机制让我眼前一亮——"约定大于配置"的理念真是太巧妙了！相信很多小伙伴都和我一样，怀着好奇心去研究@EnableAutoConfiguration和spring.factories的奥秘，甚至动手尝试编写过自己的Starter。 但说实话，在实际项目开发中，真正需要自己实现自动装配的场景并不多。大多数时候，我们都是在使用Spring Boot官方或者第三方提供的Starter。直到最近，我遇到了一个实实在在的需求，才让我有机会深入实践这个机制。 背景：Dubbo调用成了性能瓶颈 我在公司参与的这个大型项目采用了典型的微服务架构，各个服务之间通过Dubbo进行调用。项目规模较大，因此分成多个开发小组，每个小组负责不同的微服务模块。 随着业务量增长，我们发现了一个棘手的问题：某些高频的数据查询操作通过Dubbo调用时，性能开销变得不可忽视。虽然单次调用的延迟不大，但在高并发场景下，这些开销累积起来就相当可观了。同时提供duboo的服务，因为高频调用已经存在并发瓶颈，频繁告警，如果继续增加调用量随时可能崩溃。（因为数据库规格较高，瓶颈不在于数据库，而只在于dubbo服务提供方，且因为各种原因无法进行横向扩容机器） 经过我们小组讨论，决定开发一个多数据源SDK，由我负责实现。让各个小组能够通过SDK直连需要的数据库，减少不必要的Dubbo调用。这个SDK不仅要给其他小组使用，我们自己也打算针对一些高频调用duboo接口替换为本地调用。 设计思路：条件化自动装配的多数据源SDK 我的设计目标是开发一个"智能"的SDK，能够根据配置自动装配所需的数据源、Dao和Service。业务方只需要引入依赖和添加配置，就可以直接使用相关的服务。 由于SDK中有些还需要包含一些业务逻辑，我们不能只提供DAO层，还需要提供Service层。为了避免与业务项目中可能已经存在的Bean出现名称冲突，所有Bean都加上了"Sdk"前缀。