SOFAArk overview

In the process of large-scale software development, the development mode of low-level function plug-in and modular business function is usually recommend in order to achieve the advantages of low coupling, high cohesion and functional reuse. Based on this, SOFAArk provides a set of standardized plug-in and modular development solutions. The main features include:

• Defining the class loading model

  run time the underlying plug-ins and business applications (modules) are isolated from each other, a single plug-in and application (module) are loaded by different ClassLoaders, which can effectively avoid mutual package conflicts and improve the reuse of plug-ins and module functions.

• Define plug-in development specifications

  Provides the Maven packaging tool to easily and quickly package multiple second-party packages into an Ark plug-in (hereinafter referred to as a plug-in).

• Define module development specifications

  Provides the Maven packaging tool to easily and quickly package applications into modules (Ark Biz, hereinafter referred to as Biz).

• Provides a standard programming interface

  Provides standard programming interfaces for Plugin and Biz, including mechanisms such as services, events, and extension points.

• Support for multi-Biz combined deployment

  In the development phase, multiple Biz packages can be used to execute Fat JAR, or Biz can be dynamically installed and uninstalled run time using API or configuration center (Zookeeper).

Based on the preceding capabilities, SOFAArk can help solve dependency package conflicts, multiple applications (modules) merge deployment, and other scenarios.

Scenarios

Package conflict

Daily use of Java development, often encounter the problem of package dependency conflicts, especially when the application becomes bloated, package conflicts will become more difficult, resulting in a variety of errors, such as LinkageError, NoSuchMethodError, etc.

In actual development, you can use a variety of methods to solve the problem of package conflict. A common approach is similar to Spring Boot, which manages all dependency package versions of an application in a unified manner to ensure that these three-party packages do not have dependency conflicts. This approach can only effectively avoid the problem of package conflicts, but cannot fundamentally solve the problem of package conflicts. If an application does need to use two conflicting packages run time, such as protobuf2 and protobuf3, then an approach like Spring Boot still won't solve the problem.

To completely solve the problem of package conflicts, you need to use the class isolation mechanism to load three-party dependencies of different versions in different ClassLoader to isolate package conflicts. As the most famous class isolation framework in the industry, OSGI can naturally be used to solve the above package conflict problem. But OSGI framework is too bloated and functionally complex. If the OSGI framework is introduced only to solve the problem of package conflict, it is suspected of killing the chicken, and on the contrary, it makes the project more complex and is not conducive to development.

SOFAArk uses a lightweight class isolation solution to resolve packet conflicts that are frequently encountered in daily life. It serves the entire SOFABoot technology system within Ant Group and makes up for the class isolation capability that Spring Boot does not have. SOFAArk proposes a special package structure (Ark Plugin). When a package conflict occurs, you can use the Maven plug-in to package several conflicting packages into a plug-in, which is run time loaded by a separate PluginClassLoader to resolve the package conflict.

Assume the following scenario. If the project needs to introduce two third-party packages A and B, but A needs to rely on package C with version number 0.1, while B happens to rely on package C with version number 0.2, and the two versions of package C are incompatible:

In this case, you can use SOFAArk to resolve the dependency conflict. You only need to package A and C packages of version 0.1 into an Ark plug-in, and then let the application project introduce the plug-in dependency.

Merged Deployment

Complex projects often require collaborative development across teams, each responsible for different components. However, coordinating cross-team cooperation and development will encounter many problems, such as dependency conflicts caused by the inconsistency of their respective technology stacks. Submitting code to the same Git warehouse often leads to merge conflicts. Therefore, if each team can treat the responsible functional components as a separate application development, run time combined deployment, through a unified programming interface interaction, will greatly improve the development efficiency and application scalability. SOFAArk proposes a special package structure- Ark Biz. Users can use the Maven plug-in to package applications into Biz, allowing multiple Biz to be combined and deployed on top of SOFAArk containers and interact with each other through a unified programming interface.

Static merge deployment

SOFAArk provides static consolidation and deployment capabilities. During the development phase, an application can import the Biz packages of other applications through Maven dependencies. When the application itself is converted into an executable Fat JAR, the Biz packages of other applications can be imported together. When the application is started, each application is started in sequence according to the priority. Each Biz is loaded using an independent BizClassLoader, which does not need to consider interdependency conflicts. Biz interacts with each other through SofaService/SofaRefernece JVM services.

Dynamic merge deployment

The biggest difference between dynamic merge deployment and static merge deployment is that the runtime controls the deployment and uninstallation of Biz through APIs or configuration center (Zookeeper). The design concept diagram of dynamic merge deployment is as follows:

Both static and dynamic merge deployment have the concept of host application (master biz). If only one Biz is packaged in the Ark package, the Biz becomes the host application by default. If the Ark package contains multiple Biz packages, you must specify the host application. The host application is not allowed to be uninstalled. Typically, the host application is used as a mid-end system for traffic ingress, and the specific service implementation is placed in different dynamic Biz for the host application to call. Host applications can use the client API provided by SOFAArk to deploy and uninstall dynamic applications.

In addition to the API,SOFAArk also provides the Config Plugin, which is used to connect to the configuration center (currently Zookeeper is supported) and run time accept dynamic configurations. The Config Plugin parses the issued configuration to control the deployment and uninstallation of dynamic applications.

Functional principle

SOFAArk packages are runnable Fat JAR packages that meet specific directory format requirements. You can use the official Maven plug-in sofa-ark-maven-plugin to package one or more applications into standard Ark packages. Run the java -jar command to start all applications on the SOFAArk container. An Ark package usually contains Ark Container, Ark Plugin, and Ark Biz. The logical structure of run time is as follows:

The three concepts are briefly explained as follows:

• Ark Container

  The SOFAArk container manages the startup run time of Ark packages. Ark Plugin and Ark Biz run on SOFAArk containers. The containers can manage plug-ins and applications. After the container is started, the Ark Plugin and Ark Biz dependencies that are contained in the classpath are parsed to load the container in isolation and start the container in sequence based on the priority.

• Ark Plugin

  The Ark plug-in is a Fat JAR plug-in that meets specific directory format requirements. The official Maven plug-in sofa-ark-plugin-maven-plugin can be used to package one or more common Java JARs into an Ark plug-in in a standard format. The Ark plug-in contains a configuration file, which usually includes the plug-in class import and export configuration, resource import and export configuration, and plug-in startup priority. run time, SOFAArk containers use independent PluginClassLoader to load plug-ins, and build class loading index table and resource loading index table based on plug-in configurations to isolate plug-ins from each other and between plug-ins and applications.

• Ark Biz

  The Ark application module is a Fat JAR that meets the requirements of a specific directory format. The official Maven plug-in sofa-ark-maven-plugin can be used to package engineering applications into an Ark Biz in a standard format. Ark Biz is the organizational unit of engineering applications and their dependency package, containing all the dependencies and configurations required for application launch. An Ark package can contain multiple Ark Biz packages, which are started in sequence by priority. Biz packages interact with each other through JVM services.

The process of running an Ark package is as follows:

1. Ark Container starts first. The container automatically parses the Ark Plugin and Ark Biz contained in the Ark package, reads their configuration information, and builds the loading index table of classes and resources.

2. Use a separate ClassLoader to load and start in sequence according to the priority configuration.