Scalable Open Financial Architecture Stack (SOFAStack) is a finance-level cloud native Architecture independently developed by Ant Financial, which contains various components required to build the finance-level cloud native Architecture and is the best practice developed in the Financial scene.

This is the anatomy of | SOFABoot framework first article, this author nylon, from ant gold. The anatomy of | SOFABoot framework “series produced by SOFA team and source enthusiasts, project code: SOFA: BootLab /, the article tail participation way, welcome you to join the same enthusiasm for source.

SOFABoot is ant Financial’s open source Springboot-based research and development framework, providing capabilities such as Readiness Check, class isolation, and log space isolation for rapid and agile development of Spring applications, especially suitable for building microservice systems.

SpringBoot is based on Conditional Configuration of Spring and combined with starter dependency mechanism to provide quick and convenient experience of developing Spring projects, which has achieved great success. SOFABoot also builds on these two capabilities by extending SpringBoot to a finance-level application development framework. Based on ant Financial’s internal SpringBoot practices, SOFABoot complements SpringBoot’s weaknesses in large-scale financial production scenarios, such as Readiness checks, class isolation, and log space isolation. In addition to enhancing SpringBoot, SOFABoot also provides the ability to easily use SOFAStack middleware in SpringBoot.

SOFABoot: github.com/sofastack/s…

Overview of function points

SOFABoot is fully compliant with SpringBoot, and the SpringBoot stack can be quickly switched to SOFABoot stacks by modifying the nodes on which the project POM depends, for example:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>${spring.boot.version}</version>
    <relativePath/> 
</parent>
Copy the code

Replace with:

<parent>
    <groupId>com.alipay.sofa</groupId>
    <artifactId>sofaboot-dependencies</artifactId>
    <version>${sofa.boot.version}</version>
</parent>
Copy the code

The latest version of SOFABoot is v3.2.2.

Application Readiness

Once an application is started, is it “ready” to handle external requests? Can components that serve as application traffic inlets receive external connections? This makes it necessary to introduce application Readiness. SOFABoot provides application Readiness capability in addition to SpringBoot health check to ensure the normal startup of application components and the safe online of applications.

SOFABoot checks the readiness of each component through HealthChecker. After the Spring context refresh is complete (all Spring beans have been instantiated), SOFABoot retrieves all HealthChecker implementation classes in the IoC container and checks the component health they return; The module HealthChecker also kicks in to check the health of the module after the application has enabled modular isolation. Spring’s native HealthIndicator, as part of Readiness, will also be included in the results of Readiness. If the HealthIndicator fails, application Readiness will also fail.

The Readiness check includes post-check of components. Traffic entry components (such as RPC and REST) can accept external traffic requests after the post-check passes. Applications are ready.

Application Readiness differs from Liveliness in that Readiness refers to whether an application is “ready” after it is started and remains unchanged after it is started. The results of all requests for Readiness between deployments are consistent.

Application modularization

There are a variety of applications for modularity. The traditional scheme is based on the application function as the boundary to do module division; During development, classes with different responsibilities are placed under different modules, but during runtime they are all under the same classpath without any isolation. Different from the traditional module partition scheme, it is found that we can use the Java ClassLoader mechanism to completely isolate modules from classes between modules. When a module needs to communicate with another module, it can do so through class imports and exports. Both OSGi and SOFAArk are modular practices based on ClassLoader isolation.

The traditional modular scheme does not have any isolation means, the boundary between modules can not be guaranteed, easy to appear tight coupling between modules; However, the modularization scheme based on ClassLoader is too thorough. Researchers must be very clear about the import and export of classes and the loading system of Java classes, and the burden of module division is transferred to ordinary researchers.

SOFABoot combines the advantages and disadvantages of these two solutions and introduces a modular solution in between: each module has an independent Spring context, which is isolated at run time so that Bean references between different modules cannot be directly referenced. This ensures not to introduce too much complexity and avoids module boundary assurance without any isolation measures. As shown below:

All SOFABoot modules have the same Spring Context Parent, called Root Application Context. For beans that all modules need to import, you can choose to place them in the Root Application Context and share them across all modules. In addition, the SOFABoot framework provides inter-module communication capabilities behind two Spring context isolation schemes:

  • Publishing and referencing JVM services: communication between different modules within the same application
// Publish a JVM service
@Component
@SofaService
public class MyServiceImpl implements MyService {
    // implementation goes here
}
// Reference a JVM service
public class AnyClass {
    @SofaReference
    private MyService myService;
}
Copy the code
  • Publishing and referencing RPC services: Communication between different applications
