阿里巴巴的研发模式是如何演进的？

随着云计算的不断发展，很多开发者都对这一技术将为开发方式带来的变化充满兴趣，云计算解决的是从 CAPEX 到 OPEX 的转变问题。云可以带来哪些切实的好处？在云环境下应该怎么做应用架构？基于从传统架构到云架构的亲身经历，阿里巴巴合伙人、阿里云智能基础产品事业部总经理蒋江伟（小邪）阐述了企业由新架构和新研发模式带来的价值点。本文整理自正在召开的 QCon 上海 2019 蒋江伟（小邪）的演讲内容。

大家好，我是阿里巴巴合伙人、阿里云智能基础产品事业部总经理蒋江伟（小邪），本次分享的主题是“基于云架构的研发模式演进”，之前也有机会分享这个主题，但当时是作为电商的研发负责人，是站在开发者的角度思考问题。两年前，我加入了阿里云，现在是站在云计算的角度思考这个问题。

当上云成为确定性趋势，开发者应该关心哪些问题呢？站在我自己的角度来看这些问题，我在电商领域做了将近 9 年，在阿里云又干了 2 年时间，在这个过程中，我感受到最大的两点不同：一是资源的弹性，二是稳定性。

先说资源的弹性。在互联网时代，我们更多是通过顶层架构设计，如多集群部署和分布式架构的方式来实现出现资源相关问题时的快速切换，我们做了很多事情都是在让弹性变得更加简单，并通过混部计算任务来提高资源利用率。在云上做这些事情是不一样的，因为我们没有办法掌握客户的架构体系，更多的不是从架构的角度来做，而是通过产品和商品的角度来解决问题。

再说稳定性，过去二十年，我们通过硬件的方式不断提升冗余性，互联网时代通过分布式架构提升稳定性，云计算是非常不一样的，因为不知道用户是什么样的架构。

最后是可管理性，我们对应用的可管理性提出了一个畅想：云计算时代，应用的管理运维将更加标准化。

弹性

首先看弹性，先看一下我在阿里巴巴的经历，我在做中间件的时候，做了一些服务器的预算，当我们的业务不可预测，比如一些创新的业务或者业务突然爆发，预算很难完全满足需求，这时需要增加服务器，就需要重新做预算，这是非常痛苦的。假设我们有预算，设备上线也需要两周时间，虽然这已经是非常快的速度了，但作为工程师，我还是更希望有时间把性能做好，把功能做好，而不是参与资源生命周期管理。事实上，服务器的负载非常低，部门之间也不愿意把服务器资源让给其他部门，因为不知道将来用的时候还有没有。人力的效率问题也非常低，要关注服务器的整个流程，但这些问题在云时代又有着不同的表现，比如云计算时代，客户不需要自己解决网络维修等问题，而我们又是如何解决这些问题的呢？

阿里巴巴采用了全站容器化的方式来解决这个问题，各种服务、各种中间件都实现容器化。所有的业务都容器化之后，就可以打通资源池。当有一个业务需要扩容时，我从公共池子里提供资源给他。当他不需要这些资源时，可以释放回来。通过容器实现标准化，通过统一调度实现资源的使用申请和释放。但是，整个推进过程也是非常难的，这可以称为是一个 CTO 工程，自上而下推进全公司的容器化，包括数据库、中间件、缓存… 通过建设统一的资源池相对可以缓解这些问题。

容器化之后，如何整体提高资源的利用率呢？特别是在线和离线。因为阿里巴巴的业务是峰值驱动的业务，在双 11 和大促时，流量是非常高的，可以达到平时峰值的 30 倍，对计算有着更高需求，我们采用的方法是混部。双 11 时，可以把离线的资源让出来，把在线业务调度到离线服务器上，整个计算资源能够更好地使用。混部后，日均资源利用率从 10% 以内提高到 40%。如果不是一家大数据的公司，服务器的资源利用率肯定是低于 10% 的，如果高于这个数值，风险也相对增加，这还是需要通过技术的方式解决这个问题。

