Windows Azure 应用程序短暂性故障处理

　　这两天在做一个Windows Azure blob存储备份的的一个小功能，但是每次使用CloudBlockBlob.UploadFromStream上传本地文件到Blob Storage，总是不成功报出一个“Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host."的异常来。在网上Google了一下，听有人说是上传的文件太大了，把FileStream分段上传就OK了，于是做了如此尝试，但是发现仍然报出了同样的错误。一时觉得无解了，MSDN上一个偶然的发现，问题突然间有了转机。

　　“Transient Fault Handling”，也就是偶然发现的关键字，中文姑且翻译成“短暂性故障处理”。

　　那什么是“Transient Faults”?

　　MSDN大致的定义是基于云的应用使用基于云的相关服务，往往会因为网络的问题、或是间歇性的服务基础水平的错误等临时性条件导致一些错误，常常在一段时间之后又会恢复正常。比如说SQL Azure可能会因为过度的资源使用、长时间的工作、因为失效切换到备用的SQL Azure、或者是负载平衡的考虑、网络的不佳等原因而短暂的限制database的连接，甚至使中断已有的连接。对于这类临时性的错误，把它叫做“Transient Faults”。对于这种错误可以通过少量的重试来解决。

　　对于这种Transient Faults，我们一般使用Retry Policy来缓和它（这里不能保证一定可以解决，只是在一定程度上减轻错误的出现频率，是你的程序更加健壮）。怎么样使用Retry Policy首先我们看一张图。

　　从图中可以看出Retry Policy是由Detection strategy和Retry Strategy结合起来的，它通过调用ExecuteAction方法去使用你想要的云服务，ExecuteAction方法包裹你使用云服务调用的具体的方法，后边会有代码的演示。

　　Detection strategy能够识别可能导致transient fault的Exceptions，主要针对以下几个服务。　

• SQL Azure
• Windows Azure Service Bus
• Windows Azure Storage Service
• Windows Azure Caching Service

　　接下来说一下这个Retry strategy，按照种类，这里分成了三种，Example给出了每种Retry strategy使用的时间间隔，Retry的次数都是5次。

　　

Retry strategy	Example (intervals between retries in seconds)
Fixed interval	2,2,2,2,2,2
Incremental intervals	2,4,6,8,10,12
Random exponential back-off intervals	2, 3.755, 9.176, 14.306, 31.895

　　下边我以上传文件到Blob-Store为例，来具体讲述如何使用Retry Policy来缓解transient fault，来增强Windows Azure云应用的健壮性、稳定性。

　　首先，加入Transient Fault Handling Application Block assemblies的引用。

　　选中Solution右击工程节点，点弹出菜单中选中"Manage NuGet Packages",  在弹出窗口中选中“Online”，然后在“Search Online”中输入“topaz”，点击安装“Enterprise Library 5.0 - Transient Fault Handing Application Block” package. 这样我们就可以导入需要用到的命名空间了。

　　我们可以在代码或是Application Configuration File里边定义retry policies，如果你只是一个小的程序，调用retry logic的次数不多，你可以直接在代码里边定义，反之在配置文件里边定义。我们的示例是直接在程序里定义。如何在Configuration 里边配置可以点击这里查看。

　　太啰嗦了，直接上代码。

            // Define your retry strategy: retry 5 times, starting 1 second apart
            // and adding 2 seconds to the interval each retry.
            var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2));

            // Define your retry policy using the retry strategy and the Windows Azure storage
            // transient fault detection strategy.
            var retryPolicy = new RetryPolicy<StorageTransientErrorDetectionStrategy>(retryStrategy);

            // Receive notifications about retries.
            retryPolicy.Retrying += (sender, args) =>
                {
                    // Log details of the retry.
                    var msg = String.Format("Retry - Count:{0}, Delay:{1}, Exception:{2}",
                        args.CurrentRetryCount, args.Delay, args.LastException);

                    Trace.WriteLine(msg, "Information");
                };

            try
            {
                retryPolicy.ExecuteAction(
                    () =>
                    {
                        // Call a method that uses Windows Azure storage and which may
                        // throw a transient exception.
                        backupBlob.UploadFromStream(fileStream);
                    }
                );
            }
            catch (Exception ex)
            {
                Trace.WriteLine(ex, "Information");
            } 

　　这样当UploadFromStream报Transient Fault时，Retry Policy会每隔2S重新调用此方法，直到调用成功，或者超过所定义的5次尝试。我自己的blob-store备份本地文件，在未使用之前UploadFromStream尝试了8~9次都没有成功，使用了之后Retry了1次就成功了，不排除是因为上传的文件过大，或是网络的原因，总之它是的程序更加健壮了。

　　最后，说一下那些情况可以用Transient Fault Handling。

　　Detection strategy中提到的四个Windows Azure Services，如果你的应用使用了它们，你可以使用Transient Fault Handling。

　　还有一种情况是使用你自定义的Service也可以使用Transient Fault Handling，具体的使用方法可以点击这里参考

　　

　　

　　附上资料参考的来源：

　　http://msdn.microsoft.com/en-us/library/hh680901(v=pandp.50).aspx