SOFAArk 是一款基于 Java 實現(xiàn)的動態(tài)熱部署和輕量級類隔離框架，由螞蟻集團開源貢獻，主要提供應(yīng)用模塊的動態(tài)熱部署和類隔離能力?；?Fat Jar 技術(shù)，可以將多個應(yīng)用模塊打包成一個自包含可運行的 Fat Jar，應(yīng)用既可以是簡單的單模塊 Java 應(yīng)用也可以是 SpringBoot/SOFABoot 應(yīng)用。

背景

SOFAArk 最初的場景是解決 Java 開發(fā)常常會遇到的包依賴沖突的問題，尤其當(dāng)工程應(yīng)用變得臃腫龐大，包沖突的問題也會變得更加棘手，導(dǎo)致各種各樣的報錯，例如LinkageError, NoSuchMethodError等。實際開發(fā)中，可以采用多種方法來解決包沖突問題，比較常見的是類似 SpringBoot 的做法，統(tǒng)一管理應(yīng)用所有依賴包的版本，保證這些三方包不存在依賴沖突。這種做法只能有效避免包沖突的問題，不能根本上解決包沖突的問題。如果某個應(yīng)用的確需要在運行時使用兩個相互沖突的包，例如 protobuf2 和 protobuf3，那么類似 SpringBoot 的做法依然解決不了問題。

為了徹底解決包沖突的問題，我們需要借助類隔離機制，使用不同的 ClassLoader 加載不同版本的三方依賴，進而隔離包沖突問題。OSGI 作為業(yè)內(nèi)最出名的類隔離框架，自然是可以被用于解決上述包沖突問題，但是 OSGI 框架太過臃腫，功能繁雜。為了解決包沖突問題，引入 OSGI 框架，有牛刀殺雞之嫌，反而使工程變得更加復(fù)雜，不利于開發(fā)。

SOFAArk 則采用較為輕量級的類隔離方案來解決日常經(jīng)常遇到的包沖突問題，在螞蟻金服內(nèi)部服務(wù)于整個 SOFABoot 技術(shù)體系，彌補 SpringBoot 沒有的類隔離能力。實際上，SOFAArk 是一個通用的輕量級類隔離框架，并不限于 SpringBoot 應(yīng)用，也可以和其他的 Java 開發(fā)框架集成。

基于類隔離能力 SOFAArk 還提供了動態(tài)熱部署能力。SOFAArk 不但支持將多個應(yīng)用合并打成一個可執(zhí)行的 Fat Jar 包，也支持運行時通過 API 或者 Zookeeper 動態(tài)推送配置達到動態(tài)部署應(yīng)用模塊的能力。在多團隊協(xié)作開發(fā)時，各個功能模塊由不同的團隊負(fù)責(zé)開發(fā)，通常情況下，這些功能模塊獨立開發(fā)，但是運行時部署在一起。借助 SOFAArk 提供的合并部署能力，各團隊開發(fā)時擁有相當(dāng)大自由度，只需要定義各模塊之間的交互接口即可，尤其對于中臺應(yīng)用開發(fā)，提高團隊合作效率。除了合并部署，SOFAArk 還對接了 Zookeeper 接受動態(tài)配置，控制應(yīng)用模塊的動態(tài)安裝和卸載。

原理

SOFAArk 框架包含有三個概念，Ark Container, Ark Plugin 和 Ark Biz; 運行時邏輯結(jié)構(gòu)圖如下：

在介紹這三個概念之前，為了統(tǒng)一術(shù)語，有必要先說一下所謂的 Ark 包;Ark 包是滿足特定目錄格式要求的 Executed Fat Jar，使用官方提供的 Maven 插件 sofa-ark-maven-plugin可以將工程應(yīng)用打包成一個標(biāo)準(zhǔn)格式的 Ark 包;使用命令 java -jar application.jar即可在 Ark 容器之上啟動應(yīng)用;Ark 包 通常包含 Ark Container、Ark Plugin、 Ark Biz;以下我們針對這三個概念簡單做下名詞解釋：

1、Ark Container: Ark 容器，負(fù)責(zé)整個運行時的管理;Ark Plugin 和 Ark Biz 運行在 Ark 容器之上;容器具備管理多插件、多應(yīng)用的功能;容器啟動成功后，會自動解析 classpath 包含的 Ark Plugin 和 Ark Biz 依賴，完成隔離加載并按優(yōu)先級依次啟動之;

