这样的插件化架构运行了两年的时间,后来团队发现简直痛不欲生,所以在2014年初的时候整个团队就开始重新思考手淘到
底需要什么样的架构。基于之前整个插件化的方案,在经过了深入的思考后认为:
首先,手淘需要高复用性,手淘不是一个大杂烩,需要进行统一地管控,对于所有的中间件、所有的服务都需要有一方进行统
一管控。
第二方面就是要做到低侵入性,对于开发者而言,他们不需要感知容器的需求,只需要进行编码就可以了,这就是低侵入性,
也就是开发者不需要对于系统由特别深刻的了解就可以运用大量的黑科技,比如说开发者并不需要了解安卓系统底层设计,而
只需要在安卓容器上使用Java层的API就可以完成自己想要实现的功能。
第三个方面就是高可用性,高可用性也好,性能也好,要保证使用了插件不能对于应用的性能产生太大的损耗。
最后一个方面也是业务插件方提出的请求,就是希望业务和业务之间使用插件隔离开来,独立地进行开发和调试。业务今天可
以跟着手淘的航空母舰一起跑,未来也可以自己独立地运行。
在2014年初的时候,手淘技术团队在想清楚这四条原则之后,大概花费了一个月的时间构建出了新版的Atlas框架体系。
Atlas体系
如下图所示就是现在的Atlas体系结构,在整个容器中没有进行混淆之前不会超过100个类。像图中最下面的一层,称之为
Hack层,包括OS Hack toolkit & verifier,这里其实主要是为了对系统能力做一些扩展,然后做一些安全校验。上面的一层是
Bundle Franework,就是我们的容器基础框架,这一层仿照整个OSG2层容器的概念定义了一层所有容器插件化的生命周期提
供Bundle管理、加载、生命周期、安全等一些最基本的能力。再之上的一层是运行期管理层,主要在容器的运行时,对于所
有Bundle的版本控制进行管理;以及清单,会把所有的Bundle和它们的能力列在一个清单上,在调用时方便查找,这样就可
以知道到底有多少个容器;这一层还存在对于类加载器以及资源的代理,这里就是和业界一些插件化框架机制类似的地
方,Atlas会代理系统的运行环境,让Bundle运行在自己的容器框架上。这一层最右边的则是整个运行期间的监控器,可以监
控运行的情况,也方便了工程期开发调试。最上面一层就是业务,这一层是面向开发者的,开发者只需要知道存在
AtlasBridgeApplication就可完全去使用容器的能力,除此之外还有Tools,可以用来进行校验和判断。这样带来情况是使得组
件开发与在后台的开发是一模一样的,经过一个代理的Resource和Classloader进行操作。而这些东西对于组件开发而言,完
全不需要深入了解,这部分内容会在之后的章节会继续展开进行分享。