Candidate

Factor

Comparison

Architecture

Dependency

App Running Environment

Dev Functionality

Deploy

Telemetry

Auto-Recovering

Availability

Scalability

Additional

• WAS架构
• WAS性能目标
• 分散工作负载
• 避免Table热区
• 优化Table查询

WAS架构

Windows Azure Storage是一个三层架构，分为前端(FE)、分区层(Partition)、分布式存储层(DFS)。

前端负责接受客户端HTTP(S)连接，验证身份，计费以及写日志。

分布式存储层为实际的物理存储。无论Blob，File，Queue还是Table，其最终都已Binary形式存放在此层。此层确保数据在三个独立的物理节点上保存备份，避免数据丢失。

分区层提供了逻辑数据结构的访问能力。它理解数据的逻辑抽象结构，能够按照用户的请求来正确存取DFS层数据。同时，分区层实现了跨数据中心的备份同步功能。

WAS的设计目标是存储海量数据，实现大并发访问。海量存储由分布式存储层来实现，而大并发的目标是如何实现的呢？

从物理存储来看，大并发的压力来自于磁盘I/O和网络带宽。在DFS层，数据的物理存储单位是Extent，100MB-1GB不等。每个对象（Blob，Table或Queue）都由一个或多个Extent拼接而，除此之外，数据还有三个备份。这些Extent离散分布在多台独立的服务器上，因此，用户对对象的访问被分摊在多台服务器上，以达到高吞吐量。

数据逻辑结构的处理需要耗费Memory和CPU资源。Partition层将逻辑数据拆分为多个Partitions，比如：每个Blob, Queue即为一个Partition，Table中PartitionKey相同的所有实体存放在一个Partition。Partition层每台服务器负责服务一组Partitions，Master服务器会检测每台服务器的负载，并动态调整Partitions的分配。由于所有数据都存放在DFS层，因此负载调整会非常迅速。通过动态负载均衡，Partition层确保有足够的资源来响应客户请求。

WAS性能目标

微软在MSDN上公布了WAS的性能目标，这些数据是WAS的性能上限，若用户使用WAS超过指标时，WAS会返回给客户503（Server Busy）或500（Operation Timeout）。当用户接到此类错误时，建议用户采用回退的方式重试操作，这样可以缓解短暂高峰造成的WAS服务压力。

简要来说，性能目标有两层：Partition级和Storage Account级。Storage Account级的目标如下：

* Ingress refers to all data (requests) being sent to a storage account.

* Egress refers to all data (responses) being received from a storage account.

Partition级别的性能目标为：

若要了解更多细节，可以访问如下官方文档

https://msdn.microsoft.com/en-us/library/azure/dn249410.aspx

分散工作负载

了解到WAS的性能目标后，开发者在设计时就要尽量避免达到性能上限。

举个实例。两个Role通过WAS Queue来做消息中转，消息吞吐量在高峰时段可能达到10K，那么如果设计人员只使用单Queue，则Queue会成为性能瓶颈，无论增加多少Role虚拟机数量，吞吐量被始终限制在2000 messages/sec左右。解决方案就是使用多个Queue来分散工作负载。

同样的道理，用户要避免使用一个WAS Account来放置过多的虚拟机磁盘，否则有可能达到WAS Account级的性能上限20,000事务/s。建议每个WAS Account最多放置40块虚拟机磁盘。

避免Table热区

前面提到过，一个Table中PartitionKey相同的实体放置在同一个Partition里，而Partition的性能上限是2000实体访问/s。如果应用程序设计不当的话，有可能出现Table的某些Partition访问过于频繁，造成WAS响应慢或者报错（500，503）。举个具体的例子：一个日志系统，使用日期做PartitionKey，那么所有的写操作都会hit当日的Partition。如下通过测试，给大家一个直观的感觉。

场景：一个博客系统，使用WAS Table来存储博客内容。现有两种设计：

设计1：PartitionKey=date, RowKey=BlogThreadID+PostID

代码如下：

设计2：PartitionKey=date+BlogThreadID, RowKey=PostID

代码和设计1类似，唯独修改了PartitionKey

两种设计保存的数据内容是一致的，只是PartitionKey和RowKey的格式不同。最终执行效率能有多大区别呢？我这里使用压力测试来检验，结果差别巨大！

设计1，随着用户负载增加，服务延迟越来越高，吞吐量维持在1380/s

设计2，随着用户负载增加，服务延迟平稳，而吞吐量达到了2600/s

可见，开发者在设计PartitionKey，RowKey时要避免Hot Partition，否则其造成的性能差距是巨大的。

