sofa-ark类隔离技术分析调研

问题痛点

最近维护了一段时间的组件包,在向同事进行推广的时候,经常会听到身边会有类似的抱怨:

  • 我靠,为啥你们的包带了一大堆乱七八糟的依赖,把我的classpath都给污染的不像个样子了。
  • 我靠,你们这个包依赖的xx包的版本跟我们自己依赖的xx包的版本不一样啊,会不会出锅?
  • 我靠,我这个代码编译的时候没问题啊,为啥一用你们的组件就报一堆的NoSuchMethodError啊。

有时候自己写代码的时候也会遇到一些容易被忽略的问题:

  • 哎,我看人家引这个包的时候都会exclude一些依赖,我要不要也学着exclude一下呢?不管了,先一起粘过来试试看。
  • 哎,怎么我的classpath里的某个包有三四个不同的版本啊,跑的时候到底用的是哪个版本啊?不管了,反正差不多,先跑跑看。
  • 哎,我怎么直接就可以用这个类了,这个类是哪个包引的?不管了,反正IDE爸爸提示我能用,先用着再说。

大多数情况下,忽略这些问题一般也不会造成太大的影响,就算出了线上bug,一般也能很快定位问题、强制指定一下依赖的版本号就好。但是不得不说,依赖调解是普通java开发人员经常会遇到的问题,无谓的浪费了我们大量的时间和精力。尤其是当项目越来越大,用到的组件越来越多时,内耗就更加明显。

业内方案

大概研究了一下,目前对于本地依赖调解也没有什么很好的银弹。绝大多数情况下,我们都是在流程、文档上来进行把控。而从技术角度说,或许有如下几种方案供我们选择。

代码内嵌

这个方法很老土,但是也好用,就是把依赖到的包以源代码的形式放在自己项目的包中,而不是以依赖的形式引入。这样的好处就是组件一定可以依赖到自己想要引入的包,不会收到业务方引入的包的影响。不过坏处就是缺少了灵活性,业务方无法修改组件包的任何依赖。

OSGI技术

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

目前的OSGI技术社区还是比较完整的,很多知名公司的大型企业软件都在用了这个技术。不过其实大家采用这个技术主要还是为了做应用的热加载和热更新,仅仅用来做依赖隔离确实有点杀鸡用牛刀了。而且对于OSGI容器自身就是一个守护进程,他的使用、管理和维护都会有额外的代价。因此一般来说我们都认为OSGI技术太”重”,不适合小公司、小项目、或者是使用很多小项目组成大项目的互联网公司使用。

不过OSGI技术给我们提供了一个不错的思路,总结下来有如下几点:

  1. 对Jar包进行更高级的抽象,并支持对类和资源访问控制。
  2. 程序运行在一个容器中,由容器来启动和管理各个业务组件。
  3. 每个业务组件有一个独立的ClassLoader,因此不同业务组件之间的依赖不会互相影响。
  4. 支持组件向容器进行服务的注册,以及服务的互相调用。

Gradle5.0特性

Gradle项目也对依赖调解这个问题做了一个不错的尝试。在Gradle5.0中引入了”java-library”插件,试图让组件开发方在编写组件代码时,主动控制好自己的依赖是否暴露给组件接入方(这个插件在老版本中也有,不过只有在5.0版本中在真正有用)。

什么意思呢?就是原本我们使用gradle来引包的时候是这么写的:

1
2
3
4
dependencies {
compile 'commons-httpclient:commons-httpclient:3.1'
compile 'org.apache.commons:commons-lang3:3.5'
}

这么做的话,当组件接入方接入这个组件的时候,就会默认通过传递依赖也依赖了这两个包,这两个包就会出现在组件接入方开发人员的IDE的classpath里。

但是,如果组件开发方只希望将httpclient包传递依赖给接入方而不愿意将commons-lang3包暴露给接入方(毕竟commons-lang3在3.5版本的api变动还是有很多坑的),这时候就可以用Gradle5.0中”java-library”插件的新特性了,我们可以将dependencies重写为:

