浅谈Java微服务与模块化

众所周知的，我们一般传统的应用都是采用三层架构来构建，而阿里的规范中，新增了一层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中物理上的影子，设计上对开发者友好。
   看到了吧，微服务可能是你最终之路，但模块化一定是你绕不开的坎。
   为了不影响大家的阅读效果，文章不再编写过长篇幅。个人整理了更多资料以PDF文件的形式分享给大家，需要查阅的程序员朋友可以来免费领取。还有我的学习笔记PDF文件也免费分享给有需要朋友！

Java高级架构学习资料分享+架构师成长之路