演讲嘉宾简介：

蒋江伟(花名:小邪)，阿里巴巴集团副总裁、云智能基础产品事业部负责人。

以下内容根据演讲视频以及PPT整理而成。 本次分享主要围绕以下四个方面：

一、上云的核心
二、资源使用方式演进
三、稳定性演进
四、探讨与总结

直播回看

PPT下载

一、 上云的核心

1.目的

电商与云架构的演进方式和思路一致，围绕两个目的。第一，研发角度希望使系统的研发方式变得像一台服务器一样，例如客户访问、交易、商品、用户等系统，增加一台服务器，只需要把服务器添加上去，配置好IP的址就可以直接上线，获得一台服务器的计算能力。就运维角度而言，几十万台服务器的管理方式希望与一台服务器一样。因此研发角度和运维角度的本质都是希望通过研发的不断演进使若干服务器像一台服务器一样使用并管理。

2.当上云成为必然趋势，开发者关心什么

当前“上云”已成为必然趋势，“上云”的核心分为以下三点。
弹性：当开发者需要资源时能够即刻扩容。由于应用系统架构非常复杂，涉及成百上千个系统。希望当每一个应用系统遇到弹性问题时都能很快扩缩容。
稳定性：稳定性经历了几个阶段。首先，过去20年，稳定性是以硬件的稳定性来驱动的。例如一些小型机通过硬件的冗余、容灾实现计算资源的稳定。进入互联网时代之后更多是通过架构的方式使系统更加稳定。但很多公司不具备通过架构保障稳定性的能力，需要直接购买物理资源，希望系统更加稳定。因此云演进到使用廉价PC，可以保证资源相对更加稳定。
可管理性：各种公司提供各种各样的应用系统，在云上为更多客户服务。那么云端应用、系统的管理能否够做到和手机管理APP一样方便，能否对不同的公司开发的应用系统、运维系统简单的进行管理和运维？

二、 资源使用方式演进

1.阿里巴巴早期资源管理模式痛点

资源效率相对低，人工效率相对低：资源预算往往无法准确评估。特别是在业务高速发展时，可能突然有一块业务超出了预期，例如广告业务的增长，此时需要的是中间件的资源。如果资源预算准确，运维人员或资源供应人员将根据预算来提供资源。但资源预算周期很长，以周为单位。当资源预算不充分时，需要增加资源。增加资源需要进行评估、层层审批、说明占用资源目的等流程，对于工程师而言十分繁琐。

资源预测不准确是常态，并且是非常正常的。资源预测不准导致购买资源、使用资源过程中出现了各种工程师需要关注的问题。事实上，不同的部门或应用之间的资源使用率非常低。例如消息中间件因为某一块业务对消息使用的突然增长导致资源不够。而此时其它系统有很多资源，系统的load负载非常低，此时能否使用其它系统的资源就是一个更复杂的问题。没有统一的资源调度能力时，各业务部门管理使用自己的资源，在线的很多系统资源占用并不高，而某个部门由于担心资源无法回收，借调资源流程复杂等原因，不愿意对其它部门释放资源。

2.架构优化提升资源使用效率

全站容器化和统一调度：统一资源调度的前提是全站容器化。希望不同的应用、系统、中间件、缓存等都能够跑在容器里面，就可以进行统一的资源调度。合并资源池后，通过资源池分配以及调度所有资源。全站容器化与资源池合并，进行全局资源统一调度，非常好的解决了不同业务单元之间资源共享的问题，提高了资源利用率与库存利用率。不同业务单元（例如交易业务与搜索业务，跨行业业务）的峰值及峰值时刻不同，因此需要通过资源池合并来充分使用资源。其优势在于统一调度资源的效果远远好于一个业务单元自身通过系统、机器、代码优化等充分使用资源的效果。
运维标准化：统一资源调度节省运维成本，提高了交付效率和运行稳定性。由于资源调度的技术方式是一致的，统一资源调度中投入的研发或运维不仅使调度产品变得更加容易使用更加产品化。同时需要投入的人力资源也更少。目前容器化和统一资源调度已经渐渐成为行业发展演进的趋势。

