2019年11月19日,蚂蚁金服在北京举办“巅峰洞见·聚焦金融新技术”发布会,介绍2019双11支付宝背后的技术,并重磅发布全新 OceanBase 2.2 版本和 SOFAStack 双模微服务平台。咱们将系列演讲整理并发布在 “蚂蚁金服科技” 公众号上,欢迎关注。
蚂蚁金服金融科技产品技术部总经理杨冰,在发布会分享了蚂蚁金服金融级云原生在双十一的大规模应用实践,如下为演讲整理全文:数据库
2018年双11,蚂蚁金服和网商银行正式应用云原生架构,2019年双11,蚂蚁金融级云原生架构进一步深刻落地,Service Mesh 架构100%覆盖蚂蚁金服核心支付链路,是业界最大的 Service Mesh 集群。本文将分享蚂蚁金融级云原生在2019年双11中的大规模应用实践。缓存
历年双十一的交易峰值不断增加,给整个技术带来了巨大挑战和牵引力。在这样的驱动力下,技术架构又发生什么样的变革?蚂蚁金服从第一代集中式架构,逐步走向分布式架构,再到云平台,蚂蚁的架构已经造成了比较体系化的金融级分布式架构,可以很好的去支撑业务的发展。安全
几代架构演进中,虽然解决了不少业务痛点和问题,但也确实让业务作了不少的升级、改造、上云等事情。咱们开玩笑说云包治百病,业务研发团队就问,能不能让咱们将来只关注业务开发自己,剩下的事情交给基础设施?我相信这个问题也是咱们下一代架构往金融级云原生架构演进过程当中须要去解决的一个问题,也是云原生这个技术自己要解决的问题。总结来讲:交易规模的演进确实须要架构升级,但架构升级不但愿成为业务的负担。服务器
如何解决这个问题呢?咱们先来回顾下架构演进的过程。网络
金融交易技术演进的第一阶段是实现金融级分布式架构,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,将没法完成。要么只能砍需求,要么须要消耗更多业务研发的资源来配合咱们作大量升级验证工做。遗留系统也能经过装配这样一套软件,就可以具有完整的分布式架构能力,且性能损失只有一点点,同时还得到了分布式架构的快速演进能力,所以这绝对是一个值得投资的技术方向。
<p style="text-align:center">SOFAMesh架构图</p>
这个是 SOFAMesh 的架构图,里面是分红控制面和数据面两个部分,控制面是在产品层你们想要的一些能力,走向微服务架构要解决什么样的问题,但愿在这个架构上有更多的运维能力、监控能力、流量调控能力、安全能力、扩展能力。
数据面 SOFAMosn 是独立出来的进程,它能够跟 APP 进行交互,和 APP 在一个 POD 里。图中除了 SOFAMosn 承载了 APP 之间的通讯任务以外,还将异步消息的通讯逻辑也沉淀进去了,成为应用对外同步异步通讯的统一门面。同时咱们也把应用访问数据库的中间层路由逻辑和配置管理逻辑独立成一个 sidecar,称之为 DBMesh,这个图里用 More Sidecar 来表示,意味着将来可能有更多的逻辑能够下沉到 Mesh 层。
将来应用将使用很是轻薄的 SDK 或者简单的 API 跟外界交互,而复杂的路由、治理、高可用等相关的逻辑就下沉到 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大促中起到了什么做用呢?咱们先回顾下过去作过的一些事情。
蚂蚁在上云后整个系统具有了弹性伸缩能力,因而每次在搞大促活动,不管双十一、双12仍是新春红包,咱们都将对应业务链路的系统,动态弹到云上,用完了再缩回来。这个动做提及来简单,其实很是复杂,并且操做的变动很是大,可是因为几个活动间隔时间足够长,因此咱们能够比较坦然的作这个事情,并且仍是会额外消耗资源。
今年提了新要求,双11零点要搞天猫大促,次日早上7点蚂蚁森林又要支持偷能量搞活动,考虑到双十一后还有两三个小时处理收尾流量和降级的调度任务,留给系统作调度的时间也就短短的四、5个小时,怎么样在这么短的时间内将一个业务链路上的系统所有熄火,再把另一条拉起来预热到最佳状态,并且不容许额外增长资源,这个挑战很是大。
咱们经过相似超卖的方式把两条链路的应用部署在同一组 POD 里,一组处于运行态,一组处于保活态,当须要切换时,咱们将运行态的资源收缩,流量比例调低,变为保活态,把另外一组应用作反向操做变成运行态。
整个过程咱们作了很是精细化的流量调拨、转发、保活。保活很是重要,由于应用在这么短期热起来,须要有必定的保活流量来维系应用的基本状态,包括DB链接、通讯链接、缓存等等。Service Mesh 在切换过程当中将一部分流量转发到别的机器,一部分放进来用于维系应用的「热状态」。
听到这里你们可能会问,这样的场景是否是只有像蚂蚁金服或者是阿里巴巴大的一些公司才会有的?这个功能对于我来讲有什么用?对于大部分的企业的意义是什么呢?这些流量调拨能力只是 Service Mesh 在大促应用场景当中一个小小的尝试。Mesh 架构除了解决基础设施下沉的一些问题以外,我认为最大的价值在于服务化流量的精细化管控,这也是精细化运维的趋势。
以上图为例,这里介绍了精细化流量管控的三个方面,包括多版本发布、压测引流、服务分组。
不少朋友听过灰度发布,新上一个服务,线上灰度验证一下,控制必定的流量比例给新服务,若是 OK 再全量放开,这件事情听上去也不难,例如这个服务就是外部流量入口的话,很容易控制入口流量的比例,由于流量上游就是外部客户请求,必定是有接入层能够控制的,但当是一个上游有好几十个,甚至好几个百各应用来调用就不那么好控制了。
若是咱们想同时验证一组新服务可能更难,如何能保证这个灰度流量只在这组新服务之间流转而不逃逸出去?若是没有统一的流量调拨能力就没有办法控制这么细,那只能用大招,就是用额外的资源,单独开辟一个环境,或者是单独开辟一个机房,专门做为灰度环境,流量在这个环境内闭环,这个方案可行,也是咱们目前在用的方案之一,可是成本很高。若是所有装上这套系统,就能够在线划分出来任意的逻辑单元,作流量灰度,作多版本验证发布。
一样的逻辑也适用于细粒度的容灾切换、引流压测、服务分组等,将来能够基于这种全局的流量管控能力作不少创新,来作稳定性和高可用的事情,也能帮助业务作灵活的业务相关的流量调拨。
Service Mesh 带来的全局流量管控能力就比如手机导航。好比要从国贸去北京南站,系统会给你一个推荐路线。当你们都用同类软件的时候,整个系统就能根据整个交统统行情况给不一样的人不一样的推荐路线,以便最大程度的提高总体交通的吞吐量,在全局造成最优方案。这就是导航系统经过手机这个 sidecar 来进行全局车流量调拨和优化的场景,这也是 Service Mesh 能够给咱们系统带来的价值。在这个方向上,咱们内部已经有不少新的探索在作,我相信将来会有更多的创新玩法出来。
以上提到的技术会咱们会在 SOFAStack 的微服务平台上逐步开放,你们可能也都遇到了异构系统没法统一治理、分布式改形成本比较高、技术栈绑定等问题,也在但愿能有一种方式简单直接的帮助整个系统改造为一套分布式系统,而且能适配兼容各类框架。咱们今天开放的 SOFAMesh 能够以无侵入的方式帮助应用进行分布式改造,支持多种协议,兼容异构系统,不但能够跑在云原生,还能够跑在虚机上。且通过了大规模金融级的线上验证。
这个图是大概的架构,不展开讲,核心意思是说这样一套体系能够兼容蚂蚁金服的 SOFA 系统,也能够兼容社区的 Dubbo 应用、SpringCloud 应用,整个能够跑在云原生架构上,也能够跑在虚拟机架构上,背后是有通过咱们多年考验的服务注册中心做为支撑。
如今咱们只迈出一小步,在将来还会继续作更多探索。除了服务化,咱们正在把全机房流量都统一管理起来,不管是从网络接入层进来的南北向流量,仍是一个机房内部的东西向,或者是机房之间的东西向流量,所有归入到一套体系上来管理。同时,在对外的产品上,为了帮助更多的客户适配已有的体系,咱们也在作针对不一样的注册中心适配工做,以便可以归入到同一个控制面统一管理,这个是将来演进的方向。
这些技术自己有不少核心的代码也是开源的,对内在跟阿里集团在共建,对外也在努力向 upstream 作贡献,跟谷歌这样的公司合做。咱们但愿可以获得你们更多的关注并参与贡献,也但愿你们能积极参与到云原生架构在金融场景的落地探索中来。