设计2仍然存在问题：Partition按照PartitionKey字符串排序，编号相近的Partition很有可能被分配在同一台Partition服务器。设计2可能造成Partition服务器压力过载，从而影响WAS响应速度。为了提高性能，用户可以考虑倒置日期字符串来避免Partition集中。

优化Table查询

Table的实体有多个属性，通过筛选属性值，可以返回需要的实体。筛选条件的选择会直接影响查询效率。

数据库用户都知道索引能够避免扫描操作，减少I/O，从而提升效率。Table也支持索引，不过每个Table只有一个索引，即PartitionKey+RowKey。指定了PartitionKey和RowKey的查询叫做Point Query，他的查询效率也最高。

如果没有指定PartitionKey和RowKey，而是单单筛选其它属性，则查询退化为全表的扫描操作，效率会大大降低。不仅如此，之前WAS架构提到过，Table数据保存在多个Partition中，而Partitions分布在多台Partition服务器上。如果遍历的数据散布在多台服务器，则WAS会在遍历完一台Partition服务器后返回客户端一个Token，客户端凭Token来再次请求，WAS会将请求导向到下一个服务器，多次Roundtrip过程会耗费更多时间。

以访问WAD Table为例，我测试了用全表查询，局部范围查询，指定Partition查询和Point查询来搜索同一个实体。

结果表明PartitionKey 范围越小，查询速度就越快。

因此，用户的查询操作要尽量指定PartitionKey或者一个PartitionKey范围，避免大数据范围的扫描。而设计者需要根据业务需求考虑如何组合PartitionKey，使查询语句尽量多的使用到PartitionKey。

Table Storage 设计模式

最近微软公布了一份官方文档，列举了使用Azure Table Storage下的一些设计技巧，感兴趣的读者可以直接访问如下文档

https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/?rnd=1

WAS使用HTTP(S) 协议，访问操作通过发送HTTP请求来完成。访问操作的时间可由Request传输时间、Response传输时间和服务端处理时间组成。

为了提高性能，开发人员可以尝试减少每个过程的时间。总结起来，有如下一些方法：

• 减少网络延迟
  • 选择最近的数据中心
  • 使用CDN减少网络延迟
• 减少数据传输
  • 压缩Blob
  • 使用JSON格式
  • 使用实体映射（Entity Projection）
