共计 4220 个字符，预计需要花费 11 分钟才能阅读完成。
前言
SOFABoot 是蚂蚁团体开源的基于 Spring Boot 的研发框架，提供了诸如 Readiness Check、类隔离和日志空间隔离等能力，用于疾速、敏捷地开发 Spring 应用程序，特地适宜构建微服务零碎。
Spring Boot 基于 Spring 的按条件配置（Conditional Configuration），联合 starter 依赖机制提供了快捷、不便开发 Spring 我的项目的体验，取得了极大的胜利。
SOFABoot 在这两个能力上基于 Spring Boot 扩大出适应于金融级利用开发框架。作为脱胎于蚂蚁团体外部对于 Spring Boot 的实际，SOFABoot 补充了 Spring Boot 在大规模金融级生产场景下一些有余的中央，例如 Readiness 查看、类隔离和日志空间隔离等等能力。在加强了 Spring Boot 的同时，SOFABoot 还提供了让用户能够在 Spring Boot 中方便使用 SOFAStack 中间件的能力。
SOFABoot：https://github.com/sofastack/sofa-boot
性能点概览
SOFABoot 齐全兼容 Spring Boot，Spring Boot 技术栈能够疾速切换到 SOFABoot 技术栈：批改我的项目 pom 依赖的 <parent/> 节点。
例如将：
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>${spring.boot.version}</version>
<relativePath />
</parent>替换为：
<parent>
<groupId>com.alipay.sofa</groupId>
<artifactId>sofaboot-dependencies</artifactId>
<version>${sofa.boot.version}</version>
<relativePath />
</parent>以后 SOFABoot 的最新版本为 v3.11.1。
利用 Readiness 查看
一个利用启动之后，是否“筹备”好能解决内部申请呢？
作为利用流量入口的组件是否能够接管内部连贯？
这就很有必要引入利用 Readiness 的查看，SOFABoot 提供除 Spring Boot 健康检查之外的利用的 Readiness 查看能力，保障利用组件的失常启动、平安上线。
SOFABoot 通过 HealthChecker 查看各组件的 ready 状况。
在 Spring 上下文刷新实现之后（所有的 Spring Bean 曾经实例化实现），SOFABoot 会获取 IoC 容器中所有的 HealthChecker 实现类，查看其返回的组件健康状况。
在利用开启了模块化隔离之后，模块 HealthChecker 还会查看各模块的健康状况。Spring 原生的 HealthIndicator 作为 Readiness 的一部分也会纳入 Readiness 的后果中，若 HealthIndicator 呈现了失败的状况，那么利用的 Readiness 也是不通过。
Readiness 查看蕴含组件的后置查看，流量入口组件（例如：RPC、REST）须要保障后置查看通过之后，能承受内部流量的申请，利用才是真正 ready 了。
利用 Readiness 与 Liveliness 的不同是：
- Readiness 示意的是利用启动实现之后是否“筹备”好的状态，启动实现之后是不变的
- 两次部署间的 Readiness 的所有申请后果是统一的
利用模块化
利用模块化的计划多种多样。传统计划是以利用性能为边界做模块划分；研发期间，不同职责的类放在不同的模块下，但在运行期间都在同一个 classpath 下，没有任何隔离。
而与传统的模块划分计划不同，人们发现能够利用 Java 的 ClassLoader 机制，将模块与模块间的类齐全隔离。
当某个模块须要与另一个模块通信时，能够通过类的导入和导出来实现。OSGi 和 SOFAArk 都是基于 ClassLoader 隔离的模块化实际计划。
传统的模块化计划没有任何的隔离伎俩，模块间的边界得不到保障，容易呈现模块间的紧耦合。而基于 ClassLoader 的模块化计划则过于彻底，研发人员必须非常分明类的导入与导出、Java 的类加载体系，模块划分的累赘转嫁到了一般研发人员身上。
SOFABoot 综合以上两种计划的利弊，引入了介于两者之间的模块化计划：
每个模块有独立的 Spring 上下文，通过上下文的隔离，让不同模块之间的 Bean 的援用无奈间接进行，达到模块在运行时的隔离。
这样既保证了不引入过多的复杂性，也防止了没有任何隔离措施的模块边界保障。
如下图所示：
所有的 SOFABoot 模块都会有一个雷同的 Spring Context 的 Parent，称之为 Root Application Context。
对于所有模块都须要引入的 Bean，能够抉择将其搁置于 Root Application Context 中，在所有的模块间共享。此外，SOFABoot 框架提供两种 Spring 上下文隔离计划后的模块间通信能力：
- JVM 服务的公布和援用：同一个利用内不同模块间的通信
// 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;
}- RPC 服务的公布和援用：不同利用间的通信
// 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;
}除了通过注解的形式，SOFABoot 还反对 XML 文件和编程 API 的配置形式。
除了模块间通信能力，SOFABoot 还提供：
- Module-Profile：模块级 Profile 能力，指定模块是否启动
- 扩大点：利用 Nuxeo Runtime 为 Bean 提供扩大点入口
- Require-Module：申明模块间依赖关系
利用并行化启动
模块并行化启动
SOFABoot 模块之间的依赖关系能够通过 Require-Module 指定，SOFABoot 会计算模块间的依赖造成一个有向无环图（DAG）。
SOFABoot 依照拓扑关系程序启动依赖模块，并行启动自在模块。
例如有如下的模块间依赖：
从图中可知，模块 A 必须在模块 B 和 C 之前启动，模块 D 必须在模块 E 之前启动，模块 A 和 D 能够并行启动（开始终点的自在模块）。绝对于所有模块共享一个 Spring 上下文的利用，SOFABoot 利用的并行启动能显著放慢利用启动速度。
Spring Bean 异步初始化
理论的 Spring/Spring Boot 开发中，Spring Bean 经常须要在初始化过程中执行筹备操作，如拉取近程配置、初始化数据源等等。
并且，这些筹备操作在 Bean 初始化过程中占据了大量的工夫，显著拖慢速度 Spring 上下文刷新速度。然而，Bean 初始化的筹备操作与 Bean 的后置解决往往没有强制的前后程序，是可能并行的。
SOFABoot 捕捉到了这个特点，提供了可配置选项，将 Bean 的 init-method 办法的执行异步化，从而放慢 Spring 上下文刷新过程。
如图所示，Spring 在异步执行自定义 init-method 办法之后，马上进行 BeanPostProcessor 的后置解决，相当于“跳过”了最耗时的 init-method 环节。
Spring Bean 异步初始化配置办法：
<!-- 通过将 async-init 设为 true，开启对应 bean 的异步化初始化 -->
<bean id="testBean" class="com.alipay.sofa.beans.TimeWasteBean" init-method="init" async-init="true"/>中间件集成治理
SOFABoot 通过 starter 机制治理了中间件依赖。
一个中间件的应用不必再引入一长串 JAR 包依赖，而只须要一个 starter 依赖，将中间件当作可独立插拔的“插件”；starter 依赖负责传递中间件须要的 JAR 包依赖。
中间件 starter 版本与 SOFABoot 版本关联，并且保障这些中间件 starter 版本的传递依赖通过严格测试是相互兼容的。不过 SOFABoot 的依赖治理仍然是弱治理，如果用户想要指定某个 JAR 包的版本，那么也能够笼罩 starter 中配置的版本。
SOFABoot 反对 Maven 和 Gradle 的依赖配置形式。
日志隔离
SOFABoot 通过 sofa-common-tools 集成了日志空间的隔离能力。
框架主动发现利用中的日志实现，防止中间件和利用日志实现的绑定。
二方包或者引入的中间件面向日志编程接口 SLF4J 去编程，具体的日志实现交给 SOFABoot 利用开发者去抉择；同时二方包或者中间件针对每一个日志实现提供配置以输入日志到绝对固定目录下的文件。
利用抉择的日志实现，框架都可能主动感知并抉择相应的配置文件日志输入。
利用类隔离
SOFABoot 通过 SOFAArk 提供类隔离能力和利用合并部署能力。
SOFAArk 应用隔离的类加载模型，运行时底层插件、业务利用之间均互相隔离，繁多插件和利用由不同的 ClassLoader 加载，能够无效防止相互之间的包抵触，晋升插件和模块性能复用能力。
反对多利用的合并部署，开发阶段将多个利用打包成可执行 Fat Jar，运行时应用 API 或配置核心动静地装置卸载利用。
