金融级云原生如何助力双十一?蚂蚁金服的实践经验是这样

蚂蚁金服金融科技产品技术部总经理杨冰,在发布会分享了蚂蚁金服金融级云原生在双十一的大规模应用实践,以下为演讲整理全文:

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 做贡献,跟谷歌这样的公司合作。我们希望能够得到大家更多的关注并参与贡献,也希望大家能积极参与到云原生架构在金融场景的落地探索中来。


原文链接
本文为云栖社区原创内容,未经允许不得转载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/517322.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

KAFKA 最新版 Shell API单机生产与消费

文章目录一、KAFKA 启动与监控二、KAFKA 主题创建于查看生产与消费2.1. 查看主题列表2.2. 创建主题2.3. 查看主题信息2.4. 主题信息分析三、KAFKA 主题创建于查看生产与消费3.1. 客户端监听消息3.2. 生产消息3.3. 从头监听消息一、KAFKA 启动与监控 # 后台启动kafka kafka-ser…

地理文本处理技术在高德的演进(上)+

一、背景 地图App的功能可以简单概括为定位,搜索,导航三部分,分别解决在哪里,去哪里,和怎么去的问题。高德地图的搜索场景下,输入的是,地理相关的检索query,用户位置,Ap…

js倒计时

倒计时 js代码倒计时 var time_now_server,time_now_client,time_end,time_server_client,timerID; var oDate new Date();var year oDate.getFullYear(); //获取系统的年;var month oDate.getMonth()1; //获取系统月份,由于月份是从0开始计算&…

免费12个月!阿里云助力中小企业0成本上云

最新消息,阿里云宣布为企业用户推出云服务器免费12个月扶持计划,助力中小企业0成本上云。阿里云表示,该计划每年投入2000万,超5万中小企业受益,本计划已于2019年11月27日上线。 阿里云智能总裁张建锋在2019阿里云峰会…

KAFKA 同步和异步消息的发送(开发实战)

文章目录一、消费者监听1. 启动zk2. 启动kafka3. 创建主题4. 消费者监听消息二、生产者工程2.1. 依赖2.2. 生产者代码(同步)2.3. 生产者代码(异步)2.4. 发送消息2.5. 消费者监听消息2.6. 结果返回一、消费者监听 1. 启动zk zkSe…

如何通过自动增加索引,实现数据库查询耗时降低50%?

作者 | 利开园责编 | Carol封图 | CSDN 下载自视觉中国很多开发者都遇到类似这样的经历:一个产品功能开发测试都正常,发布上线后也正常,但是过一段后,如果有个活动或流量一大程序就突然卡了,也有可能流量正常也没搞活动…

重磅下载 | 核心系统100%上云,揭秘双11背后的云原生实践

2019 双11,订单创新峰值达到 54.4 万笔/秒,单日数据处理量达到 970PB,面对世界级的流量洪峰,今年的阿里交出了一份亮眼的云原生技术成绩单,并实现了100% 核心应用以云原生的方式上云: 双11 基础设施 100% …

./mysqld: error while loading shared libraries: libnuma.so.1: cannot open shared object file: No suc

./mysqld: error while loading shared libraries: libnuma.so.1: cannot open shared object file: No such file or directory解决方案: yum -y install numactl

MongoDB与阿里云达成战略合作,最新数据库独家上线阿里云!

11月26日,开源数据库厂商MongoDB与阿里云在北京达成战略合作,作为合作的第一步,最新版MongoDB 4.2数据库产品正式上线阿里云平台。 目前阿里云成为全球唯一可提供最新版MongoDB服务的云厂商,双方合作打通了企业在云上使用最新版开…

程序员:我受够了!不想再在小厂里干Java了!

你是否熟悉这样的情形:每天10点到公司,打开电脑:10个小时的增删改查,搬砖写代码的一天就这样开始了。刚毕业时候的你踌躇满志,按照自己的原定计划,这时候应该混到了阿里P6。可现在在小厂苦苦挣扎&#xff0…