1
2
3
4
dependencies {
api 'commons-httpclient:commons-httpclient:3.1'
implementation 'org.apache.commons:commons-lang3:3.5'
}

使用”java-library”插件之后,”compile”可以被”implementation”和”api”替代。对于组件本身来说,通过”api”或”implementation”引入的包都会被添加到classpath中。而”api”和”implementation”的唯一区别就是,在组件接入方的classpath中(实际上是compileClasspath),将只会出现通过”api”引入的包,而不会出现通过”implementation”引入的包。也就是说,当业务方接入了拥有上面这种依赖的组件时,他只会引入httpclient包,而不会引入commons-lang3包。

咦?那么问题来了,少引入了一个包岂不是肯定会在运行时报错么?他gradle又是通过什么方式来传递依赖控制的信息呢?毕竟打成jar包后包里可是没有任何依赖信息的。

其实”java-library”做的事情很简单,就是在将jar包上传maven仓库时修改了pom.xml文件中各个依赖包的scope。对于通过”api”引入的依赖来说,scope就是compile;而对于通过”implementation”引入的依赖来说,他的scope就变成了runtime。

比如在上面的例子中,打包上传后的pom.xml中的依赖就大概是这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<dependencies>
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.5</version>
<scope>runtime</scope>
</dependency>
</dependencies>

因此业务方在接入这个组件时,他的compileclasspath当然不会引入runtime的依赖了。但是要注意,在运行时,依旧还是会出现依赖冲突。。。

说白了,gradle5.0的这个功能对于解决依赖冲突这个问题来说,实在是有点饮鸩止渴,他实际上是将编译期的依赖冲突暂时隐藏了起来,等到运行时再暴露出来。我们的IDE中的classpath是干净了,但是该调解的冲突还是要调解,否则就会在运行时给你好看,那这又跟续一秒有啥区别。

当然,gradle的出发点是好的,至少通过api跟implementation让组件开发者明确了自己到底要暴露哪些包。况且通过这种方式来区分,要比写在注释或文档中进行区分要方便多了,而且好歹classpath干净了。

Sofa-ark项目

事实上,为了从根本上解决类冲突问题,我们还是需要OSGI那种通过ClassLoader进行类隔离的思路。但是OSGI还是太”重”了,有没有稍微”轻”一点的技术呢?还好蚂蚁金服给我们提供了他们的一个不错的实践——Sofa-ark项目。

sofa-ark项目从概念上其实并没有什么石破天惊的独创,可以说他就是用FatJar技术去实现OSGI的功能。下面我们主要就来分析一下这个sofa-ark项目,在讲sofa-ark项目之前,我们先讲一下FatJar技术。

Fat-jar技术

OSGI技术刚才大概讲过,那么FatJar技术又是什么呢?我们知道,在用打包插件对springboot项目进行打包时,打出来的那一个jar包是可以直接通过java -jar 直接运行的。可要知道,这并不是天经地义的事情,通常情况下,如果要运行一个jar包,至少得满足两个条件:

  1. 在jar包中的Manifest文件中要通过”Main-Class”属性,告诉jvm去启动哪个类的main函数。
  2. 在jvm的classpath中要有项目所有依赖的jar包。

但我们要知道,在用springboot打包插件进行打包的时候,我们并没有指定Main-Class,而且也没有将依赖下载到classpath的过程。这是因为这一切都是由打包插件帮我们做掉了。在打出来的包里,已经包含了所有配置信息,以及依赖的jar包。这个包一般被称为executable-jar或者fat-jar

springboot的一个典型的fat-jar大抵如此:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
example.jar
|
+-META-INF
| +-MANIFEST.MF
+-org
| +-springframework
| +-boot
| +-loader
| +-<spring boot loader classes>
+-BOOT-INF
+-classes
| +-mycompany
| +-project
| +-YourClasses.class
+-lib
+-dependency1.jar
+-dependency2.jar

