本文来自网站优化服务商CloudFlare官方博客，发表于6月30日。龙卷风袭击了美国东海岸，造成停电，备用电源的失效最终导致Amazon AWS和依赖于AWS云主机的服务离线。

对于此事有许多评论，我最喜欢来自Phil Kaplan的一条：“云泥之别。”（同样是云，云服务根本不是龙卷风的对手。）

这让我对于不同类型云服务的稳定程度、如何加强这些自己网站的稳定性有了更多思考。

积云，层云，卷云，雨云

许多产品都号称自己是“云”服务，然而所谓“云”的定义确实各自不同的。

Salesforce以自身服务特性为云服务下定义——将自己与传统的客户关系管理系统（CRM）对比，后者需要客户自行购买设备和运行数据库，而Salesforce的CRM系统则相当于一个收费服务，客户能在多种设备上使用。

为了做到这一点，Salesforce不光是在世界各地建立服务器和数据中心，还收购了另外一家云服务平台Heroku，后者原先用于在线运行Ruby、Java、Python等程序。

Salesforce运行于自家服务器，而Heroku运行于Amazon AWS之上，早在“云”这个概念提出来之前，就有人给出了更精确的定义：“as a Service”（作为服务）。Salesforce是软件即服务（SaaS），Heroku是平台即服务（PaaS),Amazon AWS则是基础设施即服务（IaaS）。

这三者共同点是，为客户提供数据存储和计算的服务、减少设备或平台带来的障碍，我称之为“数据与程序”云服务。

一层层服务器堆叠起来的网络

印度传说中世界是在龟背上的，而《时间简史》里提到了与这相关的一段轶事，一位科学家公开演讲时，被老太太斥责“你讲的都是废话，宇宙是个龟背上的平台”，于是他反问道“那么乌龟是站在哪儿？”，老太太只好说“数不胜数的乌龟一层层驮着”。

我们在使用云服务时很容易忘记它的结构，所有云服务都建立在服务器、交换机和路由器之上，但在Salesforce上添加公司客户信息时，并不要考虑添加任何硬件，Salesforce服务器会承担这些。

一个个环节构成了云服务，当任何一处受到阻碍时，云服务就瘫痪了。前几天的AWS数据中心停电，或者单纯从服务器来说，驱动崩溃、内存损坏，CPU过热，路由死机等等，不同环节出的问题会带来不同影响。

同步带来的挑战

有情况便有对策，多服务器负载均衡、备份和同步数据等等，为服务和数据提供保障。但同步数据要比备份数据难得多，一方面是同步机制设计，另一方面则是网络状况限制。以光速为例，在理想条件之下光子以全速从旧金山运动到阿姆斯特丹需要58.69毫秒，这个延迟不会让人觉得有卡顿感，然而实际上光纤、铜电缆、各级路由和交换机丢包等等条件，使得网络延迟大大上升，此时同步机制就要重新设计。

以Google和Twitter为例，在加拿大和日本搜索相同关键词结果是不同的，这不仅因为所用语言不通，引擎收录数据的同步也是原因，Google并没有保证所有人会有相同的搜索结果。

Twitter则不一样，Twitter Timeline是网站核心，为了保证每个人能看到自己Follow的所有人的更新，Twitter面临着更严重的问题。顺带一提Facebook的无法复制的解决方案——Facebook让用户觉得Timeline重要性不大。

Twitter、Facebook和Google这三者共同点在于拥有着庞大而需要同步的数据，同时面对着网络状况和服务器建设的问题。以目前的科技水平来看，提高容错率是个比较好的解决方案，把数据同步问题先放一放，思考在同步无法顺利进行的时候保持同样用户体验。

前端

数据同步问题只是一个方面，暂且称之为后端。所有网络服务都有前端，即用户界面或接口，前端是用户与数据的桥梁，前端设计不需要考虑太多程序逻辑和数据处理步骤，它只是将用户提交的请求转移给服务器，将处理结果根据用户类型（浏览器、系统等等）进行调整然后返回。

前端还能为后端提供一定程度的保护，使其免受安全威胁和攻击，Anycast任播技术是这类典型应用。

这就是我们建立CloudFlare的原因，用户只需调整域名DNS设置，便能获得CloudFlare提供的许多服务，包括网站加速、节约流量（缓存和防恶意盗链）、服务器安全防护、浏览者数据统计分析（自身分析系统和一键添加Google Analytics）等等。

我们用上文中提到的对策为无需同步的前端层提供了改进空间，缓存技术使得浏览服务器崩溃时的网站不是难题，服务器负载均衡的好处在今天San Jose服务器故障中体现出来，很少人受到影响，而且其他服务器表现良好，最终结果是客户并不需要为我们的错误买单。