总结下来，全站容器化、统一调度和混部都是通过架构的方式来提升资源利用率，本质上就是云化的过程，产品化和商品化之后就是云计算。当商品化之后，资源池的规模扩大了很多，资源是即买即用的。

如果采用混部架构，电商日常的资源利用率是比较低的。双 11 的时候，大数据的业务要降级。如果采用云的话，不需要使用架构上对混部场景重构的方式，也不需要预留这些资源。双 11 的时候，直接使用云的资源，全部是容器化部署就好。

如下图，我们做了这样一个模型，日常（非大促时期）的资源使用，大数据占用了较多资源，可能换算下来是 350 天；双 11 的时候，资源大部分被电商占用，换算下来可能使用的是 15 天，通过下图可以看到云化后资源的使用成本进一步大幅下降。最重要的是，云化后不需要再关注复杂的混部架构，技术也相对简单。我觉得能在下层解决的问题绝对不会在上层解决，如果运营都可以感知到架构的变化，这不是很好的体验。

我们再看对数据的影响，过去做数据库预算，做好分库分表的规则，一般是做三年，三年之后数据库会达到一个什么样的使用量和访问量，这就存在很严重的资源浪费问题，因为在到达三年之前，所有的计算和存储资源并没有被很好的利用和使用。如今，通过将计算和存储分离，计算的节点是有弹性的，存储通过分布式的方式来实现，存储的节点也是可以扩容的，这样就很好地解决了资源浪费问题。

云计算规模化带来了新的玩法，这是我自己对电商的想法，电商大促时，计算资源不用单独购买服务器资源，直接利用云计算池子里碎片的计算资源就可以。我们的客户已经这么做了，充分利用阿里云的抢占式实例，抢占式实例的起售价格非常低，只有标准实例的十分之一，当然需要工程师在架构设计上做好准备，把实例可用性的不确定性变成计算的确定性。因为抢占式实例可能一个小时后被回收，但是至少有一个小时的使用时间。

在阿里云上已经有大量用户，使用云资源的方式上领先于电商。比如，充分利用弹性的能力，使用按量付费的实例。我们有一个客户，用几分钟的弹性资源使用时间完成了秒杀的过程。

下图所示是一些具体事例，我们也有一个外卖行业的客户，使用 ECS 是按小时使用的，可在业务低峰期停机不收费，高峰期启动执行业务计算。这样上云后整体的 IT 成本降低了 20%，人均维护服务器数量提升了 3 倍。

总结下来，阿里巴巴曾经是提前采购一些服务器应对大促，大促完成后给云计算。同时，我们也通过架构来提升资源效率和人力效率。之后，我们把这些工作产品化和商品化输出，云计算上面有大量的客户在用创新的方式在使用。

稳定性

接下来，我跟大家分享稳定性。过去二十年，大家都在使用硬件冗余或者通过单点技术突破来解决这样的问题，直到今天，依旧有很多企业在沿用这样的方式。我们的小型机非常稳定，但是通过硬件冗余的方法来做的。那么，互联网公司怎么解决稳定性问题呢？

互联网公司也是普遍采用了一种架构的方式来解决可靠性问题，就是分布式和集群的方式。同时，我们也通过框架、限流、流量预测来解决各种因为分布式问题带来的缺陷。比如双 11，我们通过压力测试模拟双 11 流量，通过架构优化让流量非常均衡。总结起来就是用大量的廉价服务器通过集群的方式解决单个节点不可靠的问题。阿里云上又不一样，因为我们不知道客户业务是什么样子的，客户认为云应该是可以保证数据稳定性和可靠性的，但这是需要购买相应服务才可以享受到的，但客户认为云就是需要具备这样的能力，所以我们今天更多采用的是软件和硬件结合的方式提高单点可靠性。