在对项目进行打包的时候,插件会把所有依赖的包下载好,放到一个自定义的文件夹下(这里是BOOT-INF/lib)。但是仅仅放进来也是不够的,因为jvm并不知道要去这里拿这些依赖。为此,在启动真正的项目之前,我们还要想办法加载这些依赖。所以你会发现在jar包中有一块org.springframework.boot.loader包的代码,并且如果你打开MANIFEST.MF查看你会发现类似下面的配置:

1
2
3
4
5
6
Manifest-Version: 1.0
Start-Class: mycompany.project.YourClasses
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Spring-Boot-Version: 1.5.4.RELEASE
Main-Class: org.springframework.boot.loader.JarLauncher

也就是说,jar包在启动时实际上启动的是springboot自己的JarLauncher,通过这个JarLauncher去加载lib下的依赖,然后去启动Start-Class配置对应下的类(这个配置实际上是在用插件打包时扫描@SpringBootApplication注解得到的)。

以上就是Fat-Jar技术的基本原理,其实核心就在于要定义一套Jar包的文件规范,并且写一个打包插件按照这个规范打包,然后写一个Launcher进行解包、用依赖包配置ClassLoader、用反射调用实际main函数。

需要注意的是,如果仅仅是在IDE中运行代码,是完全感知不到打包逻辑的,因为IDE会自动帮你下载Jar包、指定classPath。

Sofa-ark的工作原理

讲了那么多准备知识,接下来就进入正题,讲一讲sofa-ark项目到底是怎么一回事。

在继续阅读之前,最好先去看一下sofa-ark项目的基本使用,否则可能会有阅读难度。

sofa-ark项目自称是“一款基于Java实现的轻量级类隔离加载容器”。在这个项目中,会打三种类型的包:

  • Ark包
  • Ark Biz包
  • Ark Plugin包

Ark Plugin

Ark Plugin包我们可以理解为一个组件,与普通组件包不同的是,Ark Plugin包原则上是不包含任何类文件的(除非是shade的场景,这在0.4.0以后的版本才出现),他只是一些依赖的集合,并且通过MANIFEST文件对这些依赖集合中的类进行访问控制。事实上,一个Ark Plugin项目在代码层面其实完全可以当成一个普通的项目(在不注册服务的情况下)。Ark Plugin项目最大的特点就在于他的打包。

包结构

一个典型的Ark Plugin包解压后大致如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
.

├── com
│ └── alipay
│ └── sofa
│ └── ark
│ └── plugin
│ └── mark

├── META-INF
│ └── MANIFEST.MF

├── conf
│ └── export.index
└── lib
├── commons-lang3-3.3.1.jar
├── sample-plugin-1.0.0.jar
└── sample-plugin-common-1.0.0.jar

可以看到这个包的结构很简单,主要是以下几个部分:

  1. com/alipay/ark/plugin/mark文件来表示这是一个Ark Plugin包。
  2. MANIFEST.MF文件,用来保存需要export或者import的包或者类,以及用于服务注册的Activator类。
  3. lib/文件夹,用来保存项目依赖到的jar包,以及项目本身的jar包。
  4. conf/export.index文件,通过解析MANIFEST文件,并扫描lib/文件夹,用于存储实际导出的类。

MANIFEST文件

MANIFEST.MF文件样例如下:

1
2
3
4
5
6
7
8
9
10
11
Manifest-Version: 1.0
groupId: com.alipay.sofa
artifactId: sample-plugin
version: 1.0.0
priority: 2000
pluginName: sample-demo-plugin
activator: com.alipay.sofa.ark.service.impl.SampleActivator
import-packages: javax.servlet,org.springframework
import-classes: com.alipay.sofa.rpc.config.ProviderConfig
export-packages: com.alipay.sofa.ark.service
export-classes: com.alipay.sofa.ark.common.CommonUtils,com.alipay.sofa.mock

MANIFEST文件中的配置基本都是打包插件直接控制的,默认的sofa-ark-plugin-maven-plugin(注意中间有一个plugin)的配置如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
<plugins>
<plugin>
<groupId>com.alipay.sofa</groupId>
<artifactId>sofa-ark-plugin-maven-plugin</artifactId>
<version>0.2.0</version>
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>ark-plugin</goal>
</goals>

