畅谈Java模块化与微服务

微服务这2年的发展太热门了，这阵势很容易导致开发者一叶障目，首先微服务是需要一些技术沉淀的，其次和业务体量、开发团队的规模有关，这里不展开探讨微服务之殇。业务的复杂度继续堆积犹如潘多拉魔盒，本文将从依赖、模块化的视角来展开探讨。提前模块化，要从大神毕玄的osgi模块化中国社区谈起，模块对代码进行了更高一级的抽象作为一个基本单位，表现形式通常为一个jar或一个fat-jar。

众所周知的，我们一般传统的应用都是采用三层架构来构建，而阿里的规范中，新增了一层manager，它包含通用业务处理层，包含对第三方平台封装的层、对Service层通用能力的下沉（如缓存方案、中间件通用处理）、与DAO层交互（对多个DAO的组合复用）。我们需要做的就是归类，对不同的业务使用不同的技术或规约进行隔离管理，通常使用的方式大概有这些：

1. 通过声明式规约：package

通过package来实现模块化间的隔离，这种方式这种方式确实比较容易，

通过规约可以将不同的业务模块划分到不同组种，但模块与模块的同享一个进程、同享一个数据源、同一个classloader、他们依赖并不太精细，随着发展，会越来越难以管理，最终会发展成巨石型的应用。

instance
    order
       manager
       controller
       service
       dao
    stock
       manager
       controller
       service
       dao

2. 通过classLoader隔离：OSGI

用OSGI技术，用felix、karaf或者Jigsaw这样的容器对jar包进行暴露和隔离。用Bundle包对jar包再进行一级权限管理，将一些导入或导出的资源配置在Manifest文件里。这样我们就可以在Bundle层面进行功能的引入和暴露。同时也在bundle层面引入了Activator的概念，用来向外部模块暴露自身的服务、或者是注册一些生命周期的代码。

虽然，每个业务组件有一个独立的ClassLoader，因此不同业务组件之间的依赖不会互相影响，但OSGI容器自身就是一个守护进程，他的使用、管理和维护都会有额外的代价。因此大家采用这个技术主要还是为了做应用的热加载和热更新，一般来说我们都认为OSGI技术太"重"，不适合小公司、小项目、或者是使用很多小项目组成大项目的互联网公司使用。

3. java9模块化

说实话你不考虑深入研究osgi的话，也一定不会中意Jigsaw，这里就不展开讲。

4. 通过Spring IOC子容器隔离

主要是通过Spring IOC子容器来实现各个业务依赖的隔离，它的确比OSGI要轻，虽然笔者之前在项目中做个一些尝试，需要你对spring 源码上有比较深入的研究才行。该方案业界也要尝试，比如Ribbon的SpringClientFactory。

这里可以讲下，还可以从物理上进行隔离，可以通过maven将依赖都打进一个jar中，放入到一个plugin目录中，通过SPI将不同的module（jar）加载的具体的子容器中。

5. 通过classloader：sofa-ark

不得不讲，大厂一般造车能力不是一般的强，很多人用个阿里的中间件都可能会了解一个组件（Pandora：潘多拉），它其实非常有创意的，考虑的不开源你可能接触不到。当然了，我这里介绍另一款类似的sofa-ark，它没有osgi那么重，既有方案4中物理上的影子，设计上对开发者友好。

看到了吧，微服务可能是你最终之路，但模块化一定是你绕不开的坎。

引用资料

• The Executable Jar Format