蚂蚁 SOFAServerless 微服务新架构的探索与实践

应⽤架构从单体应⽤发展到微服务，结合软件⼯程从瀑布模式到当前的 devops 模式的发展，解决了可扩展、分布式、分⼯协作等问题，为企业提供更好的敏捷性与执⾏效率，给企业带来明显的价值。但该模式发展⾄今，解决了⼀些问题，也有微服务⾃身的问题随着发展慢慢暴露出来，在当前已经得到持续关注：

1. 业务开发者需要感知复杂基础设施，启动慢（分钟级），研发效率低，运维负担重。

对于基础设施的问题，当前有⼀些开源项⽬在尝试解决，例如服务⽹格、应⽤运⾏时，如 darp/layotto，也在实际应⽤中都得到了不错的效果。但当前服务⽹格和应⽤运⾏时更多的是将中间件以下下沉到 sidecar，⽽⼀个应⽤⼀般还包括通⽤的业务逻辑部分，要让更⼴泛的业务也能享受到⽆基础设施的体感，也需要让业务以下（可以把业务层以下的当做基础设施）都能屏蔽。另外当前对于中⼩企业来说，使⽤服务⽹格和应⽤运⾏时的成本还是⽐较⾼的。

2. 拆分微服务的资源与维护成本⾼：拆分后每个⼦应⽤都包含公共部分（框架、中间件等），同样存在上述第⼀个问题之外，还需要独占机器资源成本⾼，如果部分业务萎缩，会⾯临⻓尾应⽤问题，需要承担⻓期维护的成本。

3. 拆分微服务的敏捷度与业务、组织发展的敏捷度不⼀致，如何合理的拆分微服务始终是个⽼⼤难的问题

• 拆得多造成资源和管理成本

• 拆的不够造成协作效率问题，有些是应该拆但没拆，有些是因为业务领域已经较为细分不便再拆。特别是在⼀些中小企业⾥，可能都没有微服务的配套设施。

为了解决这些问题，我们对应⽤同时做了横向和纵向的拆分，纵向拆分：把应⽤拆分成基座和模块两层，这两层分别对应两层的组织分⼯，基座⼩组与传统应⽤⼀样，负责机器维护、通⽤逻辑沉淀、模块架构治理，并为模块提供运⾏资源和环境。模块在业务层以下所有的基础设施、应⽤框架、中间件可以不再关注，聚焦在业务逻辑研发本身，并且采⽤ jar 包的研发模式，具备秒级的验证能⼒，让模块开发者得到极致的提效。

这可以理解为这套架构的核⼼模型，核⼼的能⼒有两个：平台化 + 模块化。模块化是 20 年前 OSGI 就已经提出的概念，从 OSGI -> JPMS ⼀直未被抛弃，到最近 Spring modulith，serviceWeaver 等⾏业⾥⼜兴起⼀些开源框架，⼀直在发展；平台化从 2017 年出现在技术雷达到 2023 年被 Gartner 列为 10⼤战略趋势之⼀，到现在国内的平台⼯程，不断得到重视和发展。⽽我们实际上在⾏业还没对这两个技术⽅向充分关注的情况下，就在尝试把他们结合起来，并在蚂蚁内部得到规模化验证和落地，给业务带来极致的降本增效效果。

该模式的另⼀个特点是可演进、可回滚，这⾥的模块如果业务发展壮⼤，可以独⽴部署成微服务，如果微服务拆分过多，可以低成本改造成模块，合并部署在⼀起，解决资源成本和⻓期维护成本。实际上可以理解为我们是在单体应⽤架构和传统微服务架构中间，增加了⼀个可以演进过度的架构。

总结下来这套新微服务架构可以解决这四个问题：

1. 通过横向拆分出基座屏蔽业务以下的基础设施、框架、中间件和业务通⽤逻辑等部分，从⽽极⼤降低了业务开发者的认知负荷、提⾼了开发效率。