<configuration>

<!-- 指定打包的 ${pluginName}.ark.plugin 存放目录; 默认放在 ${project.build.directory} -->
<outputDirectory>./</outputDirectory>

<!-- 是否把 ark plugin 安装、发布到仓库,默认为true -->
<attach>true</attach>

<!-- ark plugin 最多仅能指定一个 com.alipay.sofa.ark.spi.service.PluginActivator 接口实现类 -->
<activator>com.alipay.sofa.ark.service.impl.SampleActivator</activator>

<!-- 配置优先级,数字越小,优先级越高,优先启动,优先导出类,默认1000 -->
<priority>2000</priority>

<!-- 配置插件的名字,务必配置对,运行时,是插件的唯一标识 ID。比如 sofa-rpc 插件,可以配置为 sofa-rpc; 默认为 ${artifactId} -->
<pluginName>${ark.plugin.name}</pluginName>

<!-- 配置导入类、资源 -->
<imported>
<!-- 配置需要优先从其他 ark plugin 加载的 package -->
<packages>
<package>javax.servlet</package>
<package>org.springframework.*</package>
</packages>

<!-- 配置需要优先从其他 ark plugin 加载的 class -->
<classes>
<class>com.alipay.sofa.rpc.config.ProviderConfig</class>
</classes>

<!-- 配置需要优先从其他 ark plugin 加载的资源 -->
<resources>
<resource>META-INF/spring/bean.xml</resource>>
</resources>
</imported>

<!-- 配置导出类、资源 -->
<exported>
<!-- 配置包级别导出的类 -->
<packages>
<package>com.alipay.sofa.ark.service</package>
</packages>

<!-- 配置类级别导出类 -->
<classes>
<class>com.alipay.sofa.ark.common.CommonUtils</class>
<class>com.alipay.sofa.mock</class>
</classes>

<!-- 配置 ark plugin 对外导出的资源 -->
<resources>
<resource>META-INF/spring/bean.xml</resource>>
</resources>
</exported>

<!-- 打包插件时,排除指定的包依赖;格式为: ${groupId:artifactId} 或者 ${groupId:artifactId:classifier} -->
<excludes>
<exclude>org.apache.commons:commons-lang3</exclude>
</excludes>

<!-- 打包插件时,排除和指定 groupId 相同的包依赖 -->
<excludeGroupIds>
<excludeGroupId>org.springframework</excludeGroupId>
</excludeGroupIds>

<!-- 打包插件时,排除和指定 artifactId 相同的包依赖 -->
<excludeArtifactIds>
<excludeArtifactId>sofa-ark-spi</excludeArtifactId>
</excludeArtifactIds>

</configuration>
</execution>

</executions>
</plugin>
</plugins>

lib文件夹

lib/目录下存放的jar包,不仅包含了项目依赖的包,而且包含了项目自身的jar包。也就是说,Ark Plugin的包和原生jar包的关系并不是”代替”或是”扩展”,而是”包含”。

当然,由于plugin包和原生jar包是共用的同一个maven坐标,因此,我们就要用maven的”classifier”属性来区别。默认原生jar包的”classifier”就是空,而默认plugin包的”classifier”就是”ark-plugin”(由于版本不一致问题,最好还是在打包插件中显式指定一下classifier)。

当我们将打出来的包上传到Nexus或者其他maven包管理中心时,事实上我们会上传一个pom文件、两个jar包、以及一些自动生成的校验文件:

1
2
3
4
5
6
7
8
9
├── plugin-test-1.0-20181203.131726-1-ark-plugin.jar
├── plugin-test-1.0-20181203.131726-1-ark-plugin.jar.md5
├── plugin-test-1.0-20181203.131726-1-ark-plugin.jar.sha1
├── plugin-test-1.0-20181203.131726-1.jar
├── plugin-test-1.0-20181203.131726-1.jar.md5
├── plugin-test-1.0-20181203.131726-1.jar.sha1
├── plugin-test-1.0-20181203.131726-1.pom
├── plugin-test-1.0-20181203.131726-1.pom.md5
└── plugin-test-1.0-20181203.131726-1.pom.sha1

