在多中心的环境中，怎样解决业务在突发事件中高并发的问题？

所谓的突发事件，实际上有两个特点：

1. 不可预知
2. 对业务压力造成了极大的冲击

假设，我们的基础架构以及应用架构能够感知压力的持续性，并且能够根据一定的规则进行自动的扩展。我们的应用能够实现部署到发布的效率化和自动化。那么这个问题就可以解决掉。这里面有几个问题需要解决：

1. 业务压力的捕捉模型，涉及到一系列指标的获取，相信这个比较简单，只要有相应的监控数据。
2. 基础架构的弹性伸缩能力，我们既有的传统架构、无论是虚拟化还是物理机模式，都无法实现基础架构的弹性伸缩，因为应用从部署到发布的周期太长，验证环节太多。即使我们把部署发布等工作都做成自动化的python或者shell脚本，离我们的弹性架构还是很远。这就要求基础架构从传统的模式转向轻量性容器架构。
3. 应用的发布效率化和自动化，其实这个不仅仅是一个效率或者是自动化的简单过程，它是需要应用进行一系列的升级。包括应用的解耦、包括devops思想的推进、微服务的推进等。
4. 这一系列过程的集成化，包括数据的合理流向、任务的合理调度流程、资源的合理配置等。

在多中心或者多云环境下，资源能力的估算是一项重要管理任务，除了业务的软件架构需要符合分布式结构，具备快速部署的能力，剩余的就是可以调动的资源能力，当监控到突发业务负载，需要业务在多中心或者多云的空闲资源中按策略快速部署，以卸载业务负载，直到满足用户需求或者资源耗尽。其中策略的制定是根据业务特点来制定的，比如按地域的突发网络流量，可能选择不同的云中心来分布业务部署等等。

阿里之类 会大规模部署 设备 每年备战11.11 开发高并发队列
你要知道 阿里 支付宝 交易是内部做的 而银行卡交易和 信用卡交易是过银行的
11.11 考验的是 阿里和银行的接口 为啥阿里推荐使用支付宝和花呗
支付宝和花呗 内部能做好 ,反而是 银行接口无法承受
11.11 多次看到无法交易问题出在和银行的接口堵塞 而不是阿里这边的问题