2. ⼀个应⽤可以低成本改造或拆分出多个模块，模块间可以并⾏独⽴迭代，从⽽解决了多⼈协作阻塞问题，每个模块不单独占⽤机器资源，没有拆分的机器成本问题。

3. 存量微服务如果拆分过多，可以低成本改造成模块应⽤，合并部署在⼀起，解决拆分过多带来的资源成本和维护成本痛点。

4. 模块可以灵活部署，解决微服务拆分与组织发展灵敏度不⼀致导致的协作低效与分⼯不合理问题。应⽤拆分出多个模块，可以部署在⼀起，也可以进⼀步演进成独⽴微服务，同样如果微服务拆分过多，也可以低成本改回模块合并部署到⼀起。

这⾥卖个关⼦，为什么这些技术在蚂蚁能规模化落地，存量的业务 owner 在平衡业务迭代进度和升级新架构做权衡时，我们是做了哪些⼯作？可以在 9⽉3 号 Qcon ⼤会现场获得更详细的信息。

举个当前蚂蚁实际业务采⽤新模式前后的对⽐数据：

可以看到这些数据是⼗倍级以上的提升，当前蚂蚁所有 BU 都已经接⼊，将近 40W core 的在线业务，并为两种业务模式：中台模式和轻应⽤模式的业务都提供秒级研发运维的能⼒。⼀个基座上⾯最多有上百个模块，⼀个开发同学在研发验证阶段，⼀下午可以验证上百次，需求的交付效率最快可以到⼩时级别。

当前⾏情下，企业对新技术会更加谨慎，技术⼈也对新技术采取保守态度，新技术虽然很酷，但投⼊⼤落地场景有限。这其实是发展过程的转换，在⾼速发展的⾏情下，⼀⽅⾯是历史包袱少，另⼀⽅⾯是乐观态度占据主导，更加相信新技术能较快得到规模化落地，整个社会都对新技术充满热情。⽽在当下阶段，很多企业已经有⼀定的历史包袱，新技术规模化落地需要较⻓的周期，需要整个体系⼀起演进才可能达到最初的预想，可能也会带来越来越繁复的基础设施，所以当前⾏业对新技术更加偏保守也是⾮常合理的。

所以蚂蚁在建设这套微服务新架构时，有⼀个⾮常关键的设计思路，那就是要接地⽓或者是可演进，也即是要让存量业务能低成本接⼊。最初蚂蚁在落地该模式时，这也是踩过的最⼤的坑，⼀个普通应⽤转换成基座需要花费上⽉时间（包括流量迁移），模块研发也与现有基础设施不匹配导致模块研发成本也很⾼，这个问题在当时也成为影响该模式在蚂蚁落地⽣死存亡的问题。后来我们在这块上投⼊了很⼤精⼒，最终让普通应⽤在⼩时内可以成为基座或模块，研发模式也与普通应⽤基本⼀致。

经过这个过程，最终低成本、可演进也成为了该模式的⼀个核⼼优势。未来对外开源，我们会把接地⽓做的更加彻底，不对企业的基础设施程度有预设条件。

• ⽆需容器化也可以接⼊

• ⽆需使⽤ k8s 平台也可接⼊

• ⽆需具备微服务配套设施可也接⼊

• ⽆需服务⽹格化也可接⼊

我们做的这套模式在⾏业⾥没有先例，我们是在⽆⼈区⾥摸索，挑战是多⽅⾯的：

1. 模块化技术的质疑，为什么现在模块化技术⼜开始被关注？为什么我们基于 SOFAArk 的模块化技术能推⼴？挑战主要集中在如何制定合理的隔离和共享通信策略，我们需要避免 OSGI 之类的复杂度问题，做到可以低成本使⽤。