• 减少请求事务数量
• 并发访问
• 其它网络优化
• 减少服务端受理时间(二）
• 避免Throttling（二）

 此文章介绍网络相关的优化方法。

选择最近的数据中心

网络延迟对任何网络服务的影响都很大。Azure在全球有17+个数据中心，为了减少网络延迟，开发者应该选择离产品用户最近的数据中心。如下网站可以显示你当前的网络访问全球每个数据中心WAS Blob的速度。

https://azurespeedtest.azurewebsites.net/

在选择数据中心时，若没有特别原因，开发者需要尽量避免跨数据中心的网络访问，这样会造成额外的流量费用。比如说用户部署Cloud Service在香港，而Cloud Service需要访问 新加坡的WAS来读取数据，那么这个跨数据中心的访问将被额外收取流量费，而且跨数据中心的网络延迟会比数据中心内部访问要高。

使用CDN减少网络延迟

CDN（Content distributed Network） 是一个常用的HTTP访问优化方法， 其原理是：在某个区域或全球范围内分布很多文件缓存节点，尽可能的离用户更近。当用户需要从站点下载文件时，用户直接访问离他最近的缓存节点，若请求的数据已被缓存，则直接返回客户，起到网络提速功能；若请求的数据未被缓存，则从源站点下载。

Azure CDN有两个版本：Global版的CDN由EdgeCast公司提供，在全球24个地点部署有缓存节点。大陆版的CDN委托给ChinaCache运营，主要针对中国区网络。通过Azure CDN，可以加速WAS Blob， Cloud Service 和 Azure Website的网络访问速度，不过WAS Queue和Table不可以。

Edgecast 缓存节点分布

减少数据传输

减少传输的数据量可以减少Request或Response的网络传输时间。减少数据的方式可以有压缩数据和裁剪无关数据。

压缩 Windows Azure Blob

Blob类似于文件存储，若文件是文本类型，则压缩文件可以节省很多带宽。比如网站的js，css文件，常用浏览器都支持Gzip压缩，因此在上传前，不妨用Gzip压缩文件。实例代码如下：

            var blobClient = new CloudBlobClient(account.BlobEndpoint, account.Credentials);

            blobClient.RetryPolicy = retry;

            var blobContainer = blobClient.GetContainerReference("bundles");

            var blob = blobContainer.GetBlockBlobReference("jquery-1.6.2.js");

            blob.Properties.ContentType = "text/javascript";

            blob.Properties.CacheControl = "public, max-age=3600";

            blob.Properties.ContentEncoding = "gzip";

            using (var compressed = blob.OpenWrite())

            {

                using (var gzip = new GZipStream(compressed, CompressionMode.Compress))

                {

                    using (var filestream = File.OpenRead(filePath))

                    {

                        filestream.CopyTo(gzip);

                    }

               }

           }

如下的一个测试显示，jquery文件经过压缩后，只有原先的1/4大。

使用JSON格式

在早期版本的WAS，Table和Queue只支持ATOM格式的消息（XML），现在的版本支持JSON。相比于XML，JSON体积更小，可以更快的传输，并且更容易操作。如下为同样的数据以ATOM和JSON形式呈现，可以明显发现JSON格式更小。

使用JSON格式，需要在HTTP request header上添加 header “Accept: application/json”

使用实体映射（Entity Projection）

在查询WAS Table时，默认情况下WAS会返回符合实体的所有属性。而在一些情况下，客户端只需要实体的某些属性。WAS Table提供了查询参数 “$select”，通过使用此参数，可以让WAS Table只返回客户端需要的属性。

减少请求事务数量

拿现实的例子作比方：淘宝小店发货，如果店主每接到一单就叫快递来拿，那么快递小哥要反复奔走于快递站和淘宝店之间，在取件上耗费了大量的时间。一个更可行的方式是，店主把要发的货屯起来，在每天下午3点叫快递一并拿走，这样快递小哥一天只用跑一次，节省了大量时间。访问WAS也是如此，用户需要发现访问数据的关联性，尽量把所做的操作并在更少的请求事务上。

WAS Table支持Batch操作，即把一组Table操作放到一个Request中完成。Batch即节省了大量耗费在数据传输上的时间，同时又确保事务原子特性。如下代码测试使用Batch一次插入100条记录，通过比较发现，其性能要比逐条插入高出4到16倍。

 
需要注意的是，WAS Table Batch操作要求访问的实体存在同一个Partition中，操作上限为100。

事务并行化

当事务之间没有先后依赖关系时，可以通过并行执行来提升速度。用过网络快车、网络蚂蚁的人都懂的，使用多个线程同时下载文件的不同部分，然后拼接起来，可以达到更快的下载速度。

对于WAS Block blob，每个Blob又一组Block组成，用户可以用多线程并发的上传Block，当文件的所有Block上传完毕后，最后发一个请求，将blocks按顺序组装起来。由此方法，可以实现多线程上传，提高传输的吞吐量。图下所示，通过并发上传可以基本达到单Blob的性能上限60MB/s。

用户可以直接使用微软提供的一个工具AZCOPY，它默认就使用多线程上传。

https://blogs.msdn.com/b/windowsazurestorage/archive/2012/12/03/azcopy-uploading-downloading-files-for-windows-azure-blobs.aspx

其它网络优化

• 当网络传输的object小于1400字节时，禁用Network Nagle会提高传输性能。
• 禁用 Expect 100-Continue，减少网络Roundtrip。
• .NET 通过ServicePointManager来限制Outbound 连接数，默认为2。若程序大量使用并发连接，需要手动调整此阀值。

从外部或者客户角度来看，Azure托管服务和其他传统服务没有什么区别，因此，很多的监测工具仍然可以用在托管服务上，比如Probe探测，Google analytics。

若从服务内部接口来看，Azure托管服务和传统服务还是有很多不同之处的：托管服务运行在分布式环境下，每台服务器都是无状态的，随时可能被回收重建。因此，把监测日志放到服务器不太可靠，日志随时可能丢失。而且，把日志分散的保存在多台机器上也不利于查询使用。另外，托管服务往往依赖其他云服务（如存储），用户不能够登录到这些依赖服务的后端来检测，其实用户也没有这个义务。

在这篇文章，我想列举一下适用于Azure托管服务的监测方法，当作一个索引。

虚拟机日志

有很多的日志默认输出到服务器本地磁盘上，比如Application Log，Windows Event Log 和 IIS Log，对于此类型的日志，全都可以使用WAD来自动上传到Azure Storage上，这样便于数据查看和过滤。在可靠性设计这篇文章中已经提到了配置方法，大家也可以直接看官方MSDN文档。

https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-diagnostics/

https://msdn.microsoft.com/library/azure/gg433048.aspx

性能数据

性能数据是评价服务器运行状态、负载的重要指标。WAD可以收集性能数据并存放到Table Storage上。

用WAD收集性能数据的方式与收集日志基本一致，用户可以从常用Counter集合中勾选需要的Counter，并调整采样率，也可以直接输入定义的Counter名称。

至于如何查看和使用这些性能数据，开发者可以自己编写监控程序来读取数据，也可以使用第三方的监控服务，如Azure Watch。我这里演示一下如何使用Azure管理网站查看性能数据。

1. 首先配置好WAD，部署网站。
2. 登陆Azure管理网站，导航到托管服务配置页，把Monitoring LEVEL设置为 VERBOSE
3. 导航到MONITOR页，点击 “ADD METRICS”，从列表中选择需要监视的Counter集合
4. 性能数据会显示到上方的图表中，数据一般会有10-20分钟的延迟。

1. 用户可以点击“ADD RULE”来添加警报规则，当性能数据超越规定阈值时，可以触发警报，自动发信给系统管理员。

GuestOS Agent Log

每个托管服务实例上运行了一组代理进程，他们的作用是初始化程序运行环境，启动程序并自动恢复程序，同时也会和平台沟通，汇报实例的运行状态。

作为一般的开发者，不需要关心此日志。不过感兴趣的话，可以远程登陆虚拟机，日志保存在C:\Logs目录下。这里推荐同事的一篇博文，他解释了代理进程的功能和启动流程。

https://blogs.msdn.com/b/kwill/archive/2011/05/05/windows-azure-role-architecture.aspx

3^rd party monitoring tool

有一些第三方的工具，以托管服务启动任务的形式运行，从虚拟机上观测程序，并把数据返回到他们的管理网页上，比如New Relic。我没有用过，大家可以自己尝试

https://newrelic.com/azure

Probe

我也不知道怎么翻译，总之是一种常见的监测方式。从外部定期发送请求到网站（或服务），探测服务器是否相应正确，以及响应是否迅速。很多第三方服务商提供此类服务。Azure平台也提供此类服务”ENDPOINTS MONITORING”，不过还处在Beta阶段，功能单一，不支持发信报警功能，好处是不要钱。

ENDPOINT MONITORING 的设置方法如下：

1. 打开Azure管理网站，导航到托管服务的配置页。
2. 设置ENDPOINTS节，填写监测的服务地址，以及监测地理位置。

1. 在托管服务DASHBOARD页观看监测记录

Azure 服务仪表盘（Azure Status Dashboard）

Azure平台提供了一个服务仪表盘，它显示了所有Azure服务当前的运行状态。用户也可以查询历史上发生过的问题。当用户的程序出现故障时，不妨先看一眼仪表盘，若是Azure服务故障，可以等待Azure平台修复问题。

Global Azure

https://azure.microsoft.com/en-us/status/#current

China Azure (21世纪互联)

https://www.windowsazure.cn/support/service-dashboard/

Azure管理网站

Azure管理网站集成了各种Azure服务，用户可以从这里获得服务的运行状态信息。当Azure平台出故障时，平台也会推送通知到受影响用户的管理网站上。因此，当服务出问题时，用户可以登录管理网站，看看是否有平台故障，或者是否托管服器处在不正常的状态。

Storage Metrics & Logs

Azure Storage提供的服务器端的日志和监测功能。此功能常被用作Storage相关的Troubleshooting。

https://msdn.microsoft.com/en-us/library/azure/hh343270.aspx

Application Insight

大家可能发现，Azure托管服务的监测日志比较分散，用户需要很多的配置才能监测服务。 App Insight是微软正在开发的产品，他集成了上述多种监测日志，然后在统一的面板上显示关于目标服务的所有信息。App Insight简化了用户对监测的配置操作，使用和更容易洞察服务的问题。目前，此产品还在beta阶段，版本变化比较快，不过很有潜力。参考如下链接：

https://msdn.microsoft.com/en-us/library/dn481095.aspx

服务的可靠性至关重要，而影响可靠性的因素多种多样，例如程序错误、硬件故障或依赖服务故障，以及人为失误。工程师们要对每个方面做出合理的设计来避免或容错各种故障，才能使服务达到高的可靠性。除此之外，当服务已经中断，如何快速定位问题并解决也是产品设计时就需要考虑的。这篇文章只以“CalculateCloud”为例，讨论一下托管服务的高可靠性设计。

拿出CalculateCloud的架构图看看，影响服务可靠性的有如下几方面：

• 程序故障：这里只WebRole/WorkerRole代码出错。
• 服务器故障：这里只运行角色代码的虚拟机发生故障。
• 依赖外部服务的故障/维护：这里指托管服务所使用的Table或Queue发生故障。

接下来针对每种故障，我们逐个寻找对策：

• 程序故障
• Storage服务故障
• 服务器故障/维护
• 追求更高的可靠性
• 总结

程序故障

托管服务程序的调试和其他代码一样，在开发和测试阶段，可以使用模拟器在本地环境运行和调试代码。比如CalculateCloud非法字符输入的问题，在本地调试时，Visual Studio能够提示WorkerRole代码抛出异常。

对于此问题，使用try/catch来受理异常，问题就搞定了。需要留意的是，一旦部署到生产环境下，debug会比较困难。相比之下，丰富的程序日志能帮助用户监测服务状态和快速定位问题。下面的代码使用默认的 System.Diagnostics.Trace类来输出日志。

                if (msg != null)

                {

                    string result = null;

                    try

                    {

                        // handle job here.

                        var nums = msg.AsString.Split(',');

                        double answer = double.Parse(nums[0]) * double.Parse(nums[1]);

                        Thread.Sleep(10000);

                        result = string.Format("Job handled. {0}*{1}={2}", nums[0], nums[1], answer);

                    }

                    catch (FormatException)

                    {

                        result = "invalid input. msg=" + msg.AsString;

                        Trace.TraceError(result);

                    }

                    catch (Exception ex)

                    {

                        result = string.Format("failed to handle job. msg={0}",

                            msg.AsString);

                        Trace.TraceError(result + ", error=" + ex);

                    }

                    finally

                    {

                        AddResultEntry(result);

                        queue.DeleteMessage(msg);

                        Trace.TraceInformation(result);

                    }

                }

角色项目默认使用Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener来写日志。程序日志会以二进制形式写到虚拟机的本地磁盘C:下。由于角色可以运行在多台虚拟机上，那么日志也会分散在多台服务器上，登录每台虚拟机来查看日志会很麻烦，这里可以使用托管服务的一个组件“Windows Azure Diagnostics（WAD）”来解决问题。WAD会在每台虚拟机上启动两个额外进程，它们定期将虚拟机上的日志上传到Azure Storage上，用户可以从一个集中的地方访问所有日志。WAD的配置如下：

打开的Calculate.Worker的角色属性面板，在Diagnostics节中选择“Custom Plan”，然后设置存储日志信息的Azure Storage 连接字符串，再点击“Edit…”按钮，修改Application Logs的上传频率为1分钟。

WebRole同样需要添加Trace代码并配置WAD，这里不再重复。

WAD开启后，应用程序日志会被定期上传到Table Storage “WADLogsTable”表，大家可以用各种工具来查看日志，比如集成在VisualStudio “Server Explorer”中的Azure资源查看器。

WADLogsTable的索引键为”PartitionKey+RowKey”,其中PartitionKey格式为字符串”0”+datetime.Tick。一个常用的查询语句如下，其含义为：查询部署ID为 08cd08dce90d4516b21be7bfe6936c75，在9/24/2014 1:00:00 AM UTC后，级别至少为“警告”的所有日志。

PartitionKey gt '0635471172000000000' and DeploymentId eq '08cd08dce90d4516b21be7bfe6936c75' and Level lt '4'

WAD提供了很多的功能，感兴趣的读者可以查看MSDN官方文档

https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-diagnostics/

https://msdn.microsoft.com/library/azure/gg433048.aspx

Storage服务故障

一个复杂系统必定会存在外部资源引用。当被依赖的资源发生故障时，往往会影响到系统的可靠性。在设计时，需要考虑到如何容错外部资源的故障，尽量降低对系统的影响，或者至少能快速定位出问题的资源，以便采取准确的恢复措施。

微软保证Azure Storage 在99.9%的时间内能正常运转，也就是说每个月最多可能offline 44分钟。因此，准备应对Storage故障是很有必要的。

Azure Storage运行在普通的硬件上，硬件故障不可避免，另外由与系统维护，版本更新或者负载均衡等原因，都会造成某些Storage服务器短暂下线，而其正在执行的用户请求就会失败。对于此类型的访问失败，用户只需重试一次，请求就会被移交给健康的服务器节点进行受理。因此，微软强烈建议客户端收到错误（超时或HTTP500）时重试几下。实际上，Azure Storage .net library默认已经实现了重试机制，并默认开启。对于直接使用REST API来访问Storage的代码，务必捕获异常状态并重试。

虽然较少发生，不过有时候重试也会失败，开发者需要自己捕获失败并受理。检查CalculateCloud的WorkerRole.cs文件，你会发现一旦访问storage的重试机制失败，WorkerRole程序就会因为未受理的异常而crash，从而导致更严重的系统服务中断。解决办法就是try/catch storage异常。这里我把错误记录下来，查询日志时若发现大量Storage错误信息，则说明Storage存在问题，需要采取措施。

            while (true)

            {

                try

                {

                    var msg = queue.GetMessage();

                    ……

                }

                catch (Exception ex)

                {

                    // write trace.

                    Trace.TraceError("error occured when access storage. " + ex);

                }

            }

另外，为了进一步提高Storage的可靠性，可以使用Storage的异地备份-只读（RA-GRS）的功能，此功能将用户的数据存放在相邻的两个数据中心上，当其中一个数据中心故障，用户可以读取另一个数据中心备份。此功能可以保证数据读取99.99%的可靠性，而数据写入可靠性仍为99.9%。需要注意的是：数据在两个数据中心间同步，会有几分钟的延迟。使用RA-GRS的方法如下。

在Azure管理网站上导航到Storage配置页，更改Replication模式到“READ-ACCESS GEO REDUNDANT”

除此之外，还要修改代码，让Storage客户端能够自动failover到异地备份上。以CalculateCloud显示运算结果为例，需要更改WebRole的Default.aspx.cs文件。

        protected void Button2_Click(object sender, EventArgs e)

        {

            try

            {

                var connstr = RoleEnvironment

                    .GetConfigurationSettingValue("DataConnection");

                var storageAccount = CloudStorageAccount.Parse(connstr);

                var tableClient = storageAccount.CreateCloudTableClient();

                tableClient.DefaultRequestOptions.LocationMode =
                    LocationMode.PrimaryThenSecondary;

           ……

服务器故障/维护

托管服务是PAAS层面的服务，服务器的可靠性由平台来负责。微软对托管服务可靠性保证（SLA）的定义为：当每个角色运行在至少两个实例（即虚拟机）时，保证托管服务99.95%的在线时间。这个SLA如何理解呢？我先解释一下Azure平台的可靠性设计。

托管服务下的每台虚拟机被同时分配到两种域：故障域和更新域。故障域是物理上的概念，数据中心上每组机柜既是一个物理域，它有独立的电源管理和网络组件，一般认为，多个故障域不会同时发生故障。更新域是逻辑上的概念，管理器(FC)按照规则，同一时间只会维护一个更新域中的虚拟机。在Azure平台上，运行同样角色的三台实例（即虚拟机）是这样分配的：

如此一来，无论是硬件故障还是系统维护，同一角色的虚拟机不会同时下线 。这样解释大家就明白了吧，托管服务SLA保证了角色实例不会同时下线，而开发者需要在这种机制上建立可靠的程序。

那么用户如何充分利用平台特性来实现服务的高可靠呢，David Chappell总结了Azure编程三原则：

• 每个托管服务拥有至少一个角色
• 每个角色需要运行至少两个实例
• 即使部分实例故障，整个Azure托管服务仍可正常运行

大家若想了解更多信息，可以下载David所写的托管服务编程模型白皮书，或者翻看一下《Microsoft Azure开发与应用》。我这里用三原则来检查一下CalculateCloud项目。

第一原则是强制原则，显然满足。对于第二原则，目前每个角色只运行在一台虚拟机上。这个修改很方便，打开每个角色的属性面板，修改 Instance Count为 2。

第三原则比较复杂，具体讲就是要求同一角色的实例拥有同样的功能，并且保持无状态，其中一个实例下线后，另一个可以替代它执行任务。

对于WebRole，实例运行在负载均衡器（SLB）后，负载均衡会探测实例的状态，并将Request分配给健康的实例上。为保证第三原则，每个WebRole实例不应该将客户的状态（如Session）保存在本地（进程或磁盘），否则一旦虚拟机下线，运行在它上面的客户将遭遇信息丢失的问题。Calculate.Web角色访问的所有数据都保存在外部Azure Storage上，因此满足第三原则。

Calculate.Worker不在本地保存中间结果，运算结果也直接写到Azure Storage了，所以也满足地三原则。

大家可以把CalculateCloud部署到云端测试一下，当重启一个Calculate.Web实例和一个Calculate.Worker实例时，整个服务仍然正常运行。即使Calculate.Worker所有的实例都重启，得益于Azure Queue持久化消息通信，服务仍然可用，只是计算工作会有所延迟。

追求更高的可靠性

有些客户对服务可靠等级有更高的要求。比如发生数据中心级别的故障时，服务仍然可用。Azure平台能做到吗？当然能啊，只要愿意花更多的钱。

微软提供的另一个服务叫做Traffic Manager（简称TM），它工作在一组托管服务前，将客户的服务请求按照规则重定向到背后的某个托管服务上。以下图为例，解释一下流程。

1. 客户要访问服务（www.contoso.com），首先发DNS解析请求到公网的DNS服务器。对于服务提供商，他需要事先从域名提供商那里购买一个公网域名consoto.com。
2. DNS服务器将服务的域名（www.contoso.com）重定向到TM的域名（*.trafficmanager.net）。对于服务提供商，他需要事先配置子域名www.contoso.com的解析规则，将其CNAME到TM。
3. DNS服务器访问TM的域名服务器来索要解析的IP地址。
4. TM根据规则选择一个托管服务（现在TM支持所有公网服务）。TM会检测托管服务的状态，确保选择健康的服务。另外，用户可定义选择方式：根据性能，平均分配，或者故障迁移。
5. TM域名服务器把选择的服务IP地址返回给公网DNS服务器，最后返回给客户。
6. 客户得到服务IP后，直接访问服务地址，不再经过TM。

有了Traffic Manager，就可以做跨数据中心的服务备份了。以CalculateCloud为例，可以这样设计：在香港和新加坡各部署一个托管服务，然后在香港创建一个Azure Storage账号，并开启RA-GRS。香港的托管服务直接访问Azure Storage主地址，新加坡的托管服务访问Azure Storage主地址来写数据，而读取操作直接访问Azure Storage备份的地址（<accountname>-secondary.table.core.windows.net）。最后，创建一个Traffic Manger，将两个托管服务的地址添加到Endpoint Set中。

这种设计可以在单个托管服务下线时，保持整个系统的可用性。而当整个香港数据中心下线时，系统进入只读运行模式。具体实施步骤如下：

首先把托管服务部署到香港数据中心和新加坡数据中心。为了让新加坡的服务访问Storage备份，还需要更新Default.aspx.cs代码。

        protected void Button2_Click(object sender, EventArgs e)

        {

            try

            {

                var connstr = RoleEnvironment

                    .GetConfigurationSettingValue("DataConnection");

                var storageAccount = CloudStorageAccount.Parse(connstr);

                var tableClient = storageAccount.CreateCloudTableClient();

                tableClient.DefaultRequestOptions.LocationMode =

                    LocationMode.SecondaryThenPrimary;

接下来，登录Azure管理网站，创建一个Traffic Manager。

然后，打开TM的Endpoint配置页，把我之前部署的两个托管服务添加进来。

搞定。Traffic Manager还有很多配置选项，感兴趣的朋友看看MSDN文档吧。

https://msdn.microsoft.com/en-us/library/azure/hh744833.aspx

当然，除了上面的设计方案外，咱还可以在每个数据中心创建单独的Azure Storage，这样即使数据中心故障，服务也完全可用。不过这需要对代码做更多的调整，确保客户访问每个托管服务都能得到一致的结果。

Traffic Manager是个结构简单的服务，它的可靠性保证（SLA）为99.99%。不过根据我的经验，从服务GA到目前为止，零故障。索契冬奥会官方网站的方案就用了TM，当时他们在四个数据中心部署了八个托管服务，用TM做负载平衡。

总结

文章并没有涵盖所有Azure服务，而提到的方案也并非可以套用到所有场景下，这里只当作为抛砖引玉，供大家参考。这里总结一下提到的方法。

另外，高可靠性意味着系统冗余，增加运营的成本和系统复杂度。用户需要在可靠性和各种指标之间找到合适的平衡点。

Azure是微软推出的云服务品牌之一，主要提供IAAS和PAAS服务。在Azure平台建立初期，微软认为PAAS既拥有IAAS的计算功能，同时还比IAAS更容易管理和规模扩展。在这个理念的推动下，微软在Azure平台只推出了一个PAAS层的计算产品：托管服务（Hosted Service）。

托管服务将业务系统中的模块抽象成“角色（Role）”逻辑单元，开发者只需编写每个“角色”的代码，并声明每个角色的运行环境（网络端口，存储）即可。Azure托管服务控制器（FC，或Fabric Controller）会负责分配虚拟机，配置环境和执行角色代码。

逻辑组件和托管服务组件的对应关系

相比于传统系统，托管服务的部署极为简练，并且，服务器的维护交给FC来自动完成。唯一不足之处是：托管服务的开发模型不同于传统Windows系统开发，传统已有程序不能直接运行在托管服务上，而用户要经过一定的学习才能掌握托管服务开发。

using Microsoft.WindowsAzure.ServiceRuntime;
using Microsoft.WindowsAzure.Storage;
using Microsoft.WindowsAzure.Storage.Queue;

        // Submit calculation job.
        protected void Button1_Click(object sender, EventArgs e)
        {
            // read Azure storage connection string from Cloud settings
            var connstr = RoleEnvironment.GetConfigurationSettingValue("DataConnection");

            // create Azure Queue Client
            var storageAccount = CloudStorageAccount.Parse(connstr);
            var queueClient = storageAccount.CreateCloudQueueClient();

            // get queue named "caljobqueue", create if it doesn't exist
            var queue = queueClient.GetQueueReference("caljobqueue");
            queue.CreateIfNotExists();

            // warp user's input into queue message, add to queue.
            string msgstr = string.Format("{0},{1}",
                TextBox1.Text,
                TextBox2.Text);

            queue.AddMessage(
                new CloudQueueMessage(msgstr));

            // all done. Write application log
            System.Diagnostics.Trace.TraceInformation("Message added. " + msgstr);
        }

    public class WorkerRole : RoleEntryPoint
    {
        public override void Run()
        {
            // read Azure storage connection string from Cloud settings
            var connstr = RoleEnvironment.GetConfigurationSettingValue("DataConnection");

            // create Azure Queue Client
            var storageAccount = CloudStorageAccount.Parse(connstr);
            var queueClient = storageAccount.CreateCloudQueueClient();

            // get queue named "caljobqueue", create if it doesn't exist
            var queue = queueClient.GetQueueReference("caljobqueue");
            queue.CreateIfNotExists();

            while (true)
            {
                // get message from queue, if queue is not empty, 
                // it return one message, otherwise, return null
                var msg = queue.GetMessage();
                if (msg != null)
                {
                    // handle job here.
                    var nums = msg.AsString.Split(',');
                    double answer = double.Parse(nums[0]) * double.Parse(nums[1]);

                    string result = string.Format("Job handled. {0}*{1}={2}", nums[0], nums[1], answer);
queue.DeleteMessage(msg);

                    // add applciation log
                    Trace.TraceInformation(result);
                }
                Thread.Sleep(10000);
            }

        }
}

using Microsoft.WindowsAzure.Storage.Table;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Calculate.Worker
{
    public class CalResultEntry:TableEntity
    {
        public string Result { set; get; }
    }
}

        // initialize Table on Role start
        CloudTable _resultTable = null;
        public override bool OnStart()
        {
            // read Azure storage connection string from Cloud settings
            var connstr = RoleEnvironment.GetConfigurationSettingValue("DataConnection");

            // create Azure Table Client
            var storageAccount = CloudStorageAccount.Parse(connstr);
            var tableClient = storageAccount.CreateCloudTableClient();

            // get table named "calresulttable", create if it doesn't exist
            _resultTable = tableClient.GetTableReference("calresulttable");
            _resultTable.CreateIfNotExists();

            return base.OnStart();
        }

        void AddResultEntry(string result)
        {
            // PartitionKey+RowKey is table's primary index, must have
            var newentry = new CalResultEntry
            {
                PartitionKey = DateTime.UtcNow.ToString("yyyyMMdd"),
                RowKey = DateTime.UtcNow.Ticks.ToString(),
                Result = result
            };

            var addOp = TableOperation.Insert(newentry);
            _resultTable.Execute(addOp);
        }

        var nums = msg.AsString.Split(',');
        double answer = double.Parse(nums[0]) * double.Parse(nums[1]);
        string result = string.Format("Job handled. {0}*{1}={2}", nums[0], nums[1], answer);
  AddResultEntry(result);

 ......

        protected void Button2_Click(object sender, EventArgs e)
        {
            var connstr = RoleEnvironment.GetConfigurationSettingValue("DataConnection");
            var storageAccount = CloudStorageAccount.Parse(connstr);
            var tableClient = storageAccount.CreateCloudTableClient();
            var table = tableClient.GetTableReference("calresulttable");
            table.CreateIfNotExists();

            // get today's result form table
            var results = from en in table.CreateQuery<Calculate.Worker.CalResultEntry>()
                          where en.PartitionKey == DateTime.UtcNow.ToString("yyyyMMdd")
                          select en;

            // display result on page
            string resStr = "";
            foreach (var en in results)
            {
                resStr += en.Result + "<br>";
            }
            Label1.Text = resStr;
        }