现在看来，这与过去二十年的目的是一样的，不过解决方法不一样。主要是云计算管理了海量服务器，基于历史数据，磁盘和主板故障时间是可以预测的。当出现故障或即将出现故障时，我们可以进行迁移，客户在这个过程中是没有感知的。就像我们做了支付业务，后面接了蚂蚁支付、微信支付和银联支付，如果其中一个支付出现问题可以切换到另外一个，用户是感觉不到的。云计算也是一样，单纯硬件损坏是没办法避免的，但是通过虚拟化，当一台硬件出现问题可以迅速切换到另一个，道理是一样的。其次，我们结合了互联网架构过去沉淀的一些经验和能力，比如压测的经验、微服务管理的经验、故障演练和诊断的能力，将这些能力进行商品化，企业不需要自己做复杂架构就可以拥有这些能力。

简单总结下来，早期，软件和硬件都提供了单点的稳定性。随着规模的扩张，互联网移动化的来临，越来越多的企业选择通过架构的方式提高稳定性。但是，并不是所有企业都具有这样的能力，云计算通过软硬件结合的方式解决单点稳定性，同时结合了互联网架构整体提高了可靠性和冗余性能力。

我们内部也有过探讨，容器用物理服务器承载是比较好的方式，用虚拟机就做了两层虚拟化。但是，采用物理服务器有些云计算核心的竞争力就没法获取了，一是弹性能力，二是云计算软硬件结合的高可靠性，硬件资源的快速迭代等。因此，阿里云也创新地提出了神龙这样一套架构，通过硬件 MoC 卡，把虚拟化卸载到 MoC 卡上面，性能得到显著提升。我认为，容器的最佳载体一定是类似于神龙这样架构的裸金属服务器。一方面可以获得容器的好处，另一方面也可以获得云计算方面的好处。

OAM 正式开源

最后，我们希望云上的应用管理像手机 APP 一样，手机 APP 肯定是标准化的。我们今天安装和部署通过容器和 k8s 肯定是标准化的，但是这个应用本身你怎么去配置它，你怎么去运维它，它非常不标准。我们希望能够定义这个事情，当然这个事情也刚刚开始。今天，我们阿里云联合了微软云一起发布开放应用模型 Open Application Model（OAM），项目主页：

https://openappmodel.io/

OAM 是一个专注于描述应用的标准规范。有了这个规范，应用描述就可以彻底与基础设施部署和管理应用的细节分开。这种关注点分离（Seperation of Conerns）的设计好处是非常明显的。举个例子，在实际生产环境中，无论是 Ingress、CNI 还是 Service Mesh，这些表面看起来一致的运维概念，在不同的 Kubernetes 集群中可谓千差万别。通过将应用定义与集群的运维能力分离，我们就可以让应用开发者更专注应用本身的价值点，而不是”应用部署在哪“这样的运维细节。

此外，关注点分离让平台架构师可以轻松地把平台运维能力封装成可被复用的组件，从而让应用开发者专注于将这些运维组件与代码进行集成，从而快速、轻松地构建可信赖的应用。OAM 的目标是让简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。

在这个模型里，开发人员负责定义应用组成、依赖与架构；应用运维人员负责定义应用运行时配置与运维需求。这是一个开源的项目，我们也希望开发者一起来参与这个项目并贡献源代码。

结束语

总结一下，我今天主要讲了三件事情：一是弹性的问题；二是稳定性的问题；三是阿里云与微软合作发布的 OAM，定义了一套应用管理的标准和协议，希望开发者能够像管理手机应用一样管理云上的应用。

最后，云计算其实也面临一些挑战，比如稳定性如何超过小型机、IDC 建设如何更加绿色节能、云计算如何更加值得信赖等。阿里云希望通过流程的方式、技术的方式，产品定义的方式推动云计算可信的发展，希望更多开发者能够真正基于云来做整个软件生命周期管理，从 Run on Cloud 发展到 Develop on Cloud。