根据这个流程，如果需要扩容一个应用实例，保守估计也需要 20 分钟以上，其中购买、系统初始化、应用部署都需要占用大量的时间。假设系统流量突增，需要在 2 分钟之内紧急扩容，这个方案就无用武之地了。
在应用生命周期管理以及服务治理方面， Kubernetes 提供了比较完善的实现机制，通过构建 Deployment 资源，配合 proStop 和 postStart 脚本，能比较方便的实现滚动发布以及应用的优雅上下线。
当然是可以的。SAE 提供容器镜像部署方式，这就代表着不管采用哪种编程语言，只要最终的应用能够发布成容器镜像，就可以部署在 SAE 上。
目前还能看到双中心的形式，两个中心都是全量数据，但双跟多还是有很大差距的，这里其实主要受限于数据同步能力，数据能够在3个及以上中心间进行双向同步，才是解决真正**多活的核心技术所在。
再谈谈为什么要做多中心容灾，以我所在的CDN&视频云团队为例，首先是海外业务的需要，为了能够让海外用户就近访问我们的服务，我们需要提供一个海外中心。但大多数业务还都是以国内为主的，所以国内要建双中心，防止核心库挂掉整个管控就都挂掉了。
同时海外的环境比较复杂，一旦海外中心挂掉了，还可以用国内中心顶上。国内的双中心还有个非常大的好处是可以通过一些路由策略，分散单中心系统的压力。这种三个中心且跨海外的场景，应该是目前**多活最难实现的了。
每一种分配算法都有各自的适用场景，需要根据业务需求选择合适的分配算法。主要需要考虑几个因素：
Id类型是int64还是int32。
业务容量以及并发量需求。
是否需要与JavaScript交互。
前面两种其实就是为了最终一致性做铺垫，因为数据同步是牺牲了一部分实时的性能，所以我们需要做数据分区，做中心封闭，这样才能保证用户请求的及时响应和数据的实时准确性。
我们的数据同步组件hera-dts已在BU内部进行使用，数据同步的逻辑还是比较复杂的，尤其是实现双向同步，其中涉及到断点续传、Failover、防丢数据、防消息重发、双向同步中防循环复制等非常多的细节问题。我们的同步组件也是经历了一段时间的优化才达到稳定的版本。
从经济学的角度来讲，云计算是 IT 产业发展的必然阶段。互联网和移动互联网时代的到来，加速了企业的数字化转型。云计算可以提供时刻在线的服务能力，并满足日益增长不断变化的计算需求。此外，云计算将 IT 服务的固定成本投入转化成为了可变成本，极大降低了创新成本。在咖啡馆中，随处可见创业的青年人围坐在一起构画未来，是互联网和云计算让梦想变得触手可及。