2、Ark Plugin: Ark 插件，滿足特定目錄格式要求的 Fat Jar，使用官方提供的 Maven 插件 sofa-ark-plugin-maven-plugin 可以將一個或多個普通的 Java Jar 包打包成一個標(biāo)準(zhǔn)格式的 Ark Plugin; Ark Plugin 會包含一份配置文件，通常包括插件類導(dǎo)入導(dǎo)出配置、插件啟動優(yōu)先級等;運行時，Ark 容器會使用獨立的 PluginClassLoader 加載插件，并根據(jù)插件配置構(gòu)建類加載索引表，從而使插件與插件、插件與應(yīng)用之間相互隔離;

3、Ark Biz: Ark 業(yè)務(wù)模塊，滿足特定目錄格式要求的 Fat Jar ，使用官方提供的 Maven 插件 sofa-ark-maven-plugin 可以將工程應(yīng)用打包成一個標(biāo)準(zhǔn)格式的 Ark-Biz 包;是工程應(yīng)用模塊及其依賴包的組織單元，包含應(yīng)用啟動所需的所有依賴和配置;

在運行時，Ark Container 優(yōu)先啟動，自動解析 classpath 包含的 Ark Plugin 和 Ark Biz，并讀取他們的配置，構(gòu)建類加載索引關(guān)系;然后使用獨立的 ClassLoader 加載他們并按優(yōu)先級配置依次啟動;需要指出的是，Ark Plugin 優(yōu)先 Ark Biz 被加載啟動;Ark Plugin 之間是雙向類索引關(guān)系，即可以相互委托對方加載所需的類;Ark Plugin 和 Ark Biz 是單向類索引關(guān)系，即只允許 Ark Biz 索引 Ark Plugin 加載的類，反之則不允許。

場景

包沖突

SOFAArk初衷是為了解決包沖突問題，那什么情況下可以使用 SOFAArk 以及如何使用呢? 假設(shè)如下場景，如果工程需要引入兩個三方包：A 和 B，但是 A 需要依賴版本號為 0.1 的 C 包，而恰好 B 需要依賴版本號為 0.2 的 C 包，且 C 包的這兩個版本無法兼容:

此時，即可使用 SOFAArk 解決該依賴沖突問題;只需要把 A 和版本為 0.1 的 C 包一起打包成一個 Ark Plugin，然后讓應(yīng)用工程引入該插件依賴即可;

合并部署

SOFAArk 基于類隔離能力，實現(xiàn)了應(yīng)用的合并部署，可以簡單分為靜態(tài)合并部署和動態(tài)合并部署，介紹如下。

靜態(tài)合并部署

在實際開發(fā)過程中，經(jīng)常會出現(xiàn)多個團隊合作開發(fā)同一款產(chǎn)品，他們各自負(fù)責(zé)不同的功能模塊，這些功能模塊通?？梢元毩㈤_發(fā)，但是運行時需要作為一個整體的應(yīng)用運行。在這種情況下，所有團隊需要協(xié)商統(tǒng)一技術(shù)棧及各自的二方包版本，這無疑增加了開發(fā)和聯(lián)調(diào)的成本。為了讓開發(fā)人員專注自身功能業(yè)務(wù)的開發(fā)，理想情況下開發(fā)人員希望能像開發(fā)獨立應(yīng)用一樣，僅定義好對外交互接口，而不用考慮和其他功能模塊出現(xiàn)的版本沖突、技術(shù)棧不統(tǒng)一等問題。正是基于這種場景，SOFAArk 提供了靜態(tài)合并部署能力，應(yīng)用可以依賴其他應(yīng)用打成的 Biz 包，而當(dāng)自身被打成 Ark 包時，可以將其他應(yīng)用 Biz 包一并打入，啟動時，則會根據(jù)優(yōu)先級依次啟動各應(yīng)用。由于每個應(yīng)用使用獨立的 BizClassLoader 加載，因此不需要考慮依賴沖突或者技術(shù)棧不統(tǒng)一問題。應(yīng)用之間則通過 SofaService/SofaReference JVM 服務(wù)進行交互。

動態(tài)合并部署

動態(tài)合并部署區(qū)別于靜態(tài)合并部署最大的一點是，在應(yīng)用運行時可以通過 API 或者配置中心(Zookeeper)來控制應(yīng)用的部署和卸載。動態(tài)合并部署的設(shè)計理念圖如下：

