风险来源

海量用户

互联网应用几乎无差别地为全世界所有的用户提供服务，与服务于局域网用户的企业级应用相比，其用户量要大得多，由海量用户产生的数据量自然也会呈几何级增长。

与日常生活中的真实场景不同，在网站用户量超过应用负荷的阈值之前，互联网用户不会明显感受到由用户量增长所导致的服务质量下降。用户数一旦超过了网站应用所能够承载的阈值，比如 1000 万人同时购买，那么整个网站在处理不当的情况下便会完全失去响应，如果处理得严重不当，还会导致用户交易数据丢失，最坏的情况是部分用户付款之后却不能收到商品，且投诉无门、查无对账。互联网应用对于用户量的预估远远没有企业级应用那么准确，在业务发展迅速的情况下，用户量的增长是爆发性且没有上限的。

产品迅速迭代

随着业务模式的快速拓展，互联网应用功能推陈出新的速度也越来越快。在当今这个节奏如此快的时代，时间成本显得非常关键。敏捷地探知市场需求并将其实现，是互联网行业的立命之本。产品快速升级必然会推动开发、测试、交付甚至系统迅速迭代。

7×24 小时不间断服务

互联网应用是一个面向全球的服务应用，由于具有时区差异，因此应用必须保证全天随时可用。

各种意外情况，如光缆挖断、机房失火等，都可能对系统的可用性产生影响，每次宕机都会造成很大的损失。另外，如果系统设计得不够健壮，对其升级和维护时就要停止服务。频繁的系统升级同样会对系统可用性产生很大的影响，而互联网公司每天多次进行应用上线是很常见的行为，发布常态化已渐渐成为互联网行业的标准。

虽然随时随处可用的难度非常大，但互联网应用会尽量缩短宕机时间。通常使用 3~5 个 9（3 个 9 即 99.9%，4 个 9 即 99.99%，5 个 9 即 99.999%）作为衡量系统可用性的指标，表示系统在 1 年的运行过程中可以正常使用的时间与总运行时间的比值，下面分别计算 3 个 9、4 个 9、5 个 9 指标下的全年宕机时间，我们来感受一下它们的可靠性差异。

3 个 9：(1-99.9%)×365×24=8.76 小时 4 个 9：(1-99.99%)×365×24=0.876 小时=52.6 分钟 5 个 9：(1-99.999%)×365×24=0.0876 小时=5.26 分钟

在真实的运营环境下，系统可用性指标每提升 1 个 9 都是非常不容易的。

峰值挑战

不同类型的互联网公司有着不同的流量突增场景。比如，电商类公司的流量会在“双 11”这样的大型促销活动期间突增几倍、几十倍甚至上百倍；社交类公司的流量会在热点事件爆发时突增。

流量突增分为可预期型突增和不可预期型突增，像促销活动、有计划的热点事件（如美国总统大选、世界杯总决赛等）等引起的流量突增属于可预期的流量突增，可以通过提前扩容、预案演练等方式精心为这些流量突增准备应对方案。而意料之外的热点事件（如地震）往往事发突然，系统来不及准备应对措施，因此若系统本身的可用性、弹性等非功能需求十分成熟，便可以在某种程度上应对流量突增了。

业务组合复杂

很多互联网公司都是跨界巨头，我们知道，即使不跨界，在单一领域编织一个大规模的成型业务系统也并不简单。

以电商行业为例，电商系统在应用系统层面大致可划分为卖场、交易、订单、仓储、物流等主流程系统，搜索、推荐、社区、会员、客服、退换货等面向用户的前端系统，商品、价格、库存、配货、促销、供应链等面向后台员工的后端系统，以及广告、商家、支付、清算、财务、报表等面向合作伙伴的辅助系统，每个应用系统又会划分为很多子系统。