重庆定制网站建设公司,wordpress文章幻灯片代码,好网站建设公司北京,小程序源码之家蚂蚁金服金融科技产品技术部总经理杨冰#xff0c;在发布会分享了蚂蚁金服金融级云原生在双十一的大规模应用实践#xff0c;以下为演讲整理全文#xff1a; 2018年双11#xff0c;蚂蚁金服和网商银行正式应用云原生架构#xff0c;2019年双11#xff0c;蚂蚁金融级云原生…蚂蚁金服金融科技产品技术部总经理杨冰在发布会分享了蚂蚁金服金融级云原生在双十一的大规模应用实践以下为演讲整理全文 2018年双11蚂蚁金服和网商银行正式应用云原生架构2019年双11蚂蚁金融级云原生架构进一步深入落地Service Mesh 架构100%覆盖蚂蚁金服核心支付链路是业界最大的 Service Mesh 集群。本文将分享蚂蚁金融级云原生在2019年双11中的大规模应用实践。
历年双十一的交易峰值不断增长给整个技术带来了巨大挑战和牵引力。在这样的驱动力下技术架构又发生什么样的变革蚂蚁金服从第一代集中式架构逐步走向分布式架构再到云平台蚂蚁的架构已经形成了比较体系化的金融级分布式架构能够很好的去支撑业务的发展。
金融级分布式架构需要 Service Mesh
几代架构演进中虽然解决了很多业务痛点和问题但也确实让业务做了很多的升级、改造、上云等事情。我们开玩笑说云包治百病业务研发团队就问能不能让我们未来只关注业务开发本身剩下的事情交给基础设施我相信这个问题也是我们下一代架构往金融级云原生架构演进过程中需要去解决的一个问题也是云原生这个技术本身要解决的问题。总结来说交易规模的演进确实需要架构升级但架构升级不希望成为业务的负担。
如何解决这个问题呢我们先来回顾下架构演进的过程。 金融交易技术演进的第一阶段是实现金融级分布式架构SOFAStack 和 OceanBase 是构成这个架构的基础。需要强调的是整个金融级能力包括高可用、一致性、可扩展、高性能都需要应用到数据存储端到端整体能力。
比如分布式事务OceanBase 从数据库层面提供了分布式事务的支持但当我们把两个极其重要的业务数据放到两个 OceanBase 集群的时候就需要由应用层来解决跨数据库的一致性问题这个就是中间件需要提供的能力了。所以分布式架构下必须具备的端到端的一致性才能构成整体架构的一致性。高可用、可扩展、高性能也是一样的道理缺任何一个能力都不能算是真正的金融级分布式架构。 这张架构图的虚线以下表示的是目前蚂蚁的金融级分布式架构中的核心组件这一层软件经历了十几年的发展已经抽象的比较完备而且很好的支撑了业务的发展。
但真正系统实现中业务层跟下面几个组件有着千丝万缕的联系这个关系可能存在于下层为了减少上层的改动提供的兼容性SDK 里也许存在于上层迁就适配下层特殊用法里这样的例子层出不穷一直伴随着整个架构演进的过程。
而在下层演进发展过程中这种耦合和千奇百怪的兼容适配问题就会形成巨大的阻力和风险。金融IT同行在做数字化转型的时候也会遇到同样的痛点甚至于可能会比像蚂蚁金服这样的互联网公司遇到的困难更多一些。相比于互联网公司相对还比较统一的架构来说很多企业的IT 系统中就像博物馆三代同堂遗留系统一大堆还有很多外采的系统。所以这个架构分层虽然清晰但却无法独立演进。
蚂蚁同样有这样的问题内部有上千个系统几十万台服务器在业务迭代发展这么快的情况下根本没有太多精力来配合进行基础设施的升级。而业务不动基础设施就动不了很多能力就无法全局生效这样就发挥不了威力。
举个最简单的例子全链路压测很强大但如果没有自上而下的推动全业务线配合升级 SDK使得整体通信架构能支持全链路标识透传和识别的能力就无法实现全链路压测也许到今天我们还没法享受这个技术带来的红利。这样的例子很多很多的创新也是因为卡在「相互等待」的死锁中迟迟未能落地甚至胎死腹中。
软件世界里面有一句经典的话没有什么问题是不能通过一层抽象解决的如果说有那就再加一层。我们希望能够有这一层将业务和基础设施解耦正好云原生发展过程中出现了 Service Mesh而且这一层软件抽象从逻辑分层走向了物理分离既起到了解耦的作用又具备独立演进的能力。 康威定律认为一个软件系统的架构背后一定有对应的组织架构之前的架构中业务开发和基础设施开发虽然在组织上已经基本分开但软件上却没有切开Service Mesh 的出现正好解决了软件架构和组织架构不匹配的问题。
把这层抽象剥离变成独立的载体是一个趋势不仅仅 Service 应该被 Mesh 化更多的中间层可以被 Mesh 化蚂蚁也是这么实践的。这也是业务应用在云原生时代如何把自己的一些诉求更好的交给云让应用跟云之间的交互变得更简单的一个过程。 蚂蚁金服自研的 SOFAMesh 在双十一中大规模应用100%覆盖核心支付链路容器规模几十万千万 QPS性能消耗极低而将迭代速度从1-2次每年提升到10次每月。在 CPU、内存和相应时间等数据上来看我们通过极小资源的代价换来了系统快速迭代的速度在备战双十一的短短两个月Service Mesh 进行了几十次迭代和发布快速响应了全新的大促需求并完整多次的全站升级和全链路的线上验证。
这在以前几乎是不可想象的今年任务的复杂度和工作量如果没有 Service Mesh将无法完成。要么只能砍需求要么需要消耗更多业务研发的资源来配合我们做大量升级验证工作。遗留系统也能通过装配这样一套软件就能够具备完整的分布式架构能力且性能损失只有一点点同时还获得了分布式架构的快速演进能力因此这绝对是一个值得投资的技术方向。 SOFAMesh架构图
这个是 SOFAMesh 的架构图里面是分成控制面和数据面两个部分控制面是在产品层大家想要的一些能力走向微服务架构要解决什么样的问题希望在这个架构上有更多的运维能力、监控能力、流量调控能力、安全能力、扩展能力。
数据面 SOFAMosn 是独立出来的进程它可以跟 APP 进行交互和 APP 在一个 POD 里。图中除了 SOFAMosn 承载了 APP 之间的通信任务之外还将异步消息的通信逻辑也沉淀进去了成为应用对外同步异步通信的统一门面。同时我们也把应用访问数据库的中间层路由逻辑和配置管理逻辑独立成一个 sidecar称之为 DBMesh这个图里用 More Sidecar 来表示意味着未来可能有更多的逻辑可以下沉到 Mesh 层。
未来应用将使用非常轻薄的 SDK 或者简单的 API 跟外界交互而复杂的路由、治理、高可用等相关的逻辑就下沉到 Mesh 层了此后全局架构改造就会变得非常的轻松对业务没有打扰。
接入 Service Mesh 的挑战与解决之道
在应用 Service Mesh 的过程中蚂蚁金服也遇到了不少困难和挑战很多的社区方案其实并不能很好的满足金融行业的需求尤其对高可用、稳定性的苛刻要求蚂蚁在接入过程中也做了不少创新。
首先第一个问题是Service Mesh 是如何接入到整个体系里呢它的资源消耗又怎样呢 要按云原生社区的方式安装一个 sidecar就是扩容出来一批新的 POD里面已经为APP 装配好了 sidecar然后把老的 POD 逐步下线销毁。这就像要给一辆车装个新功能我们需要搞一批有这个新功能的新车给到客户然后把老车召回这个非常浪费资源。而且在给大规模集群上 sidecar 时需要更多的资源 buffer 去做滚动升级成本很高且效率很低而且连应用和 POD 一并销毁重建这个变更的动静太大也的确有不小的风险。 我们采用了注入升级的方式这里也对原生的 K8s 做了很多扩展的改动。
在资源消耗的优化方面我们也做了很多探索。理论上既然将这个进程独立出来跑在容器里就应该分配独立的 CPU 和内存资源我们开始也是这么做的但跑下来反而出现很多性能瓶颈。后来我们发现根本性问题在于虽然这个进程是独立的本质上它还是一段从应用里剥离出来的逻辑无论它是帮助应用做服务通讯还是访问数据库都是在应用主链路上如果为这些逻辑设置了跟应用不一样的 CPU 和内存限制反而会使得应用在做主链路业务的时候受到这个独立进程的资源消耗瓶颈影响。最后我们通过实践通过注入融合的方式跟应用一起去共享 CPU 和内存不但能达到最好效果也最大程度减少资源开销。
这整个升级的过程类似于我们把一辆普通的车注入一个模块变成了一个可持续升级的特斯拉随时随地做空中升级。而且这个模块与应用共享电源和公共资源达到最小的功耗。 既然空中升级的能力很好怎么样能稳妥保证这个模块自身的升级呢
社区的方案是销毁整个 POD连同 APP 和 sidecar再创造一个新的里面包含了原来的 APP 和新的 sidecar。这样一来虽然这个东西从应用层剥离出来但是还是跟应用放在一起整体作为一个软件创建、销毁、升级未免显得有些笨重。
其实大部分是要做这个进程的升级时应用是没有变化的。这种方案似乎也违背了把它剥离出来进行独立演进的初衷这也是我们探索过程中发现社区的方式不太理想的地方而且整个方案也没有流量摘除、优雅上下线这种设计整个方案比较简陋粗暴。 我们探索了独立升级 sidecar 的模式并且实现了较为复杂的流量热迁移。整个过程应用完全无感知就像是我们给别人打电话如果对方是个双胞胎当话筒被另一个接过去时我们还是面对的同样的电话同样的通话通道对方换了个人我们无感知。这样整个升级过程非常的平滑也对业务无打扰流量也不会出现波动符合金融级对稳定性的要求。
整个过程还是用车打比方之前看过一个劳斯莱斯的广告车子开过隔离带的时候里面的乘客没有任何感觉放在车上那杯水也没有任何的震动虽然没坐过这么好的车不知道是否真的能做到像广告里的效果但整个过程很震撼。我想平滑升级的效果就应该像这个过程一样。
Service Mesh 在双11大促中起到了什么作用呢我们先回顾下过去做过的一些事情。 蚂蚁在上云后整个系统具备了弹性伸缩能力于是每次在搞大促活动无论双11、双12还是新春红包我们都将对应业务链路的系统动态弹到云上用完了再缩回来。这个动作说起来简单其实非常复杂而且操作的变更非常大但是由于几个活动间隔时间足够长所以我们可以比较坦然的做这个事情而且还是会额外消耗资源。
今年提了新要求双11零点要搞天猫大促第二天早上7点蚂蚁森林又要支持偷能量搞活动考虑到双十一后还有两三个小时处理收尾流量和降级的调度任务留给系统做调度的时间也就短短的4、5个小时怎么样在这么短的时间内将一个业务链路上的系统全部熄火再把另外一条拉起来预热到最佳状态而且不允许额外增加资源这个挑战非常大。 我们通过类似超卖的方式把两条链路的应用部署在同一组 POD 里一组处于运行态一组处于保活态当需要切换时我们将运行态的资源收缩流量比例调低变为保活态把另一组应用做反向操作变成运行态。
整个过程我们做了非常精细化的流量调拨、转发、保活。保活非常重要因为应用在这么短时间热起来需要有一定的保活流量来维系应用的基本状态包括DB连接、通信连接、缓存等等。Service Mesh 在切换过程中将一部分流量转发到别的机器一部分放进来用于维系应用的「热状态」。
听到这里大家可能会问这样的场景是不是只有像蚂蚁金服或者是阿里巴巴大的一些公司才会有的这个功能对于我来说有什么用对于大部分的企业的意义是什么呢这些流量调拨能力只是 Service Mesh 在大促应用场景当中一个小小的尝试。Mesh 架构除了解决基础设施下沉的一些问题之外我认为最大的价值在于服务化流量的精细化管控这也是精细化运维的趋势。 以上图为例这里介绍了精细化流量管控的三个方面包括多版本发布、压测引流、服务分组。
很多朋友听过灰度发布新上一个服务线上灰度验证一下控制一定的流量比例给新服务如果 OK 再全量放开这件事情听上去也不难例如这个服务就是外部流量入口的话很容易控制入口流量的比例因为流量上游就是外部客户请求一定是有接入层可以控制的但当是一个上游有好几十个甚至好几个百各应用来调用就不那么好控制了。
如果我们想同时验证一组新服务可能更难如何能保证这个灰度流量只在这组新服务之间流转而不逃逸出去如果没有统一的流量调拨能力就没有办法控制这么细那只能用大招就是用额外的资源单独开辟一个环境或者是单独开辟一个机房专门作为灰度环境流量在这个环境内闭环这个方案可行也是我们目前在用的方案之一但是成本很高。如果全部装上这套系统就可以在线划分出来任意的逻辑单元做流量灰度做多版本验证发布。
同样的逻辑也适用于细粒度的容灾切换、引流压测、服务分组等未来可以基于这种全局的流量管控能力做很多创新来做稳定性和高可用的事情也能帮助业务做灵活的业务相关的流量调拨。
Service Mesh 带来的全局流量管控能力就好比手机导航。比如要从国贸去北京南站系统会给你一个推荐路线。当大家都用同类软件的时候整个系统就能根据整个交通通行状况给不同的人不同的推荐路线以便最大程度的提升整体交通的吞吐量在全局形成最优方案。这就是导航系统通过手机这个 sidecar 来进行全局车流量调拨和优化的场景这也是 Service Mesh 可以给我们系统带来的价值。在这个方向上我们内部已经有很多新的探索在做我相信未来会有更多的创新玩法出来。
蚂蚁金服 Service Mesh 正式对外开放 以上提到的技术会我们会在 SOFAStack 的微服务平台上逐步开放大家可能也都遇到了异构系统无法统一治理、分布式改造成本比较高、技术栈绑定等问题也在希望能有一种方式简单直接的帮助整个系统改造为一套分布式系统并且能适配兼容各种框架。我们今天开放的 SOFAMesh 可以以无侵入的方式帮助应用进行分布式改造支持多种协议兼容异构系统不但可以跑在云原生还可以跑在虚机上。且经过了大规模金融级的线上验证。 这个图是大概的架构不展开讲核心意思是说这样一套体系可以兼容蚂蚁金服的 SOFA 系统也可以兼容社区的 Dubbo 应用、SpringCloud 应用整个可以跑在云原生架构上也可以跑在虚拟机架构上背后是有经过我们多年考验的服务注册中心作为支撑。
现在我们只迈出一小步在未来还会继续做更多探索。除了服务化我们正在把全机房流量都统一管理起来无论是从网络接入层进来的南北向流量还是一个机房内部的东西向或者是机房之间的东西向流量全部纳入到一套体系上来管理。同时在对外的产品上为了帮助更多的客户适配已有的体系我们也在做针对不同的注册中心适配工作以便能够纳入到同一个控制面统一管理这个是未来演进的方向。
这些技术本身有很多核心的代码也是开源的对内在跟阿里集团在共建对外也在努力向 upstream 做贡献跟谷歌这样的公司合作。我们希望能够得到大家更多的关注并参与贡献也希望大家能积极参与到云原生架构在金融场景的落地探索中来。
原文链接 本文为云栖社区原创内容未经允许不得转载。
