弹性

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

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

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

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

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

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

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

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

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

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

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