周一，谷歌的其中一项云服务在所有地区瘫痪了近两个小时，导致另一项服务也完全瘫痪，并导致还有另外一项服务因而出现错误和更高的延迟。颇具讽刺意味的是，根源是为防止该服务瘫痪而设计的系统出现了问题。

美国太平洋时间下午瘫痪的服务是Memcache，这是谷歌的平台即服务（PaaS）：App Engine的一部分，谷歌PaaS为开发人员提供了一个平台和诸多服务，以便无需为管理底层基础设施而操心，就可以构建应用程序。

Memcache通过将数据存储查询缓存在内存中加快查询的响应速度。比如说，可以直接从内存来返回网站上最常见搜索的结果，而不是从数据库或另外某种类型的数据存储系统中获得检索结果，后者所花的时间通常来得更长。

谷歌为Memcache搭建的自动故障切换系统要求：该系统对服务每个应用程序的数据中心有一致的视图。那样一来，如果一个数据中心出了问题，该系统可以顺利地切换到另一个数据中心。配置更新后，存储该数据中心配置数据的那个数据库变得不可用，结果发生了这起事件。

谷歌的工程师在事故报告中是这样描述根本原因的：App Engine Memcache服务要求对当前服务每个应用程序的数据中心有全局一致的视图，以便出现了故障、流量切换到备用数据中心后确保高度一致性。将应用程序与数据中心对应起来的配置信息存储在一个全局数据库中。

配置更新后，存放配置信息的特定数据库实体变得不可用，无法正常读取和写入，结果发生了这起事件。App Engine Memcache采用了这样一种方法来设计：如果配置信息在20秒内无法刷新，就被视为无效。倘若客户端无法获取配置信息，Memcache就变得不可用。

在这起事件中，由于Memcache不可用，针对Memcache的请求进入到Datastore服务，致使“Datastore活动激增”，这进而导致了错误和延迟。Memcache故障结束时，Datastore又出现了流量猛增的一幕，导致Memcache本身成功恢复后，美国地区托管的一些应用程序又出现了40分钟的延迟增加这个现象。

受到影响的另一项服务是Managed Virtual Machines（托管虚拟机），该服务是2014年作为介于原始的基础设施即服务（IaaS）与PaaS之间的一种服务推出的，后来被一种名为Flexible Environment（灵活环境）的服务所取代。谷歌仍有客户运行使用托管虚拟机的应用程序，这次停运期间，所有这些客户看到所有HTTP请求和App Engine API调用都出现子故障。不过这起事件并没有影响灵活环境用户。

Google为Memcache提供了两档服务：一档是免费共享的Memcache，这种服务在任何特定的时刻都尽力为客户提供最佳服务，具体取决于资源可用性；另一档是专用的Memcache，该服务提供固定的缓存容量，每小时收费0.06美元。

谷歌是PaaS领域的领导者之一，与Salesforce的Heroku争夺市场份额，多年来Heroku是市场霸主。其他重量级厂商包括微软、Mendix、OutSystems、IBM、Red Hat、SAP和Oracle。

相比基于订阅的应用软件或原始的基础设施即服务（SaaS和IaaS），PaaS这个市场要小得多，不过分析师们预测，未来四年PaaS会以相当迅猛的速度增长。据Gartner声称，去年全球PaaS市场规模达到了71.7亿美元，它估计今年会增长到88.5亿美元，到2020年更有望增至148亿美元。

之所以会有这样的发展势头，主要归功于物联网应用得到了广泛采用。据Gartner这家研究公司声称，基于PaaS构建的新应用程序中一半以上将“以物联网为中心”。

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。