但是你会发现,Ark Plugin包和原生jar包事实上还是共用了同一个pom文件!这就意味着,当业务项目依赖了Ark Plugin包时,我们仍然会默认传递依赖进这个项目的间接依赖。这样的结果就是,即使Ark Plugin项目已经将自己的依赖添加到了jar包的lib目录下,但是这些依赖依然会出现在业务项目的classpath中。但是我们又不能将这些依赖全部排除掉,毕竟这里面还有业务方真正用到的那些类。

这显然不是我们期望看到的局面,虽然在运行时类是隔离的,但是在编译期,那些间接依赖还是会充斥业务开发人员的IDE中。

为了解决这个问题,在0.4.0版本后,在打包Ark Plugin时,增加了一个shade属性,用于指定需要shade进来的jar包的maven坐标。

所谓shade,就是指将某个jar包中所有的内容,复制到当前的jar包中。这就相当于我们在Ark plugin包中添加进了被shade进来的jar包的所有内容。这样做的好处就是,即使业务在使用时exclude了Ark Plugin包的所有依赖,业务在编译期仍然能正常使用那些shade进来的类。当然,这样做的前提是,我们需要在Ark Plugin包中导出这些类、告诉Ark Container,这些类是使用这个Ark Plugin来加载的。

因此,当我们在编写Ark Plugin时,我们应当遵循这样的规范,就是将那些需要暴露给业务方的接口作为一个模块,shade进Ark Plugin中,然后将这个模块导出,而将那些内部逻辑需要用到的一切都隐藏起来。当业务方调用这个Ark Plugin时,可以放心的将他所有的依赖排除掉。这样就既做到了编译期不引入间接依赖,又做到了运行期的依赖隔离。

export.index文件

conf/export.index文件是根据MANIFEST文件中配置的export的信息扫描lib文件夹中的jar包得到的。一个典型的样例如下:

1
2
3
com.example.test.sofa.TestLib1
com.example.test.sofa.TestLib2
com.example.test.sofa.TestLib3

在Ark Plugin包中,最重要的其实就是这个conf/export.index文件,就是他告诉容器“到底什么类需要通过这个Ark Plugin进行加载”,如果有多个plugin 声明了相同的类,那么则会根据priority进行选择,判断一个类到底是用哪一个插件的ClassLoader来加载。

Ark Biz

Ark Biz包实际上就是一个业务的包,是在多个ark plugin的基础上真正执行业务逻辑的基本单位。在用sofa-ark-maven-plugin打包时,会同时生成两个包,一个是Ark包,一个就是Ark Biz包。Ark Biz包的基本结构如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
.
├── META-INF
│ └── MANIFEST.MF
├── com
│ └── alipay
│ └── sofa
│ └── ark
│ └── biz
│ └── mark
├── lib
│ ├── spring-beans-4.3.4.RELEASE.jar
│ ├── spring-boot-1.4.2.RELEASE.jar
│ ├── spring-boot-autoconfigure-1.4.2.RELEASE.jar
│ ├── ...
│ └── velocity-1.7.jar
└── com
└── example
└── test
└── TestMain.class

首先肯定会有个com/alipay/sofa/ark/biz/mark文件,告诉容器这是一个biz包。同时,我们也要注意到,biz包是不会将ark plugin依赖添加到自己的lib文件夹下的。

然后我们来看下Manifest文件:

1
2
3
4
5
6
7
8
Manifest-Version: 1.0
deny-import-classes:
Ark-Biz-Name: sofa-test
deny-import-resources:
deny-import-packages:
Ark-Biz-Version: 1.1-SNAPSHOT
priority: 100
Main-Class: com.example.test.TestMain

虽然在他的MANIFEST文件中有”Main-Class”属性,指定了要执行的类,这个包只能算是半个可执行文件。因为他缺少了实际运行时的容器,所以如果要强行跑的话肯定是会报错。

