蚂蚁金服 SOFAArk 0.6.0 新特性介绍 | 模块化开发容器

  • 时间:
  • 浏览:1

无论是静态抑或动态合并部署也有位于宿主应用 (master biz) 的概念,肯能 Ark 包只打包了4个多 Biz,则该 Biz 默认成为宿主应用;肯能 Ark 包打包了多个 Biz 包,能也能配置指定宿主应用。宿主 Biz 和或多或少 Biz 唯一不同在于,宿主 Biz 不允许被卸载。

SOFAArk 在蚂蚁内内外部也被用来正确处理动态升级的场景问题图片。有已经 ,肯能业务迭代较快,应用依赖的某二方包能也能频繁的变更,这将原因分析分析应用每次都肯能升级二方包版本做变更发布,影响开发速度;而作为二方包的开发者,常常肯能推动依赖方应用升级阻力较大,原因分析分析新形状无法按时上线,影响业务发展。



错综复杂项目通常能也能跨团队合作者开发,每个人 负责不同的组件。协调跨团队合作者开发会遇到不少问题图片:比如每个人 技术栈不统一原因分析分析的依赖冲突、往同4个多 Git 仓库提交代码常常原因分析分析 merge 冲突、组件功能相互依赖影响测试进度。已经 ,肯可如此 让每个团队将负责的功能组件当成4个多 个单独的应用开发和测试,运行时合并部署,如此 将能够提升开发速度及应用可扩展性。

日常使用 Java 开发,常常会遇到包依赖冲突的问题图片,尤其当应用变得臃肿庞大,包冲突的问题图片也会变得更加棘手,原因分析分析各种各样的报错,同类于 LinkageError, NoSuchMethodError 等。实际开发中,可如此 采用多种法律措施来正确处理包冲突问题图片,比较常见的是同类于 Spring Boot 的做法:统一管理应用所有依赖包的版本,保证哪些地方地方三方包不位于依赖冲突。你是什么 做法如此 有效正确处理包冲突问题图片,如此 根本上正确处理包冲突的问题图片。肯能某个应用的确能也能在运行时使用4个多 相互冲突的包,同类于 protobuf2 和 protobuf3,如此 同类于 Spring Boot 的做法依然正确处理不了问题图片。

启动 Ark 包,Ark Container 优先启动,容器运行时自动解析 Ark 包中中有 Plugin 和 Biz,并读取让让我们让让我们 的配置信息,构建类和资源的加载索引表;已经 使用独立的 ClassLoader 加载并按优先级配置依次启动。能也能指出的是,Plugin 优先 Biz 被加载启动。

动态合并部署区别于静态合并部署最大的或多或少是,在运行时可如此 通过 API 肯能配置中心(Zookeeper)来控制 Biz 的部署和卸载。动态合并部署的设计理念图如下:

其次,Ark Plugin 也被用于扩展 SOFAArk 容器能力,同类于 runtime-sofa-boot-plugin 用于提供 SOFA JVM 服务通信能力; web-ark-plugin 用于提供多 web 应用合并部署能力等。

场景一:合并部署

SOFAArk 提出了并也有特殊的包形状 -- Ark Biz,用户可如此 使用 Maven 插件将应用打包成 Biz,允或多或少 Biz 在 SOFAArk 容器之上合并部署,并通过统一的编程界面交互,如下:

Biz 对应用类型如此 限制,可如此 是 Spring Boot/SOFABoot/Java 普通应用类型,Biz 之间采用统一的编程界面-SOFA JVM 服务进行交互。发布和引用服务也非常简单,使用 API 肯能 Spring 注解/XML 法律措施:

文中涉及的相关链接

SOFAStack

Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构,中有 了构建金融级云原生架构所需的各个组件,是在金融场景里锤炼出来的最佳实践。

蚂蚁金服在 SOFAStack 体系内研发了一款基于 Java 实现的轻量级类隔离容器,主要提供类隔离和应用(模块)合并部署能力--SOFAArk。> 本篇文章为 SOFAArk 0.6.0 的新形状介绍。

GitHub 地址:

https://github.com/alipay/sofa-ark

为了彻底正确处理包冲突的问题图片,能也能借助类隔离机制,使用不同的 ClassLoader 加载不同版本的三方依赖,进而隔离包冲突问题图片。 OSGi 作为业内最出名的类隔离框架,自然是可如此 被用于正确处理上述包冲突问题图片,已经 OSGi 框架门槛较高,功能错综复杂。为了正确处理包冲突问题图片,引入 OSGi 框架,有牛刀杀鸡之嫌,反而使工程变得更加错综复杂,不能够开发。

