本文是 SOFABoot（蚂蚁集团基于 Spring Boot 的研发框架） GitHub 官方 README 的完整中文翻译版，命令、版本号、端口与官方文档保持一致。
官方信息
| 项目 | 信息 |
|---|---|
| 项目名称 | SOFABoot |
| 维护方 | 蚂蚁集团（SOFAStack） |
| 仓库地址 | github.com/sofastack/sofa-boot |
| 官方文档 | sofastack.tech SOFABoot 文档 |
| 开源协议 | Apache License 2.0 |
| 编译要求 | JDK 17、Apache Maven 3.5.4+ |
一句话总结：SOFABoot = Spring Boot + 生产级就绪检查 + 类隔离 + 日志隔离 + Spring 上下文模块化 + 一套即插即用的 SOFA 中间件 starter。
项目背景
SOFABoot 是蚂蚁集团开源的、基于 Spring Boot 的研发框架。它在 Spring Boot 的基础上开箱即提供了 Readiness Check（就绪检查）、Spring 上下文隔离、类隔离、日志空间隔离等增强能力；同时，SOFABoot 让来自 Spring Boot 世界的开发者能非常方便、无缝地接入 SOFAStack 中间件。
Spring Boot 本身非常优秀，可以很方便地构建出"开箱即跑"的生产级 Spring 应用，但在蚂蚁集团这样的超大规模微服务落地过程中，仍有几个绕不开的问题：
- 只有存活检查，没有就绪检查。Spring Boot 提供的健康检查只能反映应用"活着"（Liveness），无法反映"可以接客"（Readiness）。微服务应用刚启动时，若上游的 RPC、网关、定时任务流量已经打进来，而应用内部还没初始化完，就会在短时间内产生大量错误；
- 类与依赖冲突难解。Spring Boot 通过依赖管理尽量保证它管理的 JAR 之间兼容，但引入第三方包时仍会冲突。最典型的例子是序列化类库：一个组件要用 Hessian 3，另一个必须用 Hessian 4，而 Hessian 3 与 4 不兼容，序列化又牵扯微服务上下游，强行统一版本几乎不可能；
- 日志监控成本高。大规模微服务运维必须平台化，而日志是监控的核心入口。Spring Boot 没有提供统一日志方案：每个开源组件打印什么日志、落到什么路径，全由应用自己决定，结果每个应用的日志配置五花八门，监控系统里也要逐个应用配置，关键监控的实施成本极高；
- 企业级模块化缺失。多团队协作时，每个业务团队维护自包含模块可以降低沟通成本，但 Spring Boot 默认所有 Bean 共用一个 Spring 上下文，不同团队一旦定义了相同 BeanId，运行时就会冲突报错。
为了解决上述问题，同时又因为 SOFA 中间件本身就要集成 Spring Boot，蚂蚁集团基于 Spring Boot 开发并开源了 SOFABoot。在 SOFABoot 里，SOFAStack 中间件的 SDK 都被打包成自包含的 "starter"，提供对应的能力与依赖。
理解这四个问题的实际分量很重要：就绪检查缺失意味着每次发布新实例，上游流量都可能在应用还没初始化完时打到它身上，轻则一波超时告警，重则触发连锁错误；类冲突问题在没有隔离手段时，往往要开会推动多个团队一起升级，排期动辄数周；日志配置不统一则让"上监控"这件本该标准化的事变成逐应用的体力活；而多团队共用一个 Spring 上下文，则让模块之间的边界从一开始就是模糊的。SOFABoot 把这些在蚂蚁内部打磨多年的工程实践沉淀成框架能力，开源给所有 Java 开发者使用。
核心能力
1. Readiness Check（就绪检查）
针对 Spring Boot 缺少就绪检查的问题，SOFABoot 在其现有健康检查之上补充了 Readiness Check。利用这套机制，SOFA 中间件的各个组件会在就绪检查通过之前对外"隐身"——比如 RPC 服务在 Readiness Check 通过之前不会向服务注册中心注册，上游流量自然进不来，也就避免了应用启动过程中被流量打穿。
除了中间件自己消费就绪事件，PaaS 平台也可以通过访问 http://localhost:8080/actuator/readiness 拿到就绪检查结果，用来控制网关、负载均衡等外部流量的进入时机，实现优雅上线。
2. 类隔离（基于 SOFAArk）
为解决类依赖冲突，SOFABoot 基于 SOFAArk 提供类隔离能力。相比笨重的 OSGi 类隔离方案，SOFAArk 很轻量，专注于应用与中间件模块之间的类加载隔离；在 SOFABoot 工程里引入 SOFAArk 相关依赖后，SOFA 中间件的类和应用自身的类就由不同 ClassLoader 加载，从根上防止冲突。借助 SOFAArk 的高扩展性，第三方 SDK 也可以被打成 Ark 模块，与应用类隔离开来。类隔离真正解决的是"同一个应用里两个组件硬要依赖同一个库的不同版本"的问题——这在大型公司极其常见，除了前面提到的 Hessian 版本分裂，还可能是日志框架、JSON 库、HTTP 客户端版本不一致，SOFAArk 让你不必再为了对齐版本而推动上下游改造。
3. 日志空间隔离
SOFABoot 利用 sofa-common-tools 为每个 SOFA 中间件 SDK 提供基础日志配置，应用开发者不必再反复为各个 SDK 配日志；同时每个 SDK 有独立的日志目录，与应用普通日志隔开，日志路径相对固定，非常方便统一监控。在 Spring Boot 里，日志配置的责任本来是甩给用户的：同一个 SDK 的所有使用方都得自己配一遍，但配置内容大同小异，重复劳动。SOFABoot 把这层重复配置收掉了，并且让中间件日志和业务日志在文件系统上各归各位，运维同学做日志采集和告警规则时也不用再为每个 SDK 单独找路径。
4. Spring 上下文隔离与模块化开发
Java 世界常见两种模块化方式：一是按代码组织拆成多个 JAR，但运行时所有类仍由同一个 ClassLoader 加载；二是按 ClassLoader 拆模块，每个模块有自己的类加载器和类路径。SOFABoot 提供了介于两者之间的第三种选择：基于 Spring 上下文做隔离。每个模块拥有独立的 Spring 上下文，多个上下文形成一棵简单的依赖树，Bean 的依赖注入沿着"子上下文 → 根上下文"的路径解析。这样不同模块之间的 Bean 与配置互不冲突，企业级多模块开发中团队间的沟通成本显著下降。对团队来说，这意味着业务模块可以各自定义同名 Bean 而互不干扰，模块内部也可以按自己的节奏演进依赖版本。
5. 内置 SOFAStack 中间件
基于 Spring Boot 自动配置与 starter 机制，SOFABoot 为所有 SOFAStack 中间件提供易用的编程接口，每个中间件都打包成自包含 starter，独立可插拔，按需引入即可，节省开发与后期维护成本。也就是说，在普通 Spring Boot 工程里想用 SOFA 系 RPC、注册、配置、限流、事务等中间件，不需要自己去摸索 SDK 接入，加一个 starter 依赖即可，自动配置会把它接进应用生命周期；而 SOFABoot 的前四项能力（就绪检查、类隔离、日志隔离、模块化）则保证这些中间件在大规模生产环境下也能和应用和平共处。
环境要求
编译 SOFABoot 源码需要：JDK 17，以及 Apache Maven 3.5.4 或更高版本。日常使用 SOFABoot 的工程则与普通 Spring Boot 工程一致，只要引入对应 starter 即可。
快速开始
官方在 SOFAStack 文档站 提供了完整的快速上手指南。配套的示例工程在 sofaboot-samples（4.x 分支），包含以下 demo：
- 标准 SOFABoot 示例工程：从零搭一个最普通的 SOFABoot 应用，验证基础自动配置与就绪检查；
- 带类隔离能力的示例工程：演示如何引入 SOFAArk 把应用与中间件类隔离开；
- 带 Spring 上下文隔离（模块化）能力的示例工程：演示多模块各自持有独立 Spring 上下文；
- 使用 SOFARPC 的示例工程：演示在 SOFABoot 里接入 SOFARPC 完成服务发布与引用。
生态与文档延伸
SOFABoot 不是孤立的项目，它是 SOFAStack 中间件体系面向 Spring Boot 开发者的入口。和它配套的关键组件包括：SOFAArk（类隔离与模块化打包框架）、sofa-common-tools（公共工具与日志约定）、SOFARPC（RPC 调用），以及注册、配置、限流、事务等中间件。深入理解健康检查内部机制，可以读官方源码解析文章 SOFABoot HealthCheck 机制解析；想了解模块化设计思路，可以看官方博客文章《SOFABoot 模块化实践》（sofastack.tech 文章）。完整的官方文档首页在 SOFABoot 文档站。
常见问题（FAQ）
- 问：SOFABoot 和 Spring Boot 是什么关系？ 答：SOFABoot 是基于 Spring Boot 的增强框架，不是替代品。你可以把它理解成"在 Spring Boot 之上加了就绪检查、类隔离、日志隔离、模块化和 SOFA 中间件 starter"的发行版。
- 问：就绪检查怎么暴露给平台？ 答：应用启动后，PaaS 或负载均衡访问
http://localhost:8080/actuator/readiness即可；未就绪时不要放流量，就绪后再把网关/负载均衡的流量切进来。 - 问：Hessian 3 和 Hessian 4 冲突怎么办？ 答：用 SOFAArk 类隔离，把依赖不同 Hessian 版本的 SDK 装到不同 ClassLoader 中，而不是强行统一版本。
- 问：多团队共用一个工程，BeanId 冲突怎么办？ 答：用 SOFABoot 的上下文隔离模块化能力，每个团队一个独立 Spring 上下文，Bean 沿依赖树解析，互不影响。
- 问：想深入了解健康检查机制？ 答：官方有专门的源码解析文章 SOFABoot HealthCheck 机制解析，以及一篇介绍模块化设计的技术文章。
- 问：二次开发要什么 JDK？ 答：当前源码在 JDK 17 下编译，Maven 要求 3.5.4 以上。
- 问：SOFABoot 的 starter 和 Spring Boot starter 写法冲突吗？ 答：不冲突。SOFABoot 就是基于 Spring Boot 的自动配置与 starter 描述符机制来封装 SOFA 中间件的，每个中间件一个独立 starter，想用到哪个就引哪个，用不到的不会被装配进来，这就是官方强调的"独立可插拔"。
- 问：上下文隔离和类隔离到底用哪个？ 答：类隔离解决"同一个类库版本冲突"，用 SOFAArk；上下文隔离解决"多模块 BeanId 冲突、团队边界"，用 Spring 上下文模块化。两者场景不同，可以单独用，也可以在一个工程里配合使用——官方就分别提供了带类隔离和带模块化能力的示例工程。
- 问：就绪检查会拖慢启动吗？ 答：它只是把"对外暴露"的时机后移到应用内部组件就绪之后，不会增加实际启动时长；收益是避免了启动期流量错误，这是生产环境发布自动化里不可或缺的一环。
- 问：从普通 Spring Boot 项目迁到 SOFABoot 成本高吗？ 答：核心动作是把依赖换成 SOFABoot 的 BOM/starter 坐标，业务代码基本不动；如果暂时不需要类隔离和模块化，只用就绪检查与日志隔离，迁移成本更低。官方示例工程就是按"标准工程 / 加类隔离 / 加上下文隔离 / 加 RPC"逐步叠加组织的，可以照着对号入座。
已知用户与社区
SOFABoot 已在大量生产环境使用，官方列出的已知用户包括蚂蚁集团、网商银行、恒生电子、Paytm、天弘基金、中国人保、南京银行、民生银行、中信证券、京东、网易云音乐、虎牙直播、中国移动、新华三、威马汽车等。这些用户覆盖了银行、保险、证券、基金、电商、直播、通信、汽车、金融科技等多个行业，说明 SOFABoot 这套在蚂蚁内部打磨的工程能力，在不同业务形态下都能落地。如果你也在使用，可以在 SOFAStack 使用者登记 留言分享你的场景。贡献代码前请先阅读 CONTRIBUTING.md。
SOFABoot 基于 Apache License 2.0 开源，其第三方依赖的许可证说明见 依赖组件版权说明。SOFA 的第一个版本由阿玺（Felix）创建，官方在此感谢他为 SOFA 打下的坚实基础，也感谢所有在 SOFA 历史中贡献过代码的人。如果你在生产中遇到问题，优先到 GitHub Issues 搜索或提问；社区材料见 SOFAStack 社区。