無論是靜態(tài)還是動態(tài)合并部署都會有宿主應(yīng)用(master app)的概念, 如果 Ark 包只打包了一個 Biz，則該 Biz 默認(rèn)成為宿主應(yīng)用。如果 Ark 包打包了多個 Biz 包，需要配置指定宿主應(yīng)用。宿主應(yīng)用不允許被卸載，一般而言，宿主應(yīng)用會作為流量入口的中臺系統(tǒng)，具體的服務(wù)實現(xiàn)會放在不同的動態(tài) Biz 中，供宿主應(yīng)用調(diào)用。宿主應(yīng)用可以使用 SOFAArk 提供的客戶端 API 實現(xiàn)動態(tài)應(yīng)用的部署和卸載。除了 API, SOFAArk 提供了 Config Plugin，用于對接配置中心(目前支持 Zookeeper)，運行時接受動態(tài)配置。Config Plugin 會解析下發(fā)的配置，控制動態(tài)模塊的部署和卸載。

隨著近幾年 Serverless 技術(shù)的興起，螞蟻集團在 Serverless 領(lǐng)域進行了持續(xù)的建設(shè)和探索，基于 SOFAArk 動態(tài)合并部署技術(shù)打造了比較成熟的 SOFAServerless 技術(shù)體系，去深入解決企業(yè)的研發(fā)和運維效率問題。其核心方式是通過快速熱部署、動態(tài)服務(wù)發(fā)布等技術(shù)，將應(yīng)用從代碼結(jié)構(gòu)和開發(fā)者陣型劃分為模塊和基座。其中基座為業(yè)務(wù)模塊提供計算環(huán)境并屏蔽基礎(chǔ)設(shè)施，讓模塊開發(fā)者不用感知機器和容量等底層設(shè)施而專注于某個功能模塊的開發(fā)迭代來幫助業(yè)務(wù)快速向前發(fā)展。

在應(yīng)用架構(gòu)領(lǐng)域，不可避免的問題是應(yīng)用隨著業(yè)務(wù)的復(fù)雜度不斷增加，研發(fā)運維的過程中的問題會不斷暴露出來。首先我們看一下普通應(yīng)用研發(fā)和運維過程中的流程是什么樣的：

如圖所示，從需求到設(shè)計、開發(fā)、線下測試，再到發(fā)布線上的研發(fā)運維不斷反饋、循環(huán)迭代的過程?？梢院喕癁殚_發(fā)同學(xué)提交代碼到代碼倉庫，在線下做并行的驗證測試，測試通過之后在線上發(fā)布，發(fā)布過程是串行的，只能夠有一個發(fā)布窗口，這樣的過程在應(yīng)用體量業(yè)務(wù)還不太復(fù)雜的情況下問題，并不是很明顯。

但當(dāng)業(yè)務(wù)復(fù)雜度不斷增加，普通應(yīng)用迭代過程在會出現(xiàn)一些新的問題，如下圖：

1、管理成本高：需求管理、代碼管理、人員管理。

2、時間成本高：線上驗證與發(fā)布互相阻塞。單次啟動慢。

3、變更風(fēng)險高：一次變更涉及所有代碼。一次變更涉及所有機器。

另外，由于這些問題是因為多個業(yè)務(wù)與研發(fā)任務(wù)耦合在某些單點上導(dǎo)致的，研發(fā)運維的成本隨著業(yè)務(wù)的復(fù)雜度呈現(xiàn)出指數(shù)增長的特點：

通過借助 SOFAArk 框架將應(yīng)用拆分成基座和模塊，同時將應(yīng)用里的接口按場景維度做分組，使得業(yè)務(wù)可以按一組接口的粒度進行極速發(fā)布運維以及資源按需隔離。

從這張圖里可以看到 Serverless 應(yīng)用拆分的形態(tài)，通過把一個普通的 Java 應(yīng)用拆出多個模塊，進一步對應(yīng)用進行了拆分：基座和模塊，對應(yīng)的研發(fā)人員也劃分為基座開發(fā)者和模塊開發(fā)者。

基座負(fù)責(zé)沉淀通用的邏輯，為模塊提供計算和環(huán)境，并為模塊開發(fā)者屏蔽基礎(chǔ)設(shè)施，讓模塊開發(fā)者不需要關(guān)心容量和資源等。各個模塊則是獨立的代碼倉庫，可以進行獨立的研發(fā)運維，這樣研發(fā)運維粒度就得到了精細(xì)化，并且由于基座為模塊屏蔽了環(huán)境與基礎(chǔ)設(shè)施，模塊開發(fā)者可以專注于業(yè)務(wù)開發(fā)從而提高了業(yè)務(wù)創(chuàng)新效率。