2. 模块化技术采⽤了多 ClassLoader, 对于 ClassLoader 的隔离，卸载不⼲净，我们⼀步⼀个脚印，深⼊并体系化分析底层问题，制定各种问题的解法，需要⽤实际效果证明多 ClassLoader 的问题对业务的影响能否做到可控可接受范围内。

3. 相⽐于传统应⽤发布运维调度是建⽴在机器维度上的，我们是在机器维度之上做了三层运维调度，这⾥成熟的配套能⼒需要多团队协作共同推动建设：运维能⼒、机器分组、流量分组调拨、监控、⽇志、trace、⻛险防御等都有全新的建设，⽽这些在蚂蚁现有的技术体系⾥，与现有的基础设施不匹配，有很多的适配改造、多团队协作推动⼯作。

4. 存量业务在快速迭代的压⼒下为何会选择接⼊这套新的模式？怎么低成本是影响⽤户是否愿意接⼊的关键，在低成本上做了⼤量⼯作，基座的改造、存量的应⽤改造成模块、存量的应⽤拆分成多个模块。

5. 这套模式对业务应⽤的分层，需要业务⽅团队的配合调整，这⾥⽤户⼼智培养和宣讲，需要有⼀个过程。

⼀个新的模式不是⼀蹴⽽就的，也不是⼀夜之间就提出的。新的模式的出现⼀般是在前⼈探索的基础上，⽤新的思路⽅法，保持解决问题的初⼼坚持下去，最终慢慢的成型的。

• 当前在解决基础设施屏蔽上，从 docker 到 kubernetes 到 sidecar 到 应⽤运⾏时等⽅向在发展，这⾥更多是从底层向上层的发展。⽽我们实际上可以从另⼀个⽅向，也就是⾄上⽽下的来考虑建设，我们直接从应⽤这层做了纵向的拆分，把业务以下的所有部分打包成基座这层，基座及以下的所有基础设施也就直接对业务开发者屏蔽了。所以相同问题，从不同⻆度出发可以有新的⽅法，得到新的效果。

• 3 年前的时候还没有那么多对微服务反思的声⾳，也还没有应⽤运⾏时（dapr）的概念，对模块化技术的也更多的是不看好，我们做的事情在⾏业⾥没有指引的⽅向。⽽我们依旧紧盯业务痛点，也并没有因为困难⽽采取妥协的策略，⽐如⼀个基座上只允许⼀个模块，⼀个模块只能使⽤ spi 模式，我们实际上⾛了⼀条最难的路线，这更多的是⼀群⼈的坚持，业务的理解和认可，组织的包容，才最终在蚂蚁得到规模化的落地。

当前应⽤的架构，有两个⽅向的发展，纵向不断地把业务以下的逻辑和依赖下沉，横向不断的往更细粒度的⽅向发展，未来 Serverless 会有多种形态，但也是在这两个⽅向上的发展，例如 BaaS + FaaS 模式，但是对于存量应⽤如何使⽤上这套模式，⼀直是这个⾏业⾥的问题，这个问题是挑战，也就是⾏业⾥的机会。我们需要⼀套能让应⽤平滑逐步演进到未来 Serverless 形态的应⽤架构和平台能⼒。

软件架构好⽐建造⼀座⼤厦，是⼀层⼀层的沉淀稳定，⼀层⼀层的建设，观察 kubernetes 资源编排这层已经相对成熟，当前领域⾥更多是在做 mesh/ 微服务这层，这⼀层未来也成熟稳定时，相信也是会出现⼏个类似 kubernetes 的产品，这是我们当前的机会，当然这⾥⾯也是充满挑战。

今年我们会把我们这套能⼒对外开源，欢迎有志之⼠参与共建，可以关注 SOFAServerless，共同解决微服务领域⾥的问题，让普通应⽤可以低成本演进到 Serverless  模式，让未来 serverless 能成为⼀种普世的技术。

欢迎 9⽉ 3 号 来 Qcon 大会现场⼀起探讨微服务架构新模式 。