混部资源池提升资源使用率至40%：不同的系统在不同时刻的峰值不同。例如阿里巴巴双11活动时峰值非常高，日常峰值与双11峰值可能相差30倍。现在由于阿里云的存在，双11处理变得非常简单。然而在过去不理想的状态下，准备着双11的资源量，而平时只需要1/30的资源，资源浪费非常严重。从技术演进的角度而言，可以将在线数据与离线数据进行混部。离线数据基本上是在在线数据产生之后进行离线计算。在线业务的峰值时间与离线业务的不同，并且离线业务可以接受部分有损，即可以接受报表生成时间稍延后（而非数据准确性有损）。而在线业务不能接受部分有损，比如用户下单时需要实时反馈，而不能在下单五分钟之后显示购买是否成功。当前混部资源是发展的技术趋势，即把离线业务部署到在线，在线业务部署到离线。在全站容器化统一资源调度的情况下，在双11活动峰值很高时，将在线业务调度到离线，使用离线资源补充在线资源，通过离线资源来谈在线业务，就可以大幅度降低当天的资源消耗。平时也可以将离线资源部署到在线业务上，得到了非常好的收益。
混部后资源使用效率从10%+提升到了40%，有效降低了企业在硬件资源方面的投入成本。

3.云计算

产品化解决方案：容器化、统一调度、混部等都是架构优化方案。要让离线跑到在线，在线跑到离线，仍然涉及很多需要工程师解决的问题。而云需要的是产品化、商品化的解决方案，实现资源即买即用。使工程师或用户不需要复杂架构即可实现资源使用效率和人工效率的显著提升。容器化、全局资源调度、混部等是互联网公司演进的基本逻辑，可以大幅度提升能力效率与资源效率，再据此进行产品化演进。例如当前阿里云的一些产品性能较好，稳定性较强。是由于阿里云背后有丰富的业务场景的锤炼，例如双11、业务复杂度问题等，都使产品成熟度更高。

全站云化降低电商成本：首先，大家需要注意的点是，面向云的研发模式与面向互联网的研发模式存在异同。相同点是目的都是为了像一台服务器一样简单的管理云端计算资源、研发系统架构。不同之处在于其资源池大小。容器化、统一调度、混部等架构优化方案的确可以降低电商成本。使用产品化方案云计算电商成本可以更低。下图为模拟混部与云计算在降低电商成本方面的对比，橙色部分表示跑在云上的方案，蓝色部分为混部方案使用。任何一项业务都有峰值、低谷。可见非云的混部方案利用自己持有的资源，不利用云资源，除峰值以外的日常时期占用过多资源，水位跑不满。以双11为例，峰值时期混部方案在跑满的情况下资源仍然不够，需要额外筹备或购买云资源。云计算方案可以弹性释放多余资源，因此日常以及双11峰值状态下都是跑满的。架构方案在混部、全局调度等情况下的年成本为1475单位，并且技术相对复杂，存在业务降级，需要研发人员的持续关注。而云化方案成本仅需要848单位，同时技术相对简单，业务无降级，人力资源的投入将更低。

云化为数据库应用带来很好收益：数据库的预算比较复杂。流量、并发量大时需要做分库分表，最终通过Hash方式对某一个id进行Hash。数据库一般每三年做一次预算，做一次资源储备，因此数据库资源浪费十分严重。该问题的核心是存储、计算未分离，即使计算量不高时也占用大量的计算资源。PolarDB X是阿里云自研的一款优性能产品。从MySQL分库分表到PolarDB X存储、计算分离的演进是典型的数据库云化过程。PolarDB X使用分布式存储，其优势是可以弹性释放多余计算资源，也可以弹性收回资源。阿里云上有三个基座：神龙解决计算方面问题，盘古解决存储部分问题，洛神解决网络问题。盘古早期就支持了云上和集团的各种业务，实现了计算与存储的分离，按需申请存储资源，产生了良好收益。盘古云化后成为了商品，PolarDB 和PolarDB X都可以直接使用。阿里云数据库的性能、运维等方面优势明显，直接基于阿里云的数据库进行研发等操作可以大幅度降低成本。

