赵真灵（有济）

蚂蚁集团技术专家

Serverless 和微服务领域专家

曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩与产品建设。当前主要负责应用架构演进和 Serverless 相关工作。同时也是 SOFAArk 社区的开发和维护者以及 KNative 社区的贡献者。

本文  3612  字，预计阅读  12  分钟

传统微服务架构面临的

问题和挑战？

应用架构从单体应用发展到微服务，结合软件工程从瀑布模式到当前的 DevOps 模式的发展，解决了可扩展、分布式、分工协作等问题，为企业提供较好的敏捷性与执行效率，给企业带来了明显的价值。但该模式发展至今，虽然解决了一些问题，也有微服务自身的问题慢慢暴露出来，在当前已经得到持续关注：

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

对于基础设施的问题，在服务网格和应用运行时的工作已经取得了一定的成果，但是基础设施到业务开发之间还存在业务通用的部分，这里当前没有一个模式来给予支持。

当前已经有一些开源项目在尝试解决基础设施的问题，例如服务网格、应用运行时，如 Dapr/Layotto，也都在实际应用中得到了不错的效果。但当前服务网格和应用运行时更多的是将中间件以下下沉到 sidecar，而一个应用一般还包括通用的业务逻辑部分，要让更广泛的业务也能享受到无基础设施的体感，也需要让业务以下（可以把业务层以下的看作基础设施）都能屏蔽。另外当前对于中小企业来说，使用服务网格和应用运行时的成本还是比较高的。

2、拆分微服务的资源与维护成本高：

拆分后每个子应用都包含公共部分（框架、中间件等），除了同样存在上述第一个问题之外，还需要独占机器资源成本高，如果部分业务萎缩，会面临长尾应用问题，需要承担长期维护的成本。

3、拆分微服务的敏捷度与业务、组织发展的敏捷度不一致，导致如何合理地拆分微服务始终是个老大难的问题：

• 拆得多增加了资源和管理成本；

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

蚂蚁的解决思路和方案

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

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

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

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

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 在未来能成为一种普适的技术。

欢迎 9 月 3 号 来 QCon 大会现场一起探讨微服务架构新模式。

 了解更多...

SOFAServerless Star 一下✨：

https://github.com/sofastack/sofa-serverless

推荐阅读

超越边界：FaaS 的应用实践和未来展望

如何看待 Dapr、Layotto 这种多运行时架构？

SOFABoot 4.0 正式发布，多项新特性等你来体验！

MoE 系列（七）｜ Envoy Go 扩展之沙箱安全