珠宝网站制作,专业的建站,网站做seo有什么作用,saas系统怎么读赵真灵#xff08;有济#xff09; 蚂蚁集团技术专家 Serverless 和微服务领域专家曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩与产品建设。当前主要负责应用架构演进和 Serverless 相关工作。同时也是 SOFAArk 社区的开发和维护者… 赵真灵有济 蚂蚁集团技术专家 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 扩展之沙箱安全