SOFAArk 采用轻量级的类隔离方案来正确处理日常4个多劲遇到的包冲突问题图片,在蚂蚁金服内内外部服务于整个 SOFABoot 技术体系,弥补 Spring Boot 如此 的类隔离能力。SOFAArk 提出了并也有特殊的包形状 -- Ark Plugin,在遇到包冲突时,用户可如此 使用 Maven 插件将若干冲突包打包成 Plugin,运行时由独立的 PluginClassLoader 加载,从而正确处理包冲突。

不仅仅是在跳出依赖包冲突时,可如此 通过打包 Ark Plugin 正确处理,对于错综复杂的底层组件,同类于 RPC 组件,为了正确处理它和依赖方应用位于包冲突,常会将 RPC 或或多或少后边件组件单独打成 Plugin 输出。

基于以可如此 力,SOFAArk 可如此 帮助正确处理多应用(模块)合并部署、动态升级、依赖包冲突等场景问题图片。

此时,即可使用 SOFAArk 正确处理该依赖冲突问题图片:只能也能把 A 和版本为 0.1 的 C 包一齐打包成4个多 Ark 插件,已经 让应用工程引入该插件依赖即可。

可如此 很直观的就看 Ark Container、Ark Plugin 和 Ark Biz 在 Ark 包的组织形式中。针对你是什么 个 概念让让我们让让我们 儿简单做下名词解释:

为了加快创新业务的迭代速度,会将能也能频繁变更的二方包打包成 Biz 包,供或多或少应用依赖。作为依赖方,不必直接在 Pom 文件(假设是使用 Maven 构建)定义 Biz 包版本,要是通过配置中心(同类于 Zookeeper)分类整理配置。如此 ,当应用启动时,会拉取 Biz 版本配置信息,进而拉取正确版本的 Biz 包并启动。如此 ,当能也能依赖方升级 Biz 版本时,只能也能在配置中心重新推送配置即可。

静态合并部署

假设如下场景,肯能工程能也能引入4个多 三方包:A 和 B,已经 A 能也能依赖版本号为 0.1 的 C 包,而恰好 B 能也能依赖版本号为 0.2 的 C 包,且 C 包的你是什么 个 版本无法兼容:

在开发阶段,应用可如此 将或多或少应用打成的 Biz 包通过 Maven 依赖的法律措施引入,而当自身被打成 Ark 包时,会将引入的或多或少 Biz 包一齐打入。通过 java -jar 启动 Ark 包时,则会根据优先级依次启动各 Biz,单个 Biz 使用独立的 BizClassLoader 加载,如此 考虑依赖包冲突问题图片,Biz 之间则通过 SOFA JVM 服务交互。

合并部署的形式,分为并也有 -- 静态合并部署和动态合并部署。

SOFAArk 内内外部的类加载模型相对比较简单,Plugin 之间是双向类索引关系,即可如此 相互委托对方加载所需的类和资源;Plugin 和 Biz 是单向类索引关系,即只允许 Biz 索引 Plugin 加载的类和资源,反之则不允许。

原文发布时间为:2019-03-20

本文作者:蚂蚁金服善逝

本文来自云栖社区合作者伙伴“ 金融级分布式架构”,了解相关信息可如此 关注“ 金融级分布式架构”。

SOFAArk 定义了一套相对简单的类加载模型,并结合特殊的打包格式、统一的编程界面、易扩展的插件机制,从而提供了一套较为规范化的插件化、模块化的开发方案。更多内容可如此 参考官方文档。

在介绍你是什么 个 概念已经 ,先介绍 Executable Ark Jar 包概念:Ark 包是 SOFAArk 定义的特殊格式的可执行 Jar 包。SOFAArk 提供的 Maven 插件 sofa-ark-maven-plugin 可如此 将单个或多个 Biz打包成 Ark 包,使用 java -jar命令即可在 SOFAArk 容器之上启动所有应用。Ark 包通常中有 Ark Container、Ark Plugin 和 Ark Biz。下面是4个多 简单的 Ark 包工程目录:

在介绍完 SOFAArk 的使用场景已经 ,让让我们让让我们 儿简单介绍其类加载模型。SOFAArk 中有 4个多 概念,Ark Container, Ark Plugin 和 Ark Biz; 运行时逻辑形状图如下:

在大型软件开发过程中,通常会推荐底层功能插件化、业务功能模块化的开发模式,以其达到低耦合、高内聚、功能复用的优点。基于此,SOFAArk 提供了一套较为规范化的插件化、模块化开发方案,产品能力主要包括:

动态合并部署

一般而言,宿主应用会作为流量入口的中台系统,具体的服务实现会插进不同的动态 Biz 中,供宿主应用调用。宿主应用可如此 使用 SOFAArk 提供的客户端 API 实现动态应用的部署和卸载。除了 API, SOFAArk 提供了 Config Plugin,用于对接配置中心(目前支持 Zookeeper),运行时接受动态配置;Config Plugin 会解析分类整理的配置,控制动态应用的部署和卸载。