动态加载进阶，从组件到容器

又来了一个需求，而且和上一个几乎一模一样，却还是需要走开发和上线的冗长流程，不能忍了，必须要优化。
效率就是生命，复用就是延长生命的长度，如果通过配置文件就能拿下这类需求，就很赞了。
当然，前提是，系统在架构上支持复用。暨能够在组件的层级上，抽象出一个个功能组件，能够在服务的层级上，抽象出一个个服务组件链。不同的服务，链路上根据不同需求，装配自己要的组件bean，全部通过配置文件搞定。


以用xml做配置文件为例，看看怎么实现:
ApplicationContext实现了BeanFactory接口，可从中获得上下文所有bean，将其注册到XmlBeanDefinitionReader对象中。
XmlBeanDefinitionReader可以从外部的xml配置文本中载入新的bean声明，ApplicationContext为其提供了property注入。


这是一种依赖外部配置源的初级的动态加载，组件只能复用已经存在的类，通过声明新的bean来实现功能。


问题又来了，这个需求和上一个需求完全不是一码事，是不是只能老实点了。
每次都是改这些业务逻辑，别的都是框架。每次编译和部署，框架部分其实都是在重复一样的过程，不能把这两块分而治之吗？
业务模块改一改，独立成业务容器，解耦再上一个台阶。容器部分有单独的代码源，独立实时编译，这样就避免了发布过程。


简单说说如何实现:
首先从容器代码源（例如用JGit从git仓库拉取）拉取到容器代码。JavaCompiler执行编译操作，把java文件转为class文件，再copy到运行时路径。
然后ClassLoader把这些类加载到当前线程，框架类写在xml中，由ApplicationContext管理。这样两边的bean会师，就可以干活了。


上述是一个外部代码源的动态编译加载的容器方案，不需要发布就能支持大部分需求。但还是有点麻烦，需要多次编译，线上编译环境也有可能有坑，还能再方便一点吗？为什么不把编译放到线下，直接jar包热部署呢。


这个方案实现起来更简单点：
从中央仓库获取到所需jar，ClassLoader执行加载即可，然后就是常规的新bean管理了。


到这里，业务和框架的系统代码解耦和操作流程解耦都已经比较彻底了，依赖中央仓库的容器系统能很大程度地解放开发者。