阿里基础设施的云化实践
本帖最后由 168主编 于 2019-10-20 12:00 编辑http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_1.jpeg本文内容节选自由msup主办的第七届TOP100summit，阿里巴巴高级技术专家吕奇分享的《阿里巴巴集团基础设施的云化演进》实录。分享者吕奇，花名潇谦，阿里高级技术专家。10多年的老程序员，2014年加入阿里巴巴，是阿里巴巴大规模混部及容器化的项目负责人，4次参与双11大促，目前主要负责阿里巴巴集团内的规模化混部、拟虚化、存储与日志中心等。编者按：2018年11月30日-12月3日，第七届全球软件案例研究峰会在北京国家会议中心盛大开幕，现场解读2018年「壹佰案例榜单」。本文为阿里巴巴高级技术专家吕奇分享的《阿里巴巴集团基础设施的云化演进》案例实录。目录：云化的背景云化的业务基础云化的资源基础云化的控制引擎云化的未来展望01云化的背景双十一带来的挑战http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_2.jpeg淘宝双十一在近十年的时间，业务交易额增长360倍，交易峰值增长1200倍，从最初的400笔/秒，到今年的49.1万笔/秒，这是相当大的跨越。流量的高速增长也给阿里的整个基础设施带来了巨大的压力。http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_3.jpeg上图是双十一的一个典型流量表现，零点附近因为有限流，所以看起来是一条平线，零点瞬间飙升到最高，并维持在这条线上。前几个月，阿里开源了一款Sentinel产品，是服务治理限流降级工作的，就是它干的“好事”，虽然有了它能够流量进行限制，以最大程度保障系统不被洪流所压垮，但它也会对业务体验有很大的损失。于是我们想尽可能的减少这种限制，让大家购物更爽快一些，但这其中遇到了诸多难题，其中包括资源有限的问题。阿里不仅是只有电商，还包括金融、物流、视频、票务等等，要支撑的基础设施需要的资源是非常庞大的。成本是最大的挑战巨大的成本压力给我们带来了挑战。如何用有限的成本最大化的提升用户体验和集群的吞吐能力，用合理的代价解决峰值？如何持续降低单笔交易成本以提升峰值能力，为用户提供“丝般润滑”的浏览和购物体验？思路—通过云的弹性我们认为利用云的弹性可以极大缓解短时间使用资源的成本压力。http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_4.jpeg上图截取了几个月中交易集群的峰值线，最高的峰值线是双十一产生的，第二根是双十二的峰值线，我们发现双11只有一天，过后资源利用率不高，隔年会形成较长时间的低效运行。因此，我们想到通过公有云的弹性能力来对这一部分的资源进行削峰填谷。大促开始时，借用云，当大促结束后，把过剩的资源还给云。思路—和离线混部http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_5.jpeg由于在线业务需要做容灾，例如建立多个集群等，容量一般都是冗余比较大的，平时电商或者在线服务，CPU利用率在10%左右，除了双十一或者其它大促之外，流量更多是集中在白天。目前，进入数据时代的整个离线业务或是大数据计算的增长规模远远快过在线业务。但离线业务资源十分紧缺且资源利用率非常高。于是，我们考虑平时把一部分的计算任务放到在线这边，就可以极大提高资源利用率；而双十一时，让离线短暂的降级，便可以借用到大量的资源进行消峰。云化演进http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_6.jpeg云化就是让基础设施能够像云一样具体极高的资源使用弹性能力。思路上主要是上云和自身云化建设这两部分。达到的成果http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_7.jpeg我们很多年前就开始做这件事情，这些年下来主要的成果包括：双十一每万笔交易每年以50%的成本下降；核心的混部集群日均利用率可以达到45%以上，高峰期可以维持在60%-70%。阿里的业务技术演进http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_8.jpeg在1.0-2.0时代，阿里是从PHP时代迁移到Java的时代，主要面向的是真正的企业级生产，当它达到了一定规模后，我们开始做了2.0向3.0时代的升级，主要是单体应用向大型分布式架构的演进。那个时候比较重要的开源项目Double，就是代表产物。在飞速发展下，我们现在面临的端口是3.0向4.0时代的演进，它主要是从单IDC架构向多IDC架构的云化架构的演进，解决的是成本稳定的问题，它的体量非常大，线上需要很大规模的资源，如何做好这方面的协同，是我们研究的一个方向。02云化的业务基础云化的业务基础—异地多活http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_9.jpeg多单元化或者云上的方法叫多region化，我们要将其业务部署在多个集群中，但这个工作并不简单，其中存在很多内在关系，我主要从三个方面来叙述为何做这件事情。第一，我们的规模变得极大。例如我们内部一个容器规模在8核16G，在外部大规格的容器下，一个应用可能会达到1.4万-1.5万，甚至是更高的规模体量。这么大的体量如果放在一个集群规模下，是非常难以管理，并且所有支撑的基础组件，如调度系统、中间件都会出现瓶颈。第二，容灾。任何程序都有可能出问题，但是如何最大程度的在发生线上故障的时候，让损失降到最低呢？最简单的做法就是不要把鸡蛋放到一个篮子里，所以我们做了多单元，当一个单元出问题的时候，就把整个单元下掉，而流量切到其它的单元上。第三，上云。此外，我们要用云上的资源，而且要用得比较迅速，这时候就需要有一个能力很快把业务完整的搬到云上，用完后再快速的下掉，也就是业界常说的混合云能力，而这个技术就是基础。异地多活的业务架构http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_10.jpeg上图是典型的交易单元异地多活的架构。这里面包含普通单元以及中心单元两部分。通过我们的规模化运维平台，可以做到一键建站，一天内就可以去异地搭建一个新的淘宝、天猫等。以交易单元为例，现在交易的普通单元，主要处理的一个数据是买家维度。因为卖家的数量在双十一当天不会突然增加，所以简单来讲，从业务划分、流量切分，主要也是按照买家的ID做一个哈希，然后切分。因为每一个单元的集群能力不一样，流量不一样，所以这里面还有很多的策略。普通单元主要处理的是买家维度，但商品及库存是需要统一处理的，举些简单的例子，如库存扣减我们目前也是统一到中心单元中进行扣除来防止超卖的情况；并且卖家维度也是需要一个集群来承担，而中心单元就是承担了这样的责任。另外中心单元也承担着所有单元交易数据同步的能力，中心单元包涵了所有的数据。当某个单元出现问题的时候，流量就会先切到中心单元，等单元数据同步完成之后，再切到其余单元。2013年的时候，杭州做了两个同城单元的验证；2014年的时候，我们在上海和杭州之间做了两个单元；2015年的时候，我们建了4个单元，另外一个单元就是在千里之外的地方。2018年双十一有7个单元，大家的距离就更远了。做单元化架构，并不是单元越多越好，这其中是有成本问题的，大家可以看到对于普通单元，也会存在一份全量的库存，卖家等的数据，单元数越多，冗余也越多，同心同步压力也会随之增大。异地多活的技术架构http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_11.jpeg异地多活的技术架构，在外部流量过来的时候会有一个统一接入层，这一层会按照用户ID标识来进行流量分流。其实我们做的很重要的一件事情就是单元的自闭性。单元自闭型顾名思义就是一次调用，流量进入到一个单元后，我们希望把所有的服务调用都在这一个单元内处理掉，但这并不完全能做到，有业服务还是需要跨到中心单元调用的，所以第一个问题就是路由的一致性。第二个问题是数据延时，跨城异地多活必然会有延时，网络延时来回就几十毫秒过去了，但这其中涉及到很多的数据同步。比如中间件的消息同步问题，都可能会产生数据变更不及时的问题，严重了可能引发资损。最后一个问题是数据正确性问题，很多全量数据在数据同步的时候，会发生数据冗余，一旦有数据冗余，数据在便会不一致。我们以前也有一些相关的内部产品BCP，是专门做数据校验的。网络虚拟化http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_12.jpeg多单元的架构后，我们有能力把业务搬上云了，但是网络上如何来互通呢？我们用网络虚拟化来解决数据通信以及隔离的问题。阿里的绝大部分应用都是跑在Pouch容器上的，Pouch相关的技术也已经开源，而所有容器都是跑在这个层虚拟网络上的，这样既解决了网络互通问题，也解决了网络间的隔离性问题。初步的混合云架构http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_13.jpeg2015年我们完成了混合云架构，当本地保有云无法支撑时，我们就快速在公有云上扩建新的单元，当流量过去后，再还资源给公有云。我们在集团内部保有云部分，在线服务调度是Pouch，还有一部分是离线计算任务，目前还是用物理机的模式。另外一部分是公有云的，我们采用的是Pouch On Ecs的方案，打通云上云下的整个运维体系。对于业务方来说，1.5万个容器，又分7个单元，公有云，保有云运维模式都不相同的话，业务方式肯定要崩溃，所以我们实际上是做了一体化的处理。03云化的资源基础云化的资源标准—PouchContainer容器http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_14.jpeg上图我们真正建立了组部的混合云Pouch，Pouch是云化资源的标准，是云化资源的基础，如果不打通，整个运维复杂性会非常大，在演过之初我们就开始极力推行容器化。PouchContainer容器2011年就开始建设了，2017年的时候，PouchContainer已经开源出来，并达到了百万容器的规模。2011年，我们基于LXC开始做的时候，只考虑了Runtime，那个时候觉得物理机比较大，在物理机上部很多应用会比较麻烦，而用虚拟机的模式，overhead又比较高。我们就想到了用容器来解决，当时阿里主要的语言是Java，Java语言在运维上是有一些标准的，所以我们没有按照容器即服务的方式建立这个标准。但是这两年阿里也收购了很多公司，各种语言都会进入到整个的研发体系中，运维复杂度就大大提升了，效率瓶项非常明显。在Docker兴起之后，2015开始做Docker的兼容，把Docker好的部分兼容进来，形成了我们的PouchContainer，大家知道Docker里最重要的一个组件是镜像，但镜像有一个很大的问题就是比代码包的模式要大得多，分发的速度也就慢下来了，而且对于镜像源的压力也是一个大问题。我们一个应用可能会大到1.5万余个容器，如果它的镜像是在同一个源上，这个源马上就会被打挂，再大的带宽都不够，于是我们采用了开源项目Dragonfly，它也是刚刚进入CNCF项目，通过P2P网络来解决这个问题。让资源标准化—Pouch的演进http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_15.jpeg对于大公司来说，容器化最大的阻百碍是历史包袱。我们2011年开始做了T4容器，那个时候是基于LXC做的，但当时为了能够把物理机很好的迁移到T4上，我们做了兼容。T4上有独立的IP，能够让ssh登陆进去，可以跑多进程，有SystemD，甚至我们做了可见性的隔离，对于用户来说使用容器还是虚拟机，体验是一致的。这样的话，我们的升级可以在下层做掉，而对用户来说付出的成本是比较小的，我们把这个称之为富容器技术。04云化的控制引擎云化的管理引擎—统一调度http://08imgmini.eastday.com/mobile/20190326/20190326160110_685e6041f728f1d1174e087ed8efbaed_16.jpeg只有把容器管理好，整个效率才会高，整个云化才能有更好的效率。于是我们做了统一调度，内部我们在线服务资源调度器称之为Sigma，离线的计算任务资源调度器称为FUXI，FUXI是我们飞天架构体系当中非常重要的一环。此外，又通过0层打通两个调度器，提供一个统一的资源视图和管理器。
页:
[1]