淘宝双11十年来，商家交易量增长了360倍，交易额峰值增长了1200倍。流量的高速增长也给阿里整个基础设施带来了巨大的压力。图片来自Pexels。本文是阿里资深技术专家陆奇分享的《阿里巴巴集团基础设施的云化演进》案例记录。将分以下几个部分进行分享：云化背景云化业务基础云化资源基础云化控制引擎云化云化背景及双11带来的挑战过去十年淘宝双11期间，业务交易量增长了360倍，交易峰值增加了1200倍，从最初的每秒400笔交易到今年的49.1笔。每秒10,000笔交易，这是一个相当大的飞跃。流量的高速增长也给阿里整个基础设施带来了巨大的压力。上图是典型的双11流量表现，由于流量有限，零点附近的流量看起来像一条平线，零点瞬间飙升至顶峰，并保持在这条线上。阿里开源了一个Sentinel产品，用于服务治理、限流降级。这是一件“好事”。对业务体验也会有很大的损失。所以我们想尽可能的减少这个限制，让大家购物更方便，但是我们遇到了很多困难，包括资源有限的问题。阿里不仅仅是电商，还包括金融、物流、视频、票务等，基础设施配套需要的资源是巨大的。巨大的成本压力向我们提出了挑战。如何以有限的成本最大化用户体验和集群吞吐量，以合理的成本解决峰值？如何不断降低单笔交易成本，提高峰值容量，为用户提供“丝滑”的浏览和购物体验？思路一：通过云的弹性，我们认为利用云的弹性可以大大缓解短期使用资源的成本压力。上图截取了交易集群几个月的峰值线。第一个峰值线是双11产生的，第二个是双12的峰值线，我们发现双11只有一天，之后资源利用率不高。明年将形成较长时间的低效运行。因此，我们想到利用公有云的弹性能力，为这部分资源削峰填谷。大促开始时，借用云端，大促结束时，将多余的资源还给云端。思路二：线下混合部门需要为线上业务做容灾，比如建立多个集群等，容量一般比较大，通常是电商或者线上业务，CPU使用率在10%左右，除了双11或者其他大促除外，白天人流量比较集中。目前，整个线下业务或进入数据时代的大数据计算，其增长速度远远超过线上业务。但是，线下业务资源非常稀缺，资源利用率非常高。因此，我们认为将部分计算任务上线，可以大大提高资源利用率；而在双11期间，我们可以通过线下临时降级来借用大量资源进行调峰。云化演进云化是让基础设施像云一样聚集极高的资源使用弹性。在思路上，主要有两部分：上云和自建云。成果我们从多年前就开始做这件事，这些年的主要成果包括：双11每万笔交易的年度成本每年降低50%；核心混合集群日均利用率可达45%以上，高峰期可维持在60%-70%。阿里的业务技术在1.0-2.0时代进化，阿里从PHP时代迁移到Java时代，主要是做真正的企业级生产。当它达到一定规模后，我们开始从2.0升级到3.0时代，主要是从单体应用到大型分布式架构的演进。当时比较重要的开源项目Double就是代表产品。高速发展，我们现在面临的是从3.0到4.0的演进。主要是从单一IDC架构演进到多IDC架构的云化架构，解决了成本稳定性的问题。它的体量非常大，在线需要海量资源。如何做好这方面的协同工作是我们研究的一个方向。基于云的业务基础是异地多活多单元或者说云上的方式叫多Region。我们需要将它的业务部署在多个集群中，但是这个工作并不简单，内部关系很多。我主要从三个开始描述你为什么这样做。***，我们的规模已经变大了。比如我们内部容器的规模是8核16G。在外部大型容器下，一个应用可能达到14000-15000，甚至更高的规模。这么大的体量如果放在集群规模上，管理起来非常困难，所有支撑的基础组件，比如调度系统、中间件等都会出现瓶颈。第二，灾难恢复。任何程序都可能出错，但是当出现在线故障时如何将损失降到最低呢？最简单的方法就是不要把所有的鸡蛋都放在一个篮子里，所以我们做了Multi-unit，当一个单元出现问题时，整个单元掉线，流量切换到其他单元。第三，上云。另外，我们要用到云上的资源，而且要用得比较快。这时候，我们就需要有能力将业务快速完全上云，用完之后再快速下载，也就是业界常说的混合云能力，而这个技术就是基础。异地多活业务架构上图是一个典型的异地多活架构，用于交易单元。它包括两部分：公共单元和中央单元。通过我们的大型运维平台，您可以一键建站，一天之内就可以去异地建立新的淘宝、天猫等。以交易单元为例，现在交易的通用单元主要处理其中一个数据是买家维度。因为双11那天卖家的数量不会突然增加，所以简单来说，从业务划分和流量细分来说，主要是根据买家ID做一个hash，然后进行划分。因为每个单位的集群能力和流量不一样，所以这里有很多策略。通用单元主要处理买方维度，但货物和库存需要统一处理。举个简单的例子，比如库存扣，我们目前在中央单位扣，防止超卖。而卖家维度也需要一个集群来承担，中央单位承担了这样的职责。此外，中央单元还负责同步所有单元的交易数据的能力，中央单元包括所有数据。当某个单元出现问题时，流量会先切换到中心单元，待本单元数据同步完成后再切换到其他单元。2013年杭州对同城2家单位进行核查；2014年，我们在上海和杭州之间做了2个单元。2015年我们建了4台，另一台在千里之外。2018年双11有7家单位，大家之间的距离更远了。做一个单元化的结构，并不是单元越多越好，还有一个成本问题。可以看到对于普通的单位，也会有全量的库存，卖家的数据等等，单位越多越冗余。越多，同心同步压力就会相应增加。异地多活技术架构在异地多活技术架构中，外部流量进来时会有一个统一的接入层，该层会根据用户ID来划分流量。事实上，我们做的最重要的事情之一就是单位的自闭症。顾名思义，单位自闭是一种召唤。流量进入一个单元后，我们希望处理这个单元内的所有服务调用，但这并不完全可能。一些服务仍然需要通过中央单元调用。是的，所以第一个问题就是路由的一致性。第二个问题是数据延迟。跨城、异地活动必然会有延迟。网络延迟是几十毫秒，但这涉及到大量的数据同步。比如中间件的消息同步问题，可能会导致数据变化不及时的问题，严重的话可能会导致资金流失。最后一个问题是数据的正确性。当大量的全量数据被同步时，就会出现数据冗余。一旦存在数据冗余，数据就会不一致。我们以前有一些相关的内部产品BCP，专门用来做数据校验的。网络虚拟化的多单元架构之后，我们有能力把业务搬到云端，但是如何在网络上进行通信呢？我们使用网络虚拟化来解决数据通信和隔离的问题。阿里大部分应用运行在Pouch容器上，Pouch相关技术也已经开源，所有容器都运行在这一层虚拟网络上，既解决了网络互通问题，又解决了跨网问题沟通。隔离问题。最初的混合云架构我们在2015年完成了混合云架构，当本地云支撑不住的时候，我们在公有云上快速扩容新的单元，等流量过去了，再把资源还给公有云。我们把云部分保留在组内，在线服务调度是Pouch，另一部分是离线计算任务。目前，我们仍然使用物理机模型。另一部分是公有云。我们使用PouchOnEcs解决方案，将整个运维系统打通在云上和云下。业务方面，15000个集装箱分成7个单元。如果公有云和保留云的运维模型不一样，商业模式肯定会垮掉，所以我们其实做了一个整合的流程。云资源库PouchContainer容器在上图中，我们实际上已经建立了部门的混合云Pouch。Pouch是云资源的标准和基础。如果不连接，整个运维复杂度会非常大。我们从一开始就开始大力推动容器化。PouchContainer于2011年开始建设，2017年PouchContainer开源并达到百万容器规模。2011年，我们开始做基于LXC的时候，我们只考虑运行时。当时觉得物理机比较大，很多应用放在物理机上面会很麻烦，而使用虚拟机模型，Overhead比较高。我们想到了用容器来解决问题。当时阿里巴巴的主要语言是Java，Java语言在运维方面有一些标准，所以我们没有按照容器即服务的方式建立这个标准。但是阿里这两年也收购了很多公司，各种语言都会进入整个研发体系，这大大增加了运维的复杂度，效率瓶颈非常明显。Docker兴起后，我们在2015年开始做Docker的兼容，把Docker好的部分结合起来，形成我们的PouchContainer。我们都知道Docker中最重要的组件就是镜像，但是镜像有一个很大的问题，就是比代码包大很多，所以分发的速度会变慢，对镜像的压力图片来源也是个大问题。我们的一个应用程序可能有15,000多个容器那么大。如果它的图像在同一个源上，源会立即挂起，带宽不够用。所以我们采用了同样刚刚进入CNCF项目的开源项目Dragonfly，通过P2P网络来解决这个问题。Pouch的演变对于大公司来说，容器化的最大障碍是历史包袱。我们是2011年开始做T4容器的，当时是基于LXC的，但是那个时候为了更好的把物理机迁移到T4做兼容。T4上有一个独立的IP，可以SSH登录，可以运行多进程，有SystemD，甚至我们还实现了可见性隔离。对于用户来说，无论是使用容器还是虚拟机，体验都是一致的。这样我们的升级可以在lowerlayer做，对用户的成本比较小。我们称之为富容器技术。云化控制引擎统一调度只有容器管理好，整体效率才会高，整个云化系统才会有更好的效率。所以我们做了统一调度。在内部，我们的在线服务资源调度器叫Sigma，离线计算任务资源调度器叫FUXI。FUXI是我们飞天架构体系中非常重要的一部分。此外，两个调度器通过第0层连接，以提供统一的资源视图和管理器。Sigma：2011年开始，是以调度为中心的集群管理系统。最终状态的建筑设计；三层大脑协同联动管理。基于K8S与开源社区共同开发。FUXI：针对海量数据处理和大规模计算类型的复杂应用。提供数据驱动的多级流水线并行计算框架，在表达能力上兼容MapReduce、Map-Reduce-Merge、Cascading、FlumeJava等多种编程模式。高扩展性，支持10万级以上并行任务调度，可根据数据分布优化网络开销。自动检测故障和系统热点，重试失败任务，保证作业稳定可靠运行。什么是混合部署？集群混合，不同类型的任务调度到同一个物理资源上，通过调度、资源隔离等控制手段保证SLO，大大降低了成本。我们称这种技术为混合部署。线上线下混部：线上优先级高：坚如磐石，对延迟敏感，利用率低，无法重跑。离线优先级低：就像水和沙一样，对延迟不敏感，利用率高，可以重跑。低优先级牺牲：线上不忙时抢占下线，否则退回，甚至反馈。优先互补：这是混合部门和带来成本效益的两个前提条件。混合部门架构：混合部门始于2014年，2017年在阿里大规模铺开。线上服务生命周期长，定制化策略复杂，对延迟敏感；计算任务生命周期短、高并发、高吞吐，对时延不敏感。两者正好相辅相成。通过Sigma和FUXI，完成在线服务和计算任务的调度，超卖计算共享。通过资源配比的零级相互协调，进行混合部门决策，通过内核解决资源竞争和隔离问题。该架构非常灵活。第一层是共享状态调度，第二层调度是在第一层之上自定义的。混部日常效果如下：上图是2017年混部日常效果，2017年我们实现了整个集群45%的混部，10%左右的非混部，中间增加了30%。2018年我们做到了45%以上，峰值可以拉到60%-70%以上。混部必有牺牲。它肯定会对高优先级的业务产生影响。我们已经使影响小于5%。我们可以看到这两条线，一条是混合部门集群，一条是非混合部门集。其RT性能影响在5%以内。混合部门的核心技术混合部门的核心技术一方面是调度。通过资源剖析，在竞争前，将资源竞争的可能性降到最低。但竞争总会发生，因为调度是宏观数据。微观上，资源的使用其实是有局部竞争的，所以另一方面我们在内核上做了很多保证。在资源竞争极端的情况下，我们会优先保障高优先级的任务。它是被动的但是延迟很低，可以在毫秒级响应。基于统一QOS的调度系统：调度自己的SLO：在线、离线定义自己的SLO和对应的0级资源优先级映射。资源优先级定义：共同开发第0层资源优先级定义。资源测量和控制：统一度量作为第0层资源控制。无论资源使用策略如何，调度本身都必须能够转换为第0层的标准度量单位。对于日常的分时复用，我们很早就做了弹性容量托管，但是我们发现只有真正把资源混合在一起，才能放大资源的分时复用的价值，而这部分主要是节省了问题是内存资源瓶颈。大促分时复用上图是我们日常的状态。大促期间，我们会在1小时内直接切换到如下状态，直接把线上业务和流量放在上面，部署起来，形成1个大促状态。此次大促支持了12万笔交易。实时内存超卖其实是在混合部门。CPU不是最有竞争力的，因为CPU其实是一种可压缩的资源，是有弹性的，但是内存是没有弹性的。一旦内存不足，就会OOM。这两年，为了性能问题，大家用空间换取性能，把很多东西放在内存里。内存资源非常紧张，所以我们会根据实时内存使用情况来调整内存使用级别。我们称这种内存超卖技术。.在内存方面，还有一些更高级的研究方向，比如如何更好的管理Pagecache。存储计算分离存储计算分离是我们在做混合部署时遇到的第一个问题，因为大数据需要大量的计算资源和大磁盘，而在线应用需要小磁盘。以前我们都是在同一台物理机上，没办法调度，所以我们把计算和存储分离，把原来统一的资源拆分成计算节点和存储节点。这样可以更好地控制存储的性能和容量，将成本保持在最低水平。但是这种方法对网络的依赖性会比较大。内核隔离我们最终形成了一个完整的混合云系统。我们将所有服务混合部署在上层，下层既可以是线上独立集群，也可以是混合部署集群。也可以是独立的计算服务集群，甚至是ESC上的集群。公有云的这些集群形成了上图所示的架构体系，所有的资源层都可以连接起来形成混合云模型，共同支撑阿里巴巴。商业。当然，最终的目标是完全向公有云转型。云化的未来展望目前，我们的研究方向多而杂。文章上面提到了几个阶段：微服务主要解决人和服务之间的协作。最复杂的是服务之间的协作，也就是我们常说的服务治理。我们把云架构看成是人和资源的协调，最难的是资源和资源的协调，比如单元化、混合部署。我个人认为未来的一个方向是业务和资源的协同，即用户不再需要关注资源和运维。他们只需要以标准形式输入业务需求，系统就会自动按照最佳策略进行部署。.为此，您可以采用业界非常流行的Serverless模型。关键是打通业务和资源之间的标准。陆奇，昵称小倩，阿里资深技术专家。10余年资深程序员，2014年加入阿里巴巴，阿里巴巴大型混合部门及容器化项目负责人。他曾4次参加双11大促。系统化、存储和日志中心等。