慢着,我们在打包时都没有指定Main-Class,如果是非SpringBoot项目,甚至都没有加@SpringBootApplication注解,那么打包插件是怎么知道我要运行的是哪一个类呢?其实是打包插件做了一个很”呆”的处理:

com.alipay.sofa.ark.tools.MainClassFinder:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
private String getMainClassName() {
Set<MainClass> matchingMainClasses = new LinkedHashSet<>();
if (this.annotationName != null) {
for (MainClass mainClass : this.mainClasses) {
if (mainClass.getAnnotationNames().contains(this.annotationName)) {
matchingMainClasses.add(mainClass);
}
}
}
if (matchingMainClasses.isEmpty()) {
matchingMainClasses.addAll(this.mainClasses);
}
if (matchingMainClasses.size() > 1) {
throw new IllegalStateException(
"Unable to find a single main class from the following candidates "
+ matchingMainClasses);
}
return matchingMainClasses.isEmpty() ? null : matchingMainClasses.iterator().next()
.getName();
}

事实上他会去找有@SpringBootApplication注解的类,这一点与SpringBoot的打包插件类似;如果找不到,那么就检测所有的类中有Main函数的,如果找到且只找到一个就皆大欢喜,否则就报错给你看。。。(平时喜欢在main函数里写测试用例而且还不记得删的同学要注意了哈)

回到上面的话题,既然Biz包都跑不动,我们为啥要生成他呢?事实上从这就看出sofa-ark项目的本质了。sofa-ark项目其实是一个以Ark Container为核心的容器生态。Ark Container可以被理解为OSGI中的那个守护进程,用来管理业务包和插件包,只不过Ark Container不是一个守护进程而只是一个启动类罢了。既然是容器,那么就肯定要支持多应用,Container就要和Biz解耦,从而做到一个Container可以运行多个Biz和多个Plugin。

对于单个应用的项目,我们当然可以不要Ark Biz包,而是直接用Container包装起来,做成一个可执行文件。但是如果需要多个业务同时运行,我们就可以以Biz包的形式,一个一个往容器里加了。

Ark包

包结构

有了上面的基础,Ark包就很好理解了,它实际上就是一个Ark Container实例,里面存放了需要加载的Biz和Plugin。包结构大致如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
.
├── META-INF
│ └── MANIFEST.MF
├── SOFA-ARK
│ ├── biz
│ │ └── sofa-boot-demo-web-1.0-SNAPSHOT-sofa-ark-biz.jar
│ ├── container
│ │ ├── META-INF
│ │ │ └── MANIFEST.MF
│ │ ├── com
│ │ │ └── alipay
│ │ │ └── sofa
│ │ │ └── ark
│ │ └── lib
│ │ ├── aopalliance-1.0.jar
│ │ ├── guava-16.0.1.jar
│ │ ├── guice-4.0.jar
│ │ ├── guice-multibindings-4.0.jar
│ │ ├── javax.inject-1.jar
│ │ ├── log4j-1.2.17.jar
│ │ ├── slf4j-api-1.7.21.jar
│ │ ├── slf4j-log4j12-1.7.21.jar
│ │ ├── sofa-ark-archive-0.1.0.jar
│ │ ├── sofa-ark-common-0.1.0.jar
│ │ ├── sofa-ark-container-0.1.0.jar
│ │ ├── sofa-ark-exception-0.1.0.jar
│ │ ├── sofa-ark-spi-0.1.0.jar
│ │ └── sofa-common-tools-1.0.11.jar
│ └── plugin
│ └── sofa-ark-rpc-plugin-2.2.5-ark-plugin.jar
└── com
└── alipay
└── sofa
└── ark
├── bootstrap
│ ├── ArkLauncher.class
│ ├── ClasspathLauncher$ClassPathArchive.class
│ ├── ClasspathLauncher.class
│ ├── ContainerClassLoader.class
│ ├── EntryMethod.class
│ ├── ExecutableArchiveLauncher.class
│ ├── Launcher.class
│ ├── MainMethodRunner.class
│ └── SofaArkBootstrap.class
├── loader
│ ├── DirectoryBizModuleArchive.class
│ ├── ExecutableArkBizJar$1.class
│ ├── ExecutableArkBizJar$2.class
│ ├── ExecutableArkBizJar$3.class
│ ├── ExecutableArkBizJar.class
│ ├── JarBizModuleArchive$1.class
│ ├── JarBizModuleArchive.class
│ ├── JarContainerArchive$1.class
│ ├── JarContainerArchive.class
│ ├── JarPluginArchive$1.class
│ ├── JarPluginArchive.class
│ ├── archive
│ ├── data
│ └── jar
└── spi
└── archive

