业务连续性和成本思考

        业务连续性对一些面向用户、且感知明显的业务非常重要，比如游戏类、金融类、电商类、账号类等，短时间中断就可能引起大量投诉。

        为了应对机房火灾、机柜掉电、光纤挖断、交换机故障等事故，一般会进行架构的灾备设计，主要包括硬件层面(I层)和软件层面(S层和P层)。

        一般公有云上可以直接提供I层和S层的服务，因此，首先需要选一个可靠性高的公有云提供商。不同公有云提供商的服务目录价有一些差距但基本公开，可以通过招标选择一个可靠性满足几个9，成本又能接受的服务商。选择好公有云服务商后，成本主要取决于几个方面：

        数据副本数：主要是大数据类业务

        数据异地备份：主要是大数据类业务

        双活：一般要求单AZ资源可以独立支撑业务，这样的话，双AZ的资源量至少需要翻倍

        容灾：一般只保留主流程，提供有限服务，资源量取决于容灾设计时覆盖服务范围

这些只靠堆资源就可以做到，在研发资源或能力有限的情况下，是比较好的选择。需要注意一点就是一定要用容灾演练去实际验证方案是真正可以做到所设计的高可用目标。因为现实中网络环境复杂多变，业务依赖错综复杂，有时真的是想法很好，结果很糟。

        即便100%高可用的硬件，也可能因为一个bug导致整个系统的崩溃，因此P层的连续性设计也是非常重要的。之前遇到过因为日志打印过多，影响到磁盘IO，进而拖慢整个服务的事故；也有因为缓存击穿或是索引缺失引发慢查询堆积，造成数据库CPU跑满。总体上，P层发生异常的可能性是高于I层和S层的。

        I层和S层的冗余是为了应对物理硬件、网络层面的异常，P层的连续性主要是应对突发流量、恶意攻击和部分服务中断的异常。总之，需要深入业务，针对具体故障场景，设计出对应的应急预案。如何在系统异常时，通过手动或自动采取一些消减措施，如隔离、限流、熔断、降级等，这是真正考验团队技术能力的。