根据这个流程，如果需要扩容一个应用实例，保守估计也需要 20 分钟以上，其中购买、系统初始化、应用部署都需要占用大量的时间。假设系统流量突增，需要在 2 分钟之内紧急扩容，这个方案就无用武之地了。
Serverless 技术存在多种形态，最典型的一种是 FaaS（Function as a Service，函数即服务），比如阿里云的函数计算（Function Compute，FC）产品。在函数计算领域，一切计算资源的申请和调度都由具体的业务事件触发，当业务事件所对应的任务完成之后，计算资源会被立即释放。这样的方式真做到了计算资源的按需分配，能显著提升资源利用率，是 Serverless 技术的终极形态。
SAE 的极致弹性能力
除了手动的扩缩容指令，SAE 还支持 2 种自动弹性机制，可以对微服务应用进行灵活的水平扩展，更进一步的发挥云计算的弹性能力。
再谈谈为什么要做多中心容灾，以我所在的CDN&视频云团队为例，首先是海外业务的需要，为了能够让海外用户就近访问我们的服务，我们需要提供一个海外中心。但大多数业务还都是以国内为主的，所以国内要建双中心，防止核心库挂掉整个管控就都挂掉了。
比如int32的范围从-2147483648到2147483647，Id使用范围1,2100000000)，前两位表示region，则每个region支持100000000（一亿）个资源，即Id组成格式可以表示为[0-20。
即int32位可以支持20个单元，每个单元支持一亿个Id。
既然MNS无法保证强顺序，而我们做的是数据同步，只要能够保证最终一致性就可以了。2012年CAP理论提出者Eric Brewer撰文回顾CAP时也提到，C和A并不是完全互斥，建议大家使用CRDT来保障一致性。
既然MNS无法保证强顺序，而我们做的是数据同步，只要能够保证最终一致性就可以了。2012年CAP理论提出者Eric Brewer撰文回顾CAP时也提到，C和A并不是完全互斥，建议大家使用CRDT来保障一致性。
我们通过各种方式采集到的丰富数据，在清洗、结构化后进入统一的ODS数据基础层。
其主要功能包括：
-同步：结构化数据增量或全量同步到数据中台
-结构化：非结构化(日志)结构化处理并存储到数据中台
累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、数据清洗
此外，云计算是典型的平台型业务模式。随着规模的增长，会产生网络效应。提供为企业提供产品 / 服务的 ISV 与 SI，会更加青睐于那些拥有更多用户的云平台。而用户会更加倾向于能够提供丰富技术产品和服务支撑生态的云平台。随着云平台的成长，将对用户和生态产生更强的吸引力。
在无服务器计算中，应用逻辑被解耦为多个函数，每个函数可以通过事件驱动的方式触发执行。执行粒度进一步细化，可以进一步提升弹性的效率，此外还把应用部署从本地代码（如 x86 指令集）提升到了高级语言层面，这给成本优化带来了更多的空间（比如可以在 ARM 等低成本的计算资源上来运行 Python/NodeJS 脚本）。这推动了进一步的社会分工，云厂商可以通过规模化、集约化和技术创新实现计算成本的持续优化。