这个包实际上就是shade进了Ark Container的Jar包,在SOFA-ARK/bizSOFA-ARK/plugin目录下分别保存了需要加载的业务包和插件包。

Manifest文件

他的Manifest文件大致如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Manifest-Version: 1.0
Implementation-Title: sofa-ark-all
Implementation-Version: 0.1.0
Archiver-Version: Plexus Archiver
Built-By: qilong.zql
Sofa-Ark-Version: 0.1.0
Specification-Title: sofa-ark-all
Implementation-Vendor-Id: com.alipay.sofa
Main-Class: com.alipay.sofa.ark.bootstrap.ArkLauncher
Ark-Container-Root: SOFA-ARK/container/
Created-By: Apache Maven 3.2.5
Build-Jdk: 1.8.0_101
Specification-Version: 0.1.0
ArkVersion: 0.1.0
Timestamp: 2018-03-13T18:13:06Z

在执行Ark包时,他会启动ArkLauncher,用来启动Ark Container并加载业务包和插件包(每一个业务包和插件包都有自己独立的ClassLoader)然后再去启动每一个业务包。

类加载

最后我们再来简单看下,Ark Container是如何用ClassLoader进行运行时类隔离的。

以BizClassLoader为例,BizClassLoader用来控制每一个Biz加载类的逻辑。显然默认的委托模型是不中的,BizClassLoader采用了如下逻辑:

com.alipay.sofa.ark.container.service.classloader.BizClassLoader:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
@Override
protected Class<?> loadClassInternal(String name, boolean resolve) throws ArkLoaderException {

// 1. sun reflect related class throw exception directly
if (classloaderService.isSunReflectClass(name)) {
throw new ArkLoaderException(
String
.format(
"[ArkBiz Loader] %s : can not load class: %s, this class can only be loaded by sun.reflect.DelegatingClassLoader",
bizIdentity, name));
}

// 2. findLoadedClass
Class<?> clazz = findLoadedClass(name);

// 3. JDK related class
if (clazz == null) {
clazz = resolveJDKClass(name);
}

// 4. Ark Spi class
if (clazz == null) {
clazz = resolveArkClass(name);
}

// 5. Plugin Export class
if (clazz == null) {
clazz = resolveExportClass(name);
}

// 6. Biz classpath class
if (clazz == null) {
clazz = resolveLocalClass(name);
}

// 7. Java Agent ClassLoader for agent problem
if (clazz == null) {
clazz = resolveJavaAgentClass(name);
}

if (clazz != null) {
if (resolve) {
super.resolveClass(clazz);
}
return clazz;
}

throw new ArkLoaderException(String.format("[ArkBiz Loader] %s : can not load class: %s",
bizIdentity, name));
}

可以说这段代码写的逻辑很清楚,当Biz在运行时发现一个类需要被加载时,他会按照如下步骤搜索:

  1. 如果已加载过,那就返回已加载好的那个类。
  2. 如果这个类是JDK自己的,那么就用JDKClassLoader去加载。
  3. 如果这个类是属于Ark容器的,那么就用ArkClassLoader去加载。
  4. 如果这个类是某个插件export的,那么就用ExportClassLoader去加载。
  5. 如果这个类是我业务自己的,那么就用当前的ClassLoader直接loadClass就好。
  6. 否则就去试试是不是用了某个java agent。
  7. 再找不到就报错给你看。

其他能力

上面的文章中,我们只是专注于使用sofa-ark进行类隔离。事实上他也支持类似OSGI的那种服务发布、热加载和热部署。