// Publish a RPC service
@Component
@SofaService(interfaceType = MyService.class, bindings = { @SofaServiceBinding(bindingType = "bolt")})public class MyServiceImpl implements MyService {
    // implementation goes here
}
// Reference a RPC service
public class AnyClass {
    @SofaReference(binding = @SofaReferenceBinding(bindingType = "bolt"))
    private MyService myService;
}
Copy the code

In addition to annotations, SOFABoot also supports configuration of XML files and programming apis. In addition to module to module communication capabilities, SOFABoot provides:

  1. Module-profile: module-level Profile capability, which specifies whether a Module is enabled.
  2. Extension points: Use Nuxeo Runtime to provide extension point entry for beans;
  3. Require-module: declare dependencies between modules;

Apply parallelization startup

Module parallelization started

Dependencies between SOFABoot modules can be specified using Require-Module, and SOFABoot calculates dependencies between modules to form a directed acyclic graph (DAG, which does not start properly if there is a ring graph). SOFABoot starts dependent modules in topology order and free modules in parallel. For example, there are intermodule dependencies as follows:

As can be seen from the figure, module A must be started before module B and C, and module D must be started before module E. Modules A and D can be started in parallel (free-starting modules). Parallel startup of SOFABoot applications can significantly speed up application startup times compared to applications where all modules share a Spring context.

Spring beans are initialized asynchronously

In actual Spring/SpringBoot development, Spring beans often need to perform preparation operations during initialization, such as pulling remote configurations, initializing data sources, and so on; Also, these preparations take up a significant amount of time during Bean initialization, significantly slowing down the Spring context refresh rate. However, the preparation of Bean initialization and the post-processing of beans are often not enforced sequentially and can be done in parallel! SOFABoot has keenly captured this feature, providing configurable options to asynchronize the execution of init-method methods on beans, thus speeding up the Spring context refresh process.

As shown in the figure, Spring sends the custom init-method method asynchronously and immediately postprocesses the BeanPostProcessor, which “skips” the most time-consuming init-method part.

Spring Bean asynchronous initialization configuration method:

<! Async-init = true
<bean id="testBean" class="com.alipay.sofa.beans.TimeWasteBean" init-method="init" async-init="true"/>
Copy the code

Middleware integration Management

SOFABoot manages middleware dependencies through the starter mechanism. The use of a middleware does not need to introduce a long series of JAR dependencies, but only needs a starter dependency, which treats middleware as a plug-in that can be pluggable independently. The starter dependency is responsible for passing the JAR package dependencies required by the middleware. Middleware starter versions are associated with SOFABoot versions and ensure that the delivery dependencies of these middleware starter versions are rigorously tested for compatibility with each other. However, SOFABoot’s dependency management is still weak, and if users want to specify the version of a JAR package, they can override the version configured in starter. SOFABoot supports dependency configuration for Maven and Gradle.

logs

SOFABoot integrates the isolation of log space through SOFA-common-Tools. The framework automatically discovers application logging implementations and avoids binding between middleware and application logging implementations.

Binary package or introduced middleware logging oriented programming interface SLF4J to program, specific logging implementation to SOFABoot application developers to choose; At the same time, binary packages or middleware provide configuration for each logging implementation to output logs to a file in a relatively fixed directory. Application of the selected logging implementation, the framework can automatically sense and select the corresponding configuration file log output.

Application Class Isolation

SOFABoot provides class isolation capabilities and application consolidation deployment capabilities through SOFAArk. SOFAArk uses an isolated class loading model. Low-level plug-ins and service applications are isolated from each other during runtime. Single plug-ins and applications are loaded by different Classloaders, which effectively avoids package conflicts and improves the function reuse capability of plug-ins and modules. Supports the combined deployment of multiple applications. Multiple applications are packaged into executable Fat Jars in the development stage, and applications are dynamically installed and uninstalled using APIS or configuration centers during runtime.

Welcome to join and participate in the source parsing of SOFABoot

This paper is a preliminary introduction of SOFABoot, and I hope you have a preliminary understanding of SOFABoot. At the same time, we opened the analysis | SOFABoot framework “series, will gradually the code design and implementation of each part of the detailed introduction, estimated according to the following directory:

[Completed] Overview of SOFABoot [Received] Analysis of SOFABoot HealthCheck mechanism [Received] Analysis of SOFABoot log isolation mechanism [pending] Analysis of SOFABoot Runtime mechanism [Pending] Analysis of SOFABoot context isolation mechanism

If you are particularly interested in one of the above topics, please leave a comment and we will adjust the order of the articles according to your feedback. Thank you for your attention to SOFA and SOFABoot. We will always grow up with you.

This public number would like to claim the name of the article, we will take the initiative to contact you, confirm the qualification, you can join, It’s your show time!

In addition to source code parsing, please also submit issue and PR: SOFABoot: github.com/sofastack/s…

Financial Class Distributed Architecture (Antfin_SOFA)