AnalyticDB for MySQL技术架构解析

企业数据需求不断变化,近年来变化趋势日益明显,从数据的3V特性看:体积,速度和变化;Big Data强调数据量,PB级以上,是静态数据。而Fast Data在数据量的基础上,意味着速度和和变化&…

双十一|又快又稳!闲鱼实时事件规则计算驱动平台

闲鱼双十一金鳞抽奖玩法 相信今年在11月7日-11月11日期间使用过闲鱼的用户,可能已经被如下图所示的幸运海星“砸”到过了。只要用户进入到指定的几个页面,或者在某些指定的页面有点击行为,就会触发到这样一个幸运之星。这就是今年闲鱼双十一…

“编程能力差的程序员,90%会输在这点上”谷歌AI专家:其实都是瞎努力

最近几年,我看过市面上很多 Python和人工智能的教程和书籍,它们大都这样讲:先从 Python 人工智能的历史讲起开始,再介绍的基本语法规则,Python 的 list, dict, tuple 等数据结构,最后学习机器学习、深度学习…

阿里科学家再获世界级荣誉,平头哥首席科学家谢源当选AAASFellow

11月27日,美国科学促进会(AAAS)公布了2019年度会士(Fellow)增选结果,阿里巴巴平头哥首席科学家、达摩院高级研究员谢源当选,这也是信息、计算和通信领域新当选的24名Fellow之一,一同…

开放下载!从RCNN到SSD,这应该是最全的一份目标检测算法盘点

导读:从简单的图像分类到3D姿势识别,计算机视觉从来不缺乏有趣的问题和挑战。通过肉眼我们可以检测出一张宠物照中的猫和狗,可以识别出梵高作品《星夜》中的星星和月亮,那如何通过算法赋予机器“看”的智能,就是我们接…

全网最详细TCP参数讲解,再也不用担心没有面试机会了......

作者 | 小林coding责编 | 王晓曼封图 | CSDN 下载自视觉中国前言TCP 性能的提升不仅考察 TCP 的理论知识,还考察了对于操作系统提供的内核参数的理解与应用。TCP 协议是由操作系统实现,所以操作系统提供了不少调节 TCP 的参数。Linux TCP 参数如何正确有…

图片的缩放与拖拽

这个图片的缩放的流畅度还是很好的&#xff0c;需要引入touch.js,好像是百度团队那边写的 <script src"./js/touch.min.js" type"text/javascript"></script> $(function() { //放大缩小var scaleVal 1;var initialScale scaleVal || …

为了帮助卖家成交,闲鱼工程师做了些什么?

引言 闲鱼是一个C2C平台&#xff0c;提高卖家活跃度不仅有利于成交的提升&#xff0c;对于用户增长也有积极意义。而其中的关键点就在于其成交的效率。而个人卖家由于其专业程度不如专业卖家&#xff0c;成交效率往往并不高。我们希望可以实现两个提升&#xff1a; 能帮助卖家…

TOP互联网公司都在用,为什么SRE比传统运维更抢手?

阿里妹导读&#xff1a;双11的完美收官&#xff0c;2684亿的销售奇迹及顺滑极致的客户体验让双11背后的技术再次被推到风头浪尖。而双11技术热点话题&#xff0c;不得不提集团核心系统100%上云这一技术创举。 作为集团上云的底座产品&#xff0c;ECS承担了集团上云基础设施的重…

***error*** (zip#Browse) unzip not available on your system

文章目录1. 修改jar配置文件2. 现象3. 解决方法1. 修改jar配置文件 vim xxx.jar2. 现象 用不同用户打开&#xff0c;效果是不一样的&#xff0c;下图分别是 root账号、普通用户打开的 root账号显示异常还不明显&#xff0c;切换成普通用户后发现就很明显了&#xff0c;原来…