忙信号模式介绍
在阅读本文前，您需要了解云计算与互联网开发基础知识。[忙信号模式]是专注应用程序对当云服务请求响应不成功时忙信号如何处理。这种模式从客户端角度出发，这里主要描述的云计算中场景。客户端是每发出请求到服务端，服务端答复忙信号。客户端负责根据忙信号做出适当数量的重试次数处理。如果重试过程中继续收到忙信号，客户端将该服务视为不可用。我们偶尔地拨号电话结果是忙信号，正常的反应需要重拨，这时通常会导致能成功建立通话。
同样，偶尔会调用服务结果被返回失败代码，表明云服务目前不能够满足该请求。需要重试，在服务端这种结果通常称之为常规反应。云服务不能满足请求的主要原因可能是因为它是太忙了。有时服务是"太忙"因为几百毫秒，或一个或两个秒处理。智能重试的策略将有助于处理忙信号而不影响用户体验。
场景： 您的应用程序每次使用云平台服务，但云服务不能保证都响应成功。这个模式应用于所有访问云平台服务类型，如管理服务，数据服务等。一般来说，也可以应用于通过网络访问的服务或资源，不一定是云计算。在所有这些情况下，应定期短暂失效。熟悉的场景，在如非云计算下，当 Web 浏览器完全加载一个网站失败后，需要简单刷新或重发请求来修复该问题。
对云平台的意义。通常在云服务会有短暂失效的结果，这个时候如果不回应合适的忙信号，用户体验则非常糟糕，用户感觉是服务端程序错误，并且难于重现。应用程序应有计划地响应忙信号，这个模式能增加应用程序的健壮性。
影响： 可用性，可伸缩性，用户体验。
机制：当客户端访问云服务时，正常情况下使用忙信号模式来预测与处理短暂失效。短暂失效是瞬间失效，它不是客户端的故障。事实上，如果客户端稍后重发相同的请求，它往往会成功。短暂失效是预期发生的，不是意外。有点儿像电话拨打电话时对方忙音，这是正常的。想象你打电话中国移动客服中心，你的呼叫将被上百个话务员中一个人接听。但不是这每次会这样顺利，当听到提示客服忙线时，你不会猜测哪儿不对了，通常你会重拨这个号码，这就是[短暂失效]，作出适当的反应： [重试]。但是，连续的忙信号意味着需要停止呼叫一段时间，可能是一天。如果这是真实的忙信号我们才想去重试，如果我们拨打错号码或号码销号了，我们不再会想重试了。
虽然网络连接问题有时可能是短暂失效引起的，但我们关注的是服务边界上的短暂失效，这是一个请求到达云服务，但没有被服务端立即满足。 云计算服务有限制的；具体需要查阅您的云供应商文档。例如，限制在每个可执行服务操作的最大数目，每秒可以将多少数据传输，在单个操作中可以传输多少数据？在云服务中个别客户端或多个客户端集合可能超出限制。每当您对服务的使用超出了其允许的最大吞吐量，这将由服务检测到您的访问，并将进行带宽限制。带宽限制是由服务完成的，有时延迟响应，并做出其它客户端的请求被拒绝正常反应。
云服务也有内部故障，如发生磁盘驱动器故障。虽然该服务将自动通过自我修复并将故障转移到一个可工作的磁盘驱动器，将流量重定向到一个可工作的节点，并启动故障磁盘上的数据复制程序 （通常有三个副本），它可能无法在瞬间完成。在恢复过程中，该服务将减弱，并且服务调用更有可能被拒绝或超时。
为什么预期数据库将被释放？
SQL 数据库为什么会断开您的连接？当您连接时，在幕后它不是单个实例，而是三个协作服务器的群集。这有几个好处。一个好处是当每个字节写入群集内所有三个服务器的磁盘驱动器时发生故障的复原能力。另一个好处是，作为一种多租户服务，SQL 数据库可以分发 （和重新分配） 跨服务器而保持它平衡负载。这些好处付出了代价。如果 SQL 数据库选择改变连接到另一个群集中的三个服务器，则需要首先断开连接你 ；当您重新连接，您将连接到您的新分配的群集节点，虽然你不能分辨的这些连接。
识别忙信号
对于通过 HTTP 访问的云服务，短暂失效是表示拒绝该请求，通常服务端回应适当的状态代码， 如：HTTP 503 服务不可用。对于通过 TCP 访问关系数据库服务，可能会关闭数据库连接。其他短暂的服务中断可能会导致不同的错误代码，但处理程序类似。
现实中的案例：
某应用程序通过公共互联网向 Windows Azure Blob 存储设备上传数据，采用自定义指数退避算法的重试策略，同时还记录每次重试日志。上载期间的有近 100 万个文件且平均大小4兆字节，1.8%的文件大约至少需要一次重试。请注意因为文件是如此之多，每个文件上传涉及许多存储操作细节，所以很少超过 0.1%的时间就需要对存储操作重试。还有，许多因素可以影响重试的发生，例如公共互联网网络连接与本地网络资源的竞争。结果将会变化很大。
响应忙信号
您的应用程序应在如何应对如果再次请求服务失败？这取决于具体环境。要考虑一些响应包括：
重试立即 （无延时）
延迟 （固定或随机延迟） 后重试
增量延迟 （线性或指数退避) 最大延迟时间重试
应用程序中抛出异常
这里又引入[重试模式]，上图的3个步骤解释了Http下重试流程。应该不能看懂，在些这不再赘述。在微软最佳实践的企业库，提供了The Transient fault handling application block模块来处理这个问题。有时间在后面，我们来介绍它使用。
希望对您云计算的软件设计与开发有帮助。
您可能感兴趣的文章：
作者：Petter
Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu
Blog。