云计算规模化带来新的玩法——抢占式实例：以抢占式实例为例。抢占式实例的SLA不太高，价格十分低廉。抢占式实例并非阿里云原创，在AWS上已经是一套非常成熟的机制，并且在很多公司得到良好使用。下图为某移动广告及数据分析公司使用抢占式实例，成本得以大幅度下降。服务器切割后存在一些碎片资源、库存资源等，将其作为抢占式实例进行收买。抢占式实例的SLA不能保证，当其它客户需要完整的一块资源时，可能恰好包含某一块碎片资源，该实例就可能会被释放，但是回收前5分钟会通知客户。当然如果客户研发能力较强，可以通过PASS平台建立自己的平台，利用大量碎片资源进行调度，可以在保证SLA的情况下使成本尽量更低。在研发能力强的情况下，比如阿里云，使用抢占式实例只需要使用正常计算实例的20%左右，就可以得到解决同样问题的计算能力。

高效使用资源案例：如下图所示，某些在线旅游网站利用业务峰值、时间进行弹性付费；某些媒体公司利用热点事件快速进行弹性操作；某些渲染公司使用抢占式实例、经济型实例等降低成本，提高渲染效率。下图为过去数据，目前效果数据应该更加优秀。

面向云的研发与过去不同。从前的资源池可以视为小池塘，而面向云的资源池如同大海。虽然看似云端资源有些浪费，但是整体而言更有优势。下图所示为某O2O公司上云后资源使用效率较线下效率显著提升。该公司业务峰值在午餐、晚餐时间，一次性服务器采购成本高。该公司面向云利用全局统一资源调度、容器化、秒级弹性实例等操作解决了日峰值问题，节省了成本，提高了服务能力。

三、 稳定性演进

稳定性是每一家公司都十分关注的性能，稳定性直接关系到产品优劣、客户满意度，非常重要。稳定性的演进过程可大致分为以下三阶段。

1.早期IT时代

商用软、硬件厂商提供稳定性：用户架构简单，成本高。主要使用主机、小型机等方式保障稳定性。过去以现在做架构的方式在硬件层面做了很多与稳定性相关的操作，相应的其成本比较高。例如通过冗余的方式，使用两块绑卡、更多内存，在一条链路失效时切换另一条等方式。

2.互联网时代

架构优化提高稳定性：技术复杂，成本低。使用廉价PC Server不如小型机稳定。由于内存、主板、CPU、内核等各种原因，使用PC存在万分之三的服务器宕机率，但相同计算密度下价格非常低廉。因此需要通过架构优化提升稳定性。当一台服务器IP不通时可直接将其从集群中剔除，当整个集群存在问题时将业务切换到另一个集群上。例如阿里巴巴电商业务，甚至当某的的服务器不可用时可以切换到另一的的服务器上工作，架构非常灵活且高可用，拥有强大的调度、容错容灾能力。

高可用架构-容量能力：三八女王节活动需要做容量确定，确定需要多少笔交易能力。对每一个应用都需要进行容量规划、确定其所需计算资源，并进行全链路压测。
高可用架构-应用治理：需要了解应用之间的依赖关系。通过应用间的依赖关系可以进行链路跟踪、故障演练、监控、判断缓存是否失效等多种操作。
高可用架构-运行管控：例如容量确定并不一定能够满足所有容量能力，需要进行限流降级。例如客户需求为峰值100笔交易能力，而业务方认为该数值过高，只提供80笔交易的能力。在峰值时期对20%的交易进行限流，其它时间80%的交易能力足够使用。那么在峰值的几分钟时间进行一定限流，既不影响大部分正常时间的交易，又能节省20%的资源储备，是十分合适的。另外可以实现开关预案、监控报警等功能。
高可用架构-容错容灾：包括同减双活、异的多活、流量调度等能力。

3.云计算产品化

云计算通过软硬件结合提供很高的单点稳定性：用户架构简单，成本低。不计成本价格情况下，云的理想模式是出售小型机、同时拥有互联网架构的产品与能力，在单机稳定的同时架构能力也非常强。云上客户有大有小，技术能力参差不齐，但是对云产品、对服务器的要求同样严格。阿里云目前提供的SLA指标是全球最高指标，为其投入了大量资源。阿里云希望单机稳定性、可用性都可以达到非常高的标准，为客户提供比物理机更高的稳定性。云服务器的生命周期约3年，不如小型机生命周期长，云在硬件、在服务器中实现高可用性就成本而言并不划算。并且云是使用廉价硬件实现高稳定性，抬高物理资源成本并不符合云化趋势。因此客观而言，云计算达不到小型机的稳定程度。
云计算提高稳定性的方法如下图所示。通过商品化方式提供单点稳定性和分布式全栈化的产品和解决方案。例如硬件系统监测+AI故障预测，可以预测磁盘、主板等损坏的时间、故障率、故障诱发原因等指标，提前预警以便迁移应对。云上可以进行热迁移，在预测出故障的情况下及时迁移计算实例，消除故障于无形，宕机率降低到原来的1/5。另外高可用全网部署能力可以消除硬件故障及对业务的单点威胁。例如通过分散资源部署到不同批次，不同位置。实现上述能力的前提是需要有一定的规模，因此业务规模越大，方法越有效，稳定性越高。

