1 什么是“云原生”
这不是亚马逊的错。2015年9月20日，星期日，Amazon Web Services（AWS，亚马逊公司旗下的云计算服务平台）经历了一次重大的宕机事故。随着越来越多的公司在AWS上运行自己的关键系统—甚至是为客户提供的核心服务，AWS宕机可能会导致后续一系统影响深远的事故。在这种情况下，Netflix、Airbnb、Nest、IMDb以及很多其他公司都经历了宕机，服务的客户受到影响，最终企业利益受到损失。AWS核心宕机持续了大约5小时（或者更长，取决于你如何计算），而受AWS影响的客户则花费了更长时间才将其系统从故障中恢复。
如果你是Nest公司，你向AWS付费是因为希望专注于为客户创造价值，而不用关心基础设施的问题。作为协议的一部分，AWS负责保证其系统的正常运行，从而让你的系统也能够正常运行。如果AWS宕机，那么你很容易把自己系统的宕机都归咎于亚马逊。
但是你错了，亚马逊不应该为你的宕机负责。
等等！不要把书扔到一边，请听我说完。我的话会直击问题的核心，并且解释了本书的写作初衷。
首先，让我澄清一件事情。我并不是说亚马逊和其他云供应商没有责任保证系统的正常运行，它们显然就是做这件事情的。如果供应商没有达到一定的服务水平，客户可以并且一定会找到替代的方案。云服务供应商通常会提供服务级别协议（SLA）的保证。例如，亚马逊可以为其大部分服务提供99.95%的正常运行时间保障。
我想指出的是，你在基础设施上运行的应用程序应该比基础设施本身更稳定。你会说，那怎么可能？朋友们，这正是本书要教给你们的。
让我们来快速回顾一下2015年9月20日的AWS宕机事件。Netflix是受网络中断影响的众多公司之一，它是美国最大的互联网网站之一，其访问流量占全部互联网带宽的36%。尽管Netflix宕机影响了很多人，但是该公司对于AWS事件是这么说的：
Netflix在受影响的地区确实经历了短暂的可用性问题，但我们避开了所有重大影响，因为Chaos Kong演习让我们为此类事件做好了准备。通过定期模拟区域性中断的试验，我们能够及早发现任何系统性缺陷并修复它们。当us-east-1变得不可用时，我们的系统足够强大，以至于可将流量转移到其他可用区域。[1]
Netflix很快就从AWS宕机事故中恢复过来，事故发生几分钟后就完全恢复了功能。Netflix仍然在AWS上运行，即使AWS还在宕机，它依然能够完全正常运行。
注意 Netflix如何能够恢复得如此之快？答案是冗余。
没有一个硬件可以保证100%的时间都是可用的，并且正如一直以来的实践经验表明，我们会在适当的地方增加冗余系统。AWS正是这样做的，并且将这些冗余能力提供给它的用户。
特别地，AWS会在多个区域提供服务。例如，在撰写本书时，其Elastic Compute Cloud platform（EC2）产品正在爱尔兰、法兰克福、伦敦、巴黎、斯德哥尔摩、东京、首尔、新加坡、孟买、悉尼、北京、宁夏、圣保罗、加拿大，以及美国的4个地方（弗吉尼亚州、加利福尼亚州、俄勒冈州和俄亥俄州）运行和提供服务。在每个区域内，服务被进一步划分为许多可用区（AZ），这些可用区被配置为相互之间的资源是隔离的。这种隔离机制限制了一个可用区失败而对另一个可用区服务造成的影响。
图1.1演示了3个区域，每个区域包含4个可用区。
图1.1 AWS将其服务划分为区域和可用区。区域对应地理地区，而可用区在单个区域内提供进一步的冗余和隔离
应用程序在可用区中运行，重点是，它可能在多个区域的多个可用区内运行。回想一下，之前我曾说过，冗余是系统正常运行的关键之一。
在图1.2中，我放置了一些图标来表示正在运行的应用程序。（我不清楚Netflix、IMDb或者Nest是如何部署它们的应用程序的，这里纯粹是假设，仅仅为了说明。）
图1.2 AWS上的应用程序可以部署到单个可用区中（例如，IMDb公司），也可以部署在单个区域的多个可用区中（例如，Nest公司），或者部署在多个可用区和多个区域中（例如，Netflix公司）。这样可提供各种不同的弹性能力
图1.3演示了一个单个区域故障，就像2015年9月的AWS宕机一样。在那种情况下，只有us-east-1可用区无法提供服务。
图1.3 如果应用程序采用了正确的架构和部署方式，即使出现大范围的服务中断（例如整个区域故障），也可以正常提供服务
在这个简单的图表中，很显然可以看到，Netflix比其他公司更好地避免了宕机事故。它的应用程序可以在其他AWS区域运行，并且能够轻松地将所有流量引导到正常的实例上。虽然与其他区域的故障切换不是自动的，但是Netflix已经预料到（甚至实践了）可能会出现这样的中断，并且以此来设计软件架构，包括相应的运维手段。[2]
注意 云原生软件的设计目的是预测故障，并且即使当它所依赖的基础设施出现故障，或者发生其他变化时，它也依然能够保持稳定运行。
应用程序的开发人员、支持人员和运维人员，必须学习和应用新的模式和实践，来创建和管理云原生软件，这也正是本书所教授的内容。你可能认为这并不是什么新鲜的知识，因为很多企业（比如金融行业）在核心业务中已经采用了双主模式的系统，不过这里要介绍的是实现这一目标的新方法。
在过去，实现这些故障切换的行为通常各不相同，因为我们部署的系统最初并没有按照底层系统会发生故障的前提去设计。实现所需SLA指标要求的知识，通常仅限于少数几个“专家”知道。因此，为了使系统能够应对底层基础设施的故障，需要进行精心的设计、配置和测试。
这与Netflix今天所做的事在哲学上存在根本的不同。对于前一种方法，变化或者失败被视为例外情况。相比之下，Netflix和许多其他大型互联网公司，例如Google、Twitter、Facebook和Uber，都将变化或者失败视为正常规律。
这些企业已经改变了它们的软件架构和工程实践，让面向失败的设计成为它们构建、交付和管理软件过程中的一个组成部分。
注意 失败是正常规律，而不是例外。