服务发布

利用Activator,你可以很方便的以jvm服务的形式发布plugin的服务。不过这不是我使用的重点,我也就没有过多研究。

热加载

当你启动ark包时,你会发现你的1234端口开放了一个telnet接口,当然这个端口默认是没有任何用的。不过当你引入了sofa-jarslink项目,你就真的可以像使用OSGI容器一样的利用这个端口动态管理你的Biz和Plugin了。

启动方式

非Springboot应用

在非SpringBoot中,Sofa-ark的Biz通过引入sofa-ark-support-starter,并且在主函数中显式launch来启动。

1
2
3
4
5
6
public class TestMain {
public static void main(String[] args) {
SofaArkBootstrap.launch(args);
//TODO do your business
}
}

注意到这个launch方法一定要是main函数的第一个方法。否则在他之前的代码就会被执行两次。

如果是在IDE中启动,那么这个launch方法会自己起一个Ark容器,然后再用反射重新调用自己的main函数。
如果是打包后启动,那么创建Ark容器的任务就交给了启动类了了,这个launch方法将不做任何事情。

SpringBoot应用

在SpringBoot中,Sofa-ark的Biz通过引入sofa-ark-springboot-starter来启动。这个starter注册了spring的启动事件,并且在启动事件中调用SofaArkBootstrap.launch函数。其他的过程就和非SpringBoot应用类似了。

IDE启动和打包启动的区别

为什么前面我们要区分IDE启动和非IDE启动呢?因为这两种启动方式不只是启动逻辑不同,执行逻辑也不一样。

在IDE中启动时,由于主类的静态代码块是会在容器启动之前就会加载一次的。可是在容器起来之后,由于容器会用心的ClassLoader再反射调用主类的main函数,因此他又会被加载一次,这一点需要额外注意。

但是,如果是打包后启动呢?容器的启动是在启动类中完成的、而不是主类,因此主类的静态代码块就会正常只被执行一次,这样就不会有问题了。

已知问题

关于sofa-ark项目,前前后后研究了一个礼拜的样子,也稍微有了一些使用心得,再总结一下这个项目的不足:

  1. 用fatJar技术做依赖隔离其实并不优雅。因为不同插件实在是会引入很多重复的包,会导致最终的jar包很大。虽然plugin层可以复用,但是还是会有一些重复jar包的。
  2. 目前采用的日志框架是蚂蚁内部的框架,实在是太丑陋,而且不支持关闭,用起来很难受。
  3. 没有官方gradle插件,且开发组据说一时半会也不会考虑支持。当然,写起来其实不困难,为了内部使用,我没办法就只能自己花了点时间写了一套,先自己用一段时间看看。
  4. 社区不够完善。这个项目刚开源也没多久,用的人也不是很多,所谓的社区也就只有github的issue了。而且看上去开发组也很忙,很多特性的支持都很慢。
  5. 对应用侵入性比较强,有风险。为了运行sofa-ark,项目的整体打包逻辑都要变,而且代码都是跑在Ark Container里面,对于一个社区都不完善的不是很成熟的项目来说,这么用还是有很大风险的。
  6. 对依赖进行导入导出的管理引入了一定的复杂性,还是有一定学习成本的。

最后再强调一点,sofa-ark项目并不是解决依赖冲突问题的银弹。对于一个已有的、已经使用了很多富客户端二方包的项目,迁移到sofa-ark后,你会经常发现很多”ClassCastException”。这是因为由不同Classloader创建的类是不一样的,不能将一个ClassLoader创建的实例,赋给由另一个ClassLoader声明的类。在springboot项目中,这种问题经常会发生。

因此,在已有的生态中仅仅是为了做依赖隔离而接入sofa-ark并不是一件省心的事情,各位还要慎用。

参考资料

探索 OSGi 框架的组件运行机制

gradle 5.0 The Java Library Plugin

Spring Doc:The Executable Jar Format

sofa-ark Github

sofa-stack官网文档

Java隔离容器之sofa-ark使用说明及源码解析