全栈稳定性解决方案及产品：利用互联网沉淀的一些能力，利用阿里巴巴在金融、电商、物流等方面沉淀的能力，输出了一些高可用性产品。其中PTS是一款全链路压测工具，在架构互联网化的前提下可以发起大规模的在线业务全链路压测，高仿真线上峰值流量。PTS能够精准判断支持目标的QPS、TPS所需的资源，判断并均衡系统资源。

四、探讨与总结

1.容器的最佳载体探讨

物理机or虚拟机？容器是当前发展趋势。许多公司基于物理机做容器服务。客观而言，通过虚拟机对容器进行多次虚拟化并不好，基于物理机做容器服务是最好的。但是基于物理机做容器服务就失去了云的优势。云有五大优势。第一是弹性能力强，可以大幅度降低成本，提升可用性。第二是供应链效率高，不使用云，就不能通过鼠标的简单操作建立计算实例，而要进行诸多复杂操作流程。第三是财务效率高，不使用云时是一笔持有三年、四年的资产，而云上购买服务器后永久拥有。第四是稳定性好，云服务由专业公司提供稳定性，比客户自己保障稳定性更强。第五是云上产品丰富度高，并且不断推陈出新。其中包括阿里云的产品，也包括其它合作伙伴推出的产品，客户自己研发的东西也可以产品化、服务化，提供给云上其它客户。因此云上生态更加繁荣。
神龙子系统：其主服务器为第三代虚拟化技术，为容器服务而生。第一代虚拟化技术以VMware为典型代表，第二代以Xen与KVM为代表。第三代虚拟化技术即软硬件结合，弥补前两代的缺陷，以硬件方式进行虚拟化，虚拟化开销几乎为零，成本大幅度降低。
如果客户希望拥有更强的管控能力，可以在运维管控方面投入更多资金、人力，那么可以采用神龙子系统做容器服务。当然也可以使用云虚拟组建或其它服务器。

2.像管理手机APP一样管理云端应用

阿里巴巴呼吁通过标准化简化云端应用的管理。否则不同公司提供的服务、软件、应用系统的管理方式不尽相同，涉及大量研发、测试、生产环境，专有云、公共云、IoT环境，流程复杂，管理困难。而每一个手机用户都可以便捷的管理手机APP，其核心就是标准化，例如安卓系统、华为系统等。

3.Open Application Model

阿里云联合Microsoft Azure发布了OAM（开发应用模型），是全球首个云原生应用标准定义与架构模型。OAM在开发人员层定义应用的组件、依赖以及架构，在运维人员层定义应用的运维配置和运行时参数，在平台层执行OAM应用描述。使OAM可以一键安装、多处运行，使用标准化方式透出平台的基础能力与特性。只要符合OAM标准，不论在阿里云、其它云还是在其它个人搭建的KPS环境都可以进行更加方便的管理。

4.总结

云计算创新：基于云架构，开发者在研发与运维模式上不断创新。专注云上资源的使用，云厂商提供资源和灵活使用资源的工具。充分利用云计算解决应用稳定性问题。通过OAM，云上应用管理和手机APP管理一样简单。
云计算挑战：第一，稳定性超过小型机，同时保证价格低廉。第二，IDC建设更绿色节能。第三，可信科技创新持续稳步提升。第四，从Run on Cloud到Develop on Cloud。
云未来：随着计算机互联网化，计算机愈加影响到人类生活的方方面面，带来了巨大价值。云计算与之相似，云资源、云特性将会带来一种新的研发模式。相信随着云的快速发展，云将会带来更加深切的变化。今天云的关注点还在于资源、成本、运维、弹性、效率、稳定性等角度，未来云将会更加深入的影响到应用、商业模式，为社会带来更大的价值。