共计 4330 个字符，预计需要花费 11 分钟才能阅读完成。
作者简介
赵真灵（有济）
蚂蚁团体技术专家，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 扩大之沙箱平安