[转]在 Azure 云服务上设计大规模服务的最佳实践

时间 2019-11-22

标签 azure 服务设计大规模最佳实践繁體版

原文原文链接

本文转自：http://technet.microsoft.com/zh-cn/magazine/jj717232.aspxcss

英文版：http://msdn.microsoft.com/library/azure/jj717232.aspxnode

做者：Mark Simms 和 Michael Thomassy ios

供稿做者：Jason Roth 和 Ralph Squillace web

审阅者：Brad Calder、Dennis Mulder、Mark Ozur、Nina Sarawgi、Marc Mercuri、Conor Cunningham、Peter Carlin、Stuart Ozer、Lara Rubbelke 和 Nicholas Dritsas。 算法

概述

云计算是一种分布式计算，而分布式计算所须要的是缜密的规划和传递，而与平台选择无关。本文档的目的是基于真实的客户案例提供一个成熟的指导方针，以方便客户在 Azure 和 SQL Database 上构建可扩展的应用程序，以及实施平台即服务 (PaaS) 方案，在这种方案中须要借助 Web 角色和辅助角色将应用程序构建成为 Azure 云服务。sql

重要提示
注意：本文中的全部最佳实践指导均源自与在 Azure 上运行生产代码的客户之间的深刻合做。本文仅讨论基于 SDK 1.6 版本的 Azure 云服务 (PaaS) 平台，而不涵盖未来的功能，如 Azure 网站或 Azure 虚拟机 (IaaS)。

本文档介绍有关构建 Azure 应用程序的基础设计概念、关键的 Azure 平台功能、限制和特性，以及使用核心 Azure 服务的最佳实践。重点介绍那些适合松散一致的分布式数据存储区的应用程序（与严格一致或高密度的多租户数据模型相对）。数据库

出于多种缘由，将应用程序和服务的一些环节转换为 Azure 可能颇有吸引力，例如：apache

节省资本支出或将资本支出合并为运营支出（资本支出至运营支出）。
经过更密切地匹配需求和容量来下降成本（并提升效率）。
经过减小或消除基础结构障碍来提升灵活性和缩短上市时间。
提升受众对新市场（如移动设备）的接触面。
经过构建新的应用程序，使它们经过地理上分散的数据中心支持全球受众，从而因云计算的巨大规模而受益。

从技术方面而言，也有许多极好的理由，要求咱们开发新的应用程序或将现有应用程序的某些部分或所有内容移植到 Azure。因为环境具备许多可选的实现方法，所以，你必须仔细地评估你具体的应用程序模式，以便选择正确的实现方法。一些应用程序很是适合 Azure 云服务（这是平台即服务或 PaaS 方法），而其余一些应用程序可能受益于部分或完整的基础结构即服务（或 IaaS）方法，如 Azure 虚拟机。最后，结合使用这二者可能可以最好地知足某些应用程序的要求。windows

你的应用程序应具备如下三个关键环节的一个或多个，以便最大限度地发挥 Azure 云服务的优点。（并不是全部这些环节都须要出如今你的应用程序中；一个应用程序可能只需如下这些环节之一就可以很是充分地利用 Azure，从而带来巨大的投资回报。可是，若是工做负荷没有展示任何这些特性，则它可能并非很是适合 Azure 云服务。）后端

评估应用程序时应考虑的重要环节包括：

弹性需求。过渡到 Azure 的重要价值主张之一是弹性扩展：可以在应用程序中添加或删除容量（缩小和放大）以更密切地匹配动态用户需求的特性。若是你的工做负荷具备静态、稳定的需求（例如，静态的用户数和交易数等），则不能最大限度地发挥 Azure 云服务的这一优点。
分布式用户和设备。在 Azure 上运行使你可以即时访问应用程序的全球部署。若是你的工做负荷是一个在单一位置（如单个办公室）开展工做的固定用户群，则云部署可能没法提供最佳的投资回报。
可分区工做负荷。经过向外扩展，进而在更小的块区中添加更多容量，云应用程序可自如扩展。若是你的应用程序依赖于向上扩展（例如，大型数据库和数据仓库）或者是专业化、专用的工做负荷（例如，大型、统一的高速存储），则必须对其进行分解（分区），以便使在云中运行向外扩展的服务变得可行。根据工做负荷的大小，这一过程可能并不那么简单。

重申一遍：当评估你的应用程序时，若是你的工做负载仅具备在平台即服务环境（如 Azure 云服务）中起重要做用的上述三个环节之一，则过渡到 Azure 云服务或在此类服务之上构造应用程序会带来较高的投资回报。若是应用程序具备全部这三个特性，则你将有望得到很是高的投资回报。

设计概念

尽管为 Azure 设计应用程序的许多环节与内部开发很是类似，但在基础平台和服务的行为方面存在若干关键差别。了解这些差别进而了解如何根据（而不是针对）平台进行设计，对于交付可以在云中实现弹性扩展的应用程序而言是相当重要的。

这一部分归纳了五个关键概念，这些概念对于为平台即服务 (PaaS) 环境（如 Azure 云服务）构建大规模、普遍分布的向外扩展应用程序而言是相当重要的设计点。了解这些概念将帮助你设计和构建知足如下要求的应用程序：它们不只在 Azure 云服务上运行，还能在此类服务上发展壮大，从而使你的投资得到尽量高的回报。本文档后面讨论的全部设计注意事项和选择都会与这五个概念之一有密切联系。

此外，值得注意的是，尽管能够从 .NET 应用程序的角度来查看其中许多注意事项和最佳实践，但基础概念和方法大致上是不区分语言或平台的。

向外扩展而非向上扩展

从内部应用程序转向 Azure 云服务的主要变迁与应用程序如何扩展密切相关。构建较大型应用程序的传统方法依赖于将向外扩展（无状态的 Web 和应用程序服务器）与向上扩展（购买较大的多核心/大内存系统、数据库服务器以及构建较大型的数据中心等）相结合。在云中，向上扩展是一个不太现实的选项；实现真正可扩展的应用程序的惟一途径是明确设计向外扩展。

随着内部应用程序的许多元素已适于进行向外扩展（Web 服务器、应用程序服务器），挑战在于如何肯定应用程序中依赖于向上扩展服务的环节，并将其转换（或映射）到向外扩展实现。向上扩展依赖性的主要候选元素一般是关系数据库 (SQL Server/Azure SQL Database)。

传统的关系设计主要围绕着全局连贯的数据模型（单一服务器向上扩展）以及严格的一致性和事务行为。针对此支持存储区，传统的扩展方法一直是“使全部元素都变得无状态”，并将管理状态的责任推延到向上扩展 SQL 服务器。

不过，SQL Server 的可扩展性虽然很强大，可是缺少真正灵活的扩展。也就是说，它没法提供响应性极高的资源可用性，而是必须购买较大的服务器以及执行代价高昂的迁移阶段，使容量大大超过需求，而且每次都要扩大向上扩展的规模。此外，当扩展之前的中等规模硬件时，成本曲线呈指数上升。

而当 Azure 云服务的基础结构进行扩展时，应用程序须要设计为使用向外扩展数据存储区。这样就会引起一些设计难题，例如，显式将数据分区到较小的块区（每一个块区适合一个数据分区或向外扩展单元）以及管理分布式数据元素之间的一致性。这种经过分区实现扩展的方法，避免了设计为向上扩展的许多缺点。

从众所周知的向上扩展方法转向向外扩展数据和状态管理，一般是针对云进行设计的最大障碍之一；解决这些难题并设计应用程序以充分利用 Azure 云服务和 Azure SQL Database 的可扩展、灵活的功能来管理持久数据，这是本文档中大量内容的焦点。

凡事都有限制：组合以实现扩展

当你运行本身的数据中心时，你具备几乎无限的控制度，同时具备几乎无限的选择。从实际场所（空调、供电、空间）到基础结构（机架、服务器、存储设备、网络等）的任何事物，直至配置（路由拓扑、操做系统安装），一切都在你的控制之下。

这种控制度也带来了各方面的成本 – 资金、运营、人力和时间。在灵活和不断变化的环境中管理全部细节的成本是转向虚拟化的过程的核心，也是转向云的征程中的一个关键环节。做为对放弃控制度的回报，这些平台下降了部署、管理的成本并提升了灵活性。它们所产生的约束在于：可用组件和服务的规模（容量、吞吐量等）限制在必定量以内。

打个比方来讲，商业散装货运主要依赖于集装箱。这些集装箱能够装在各类运输工具（轮船、火车和卡车）上，而且有各类标准尺寸（最长为 53 英尺）。若是你要装运的货物量超过了最大拖车的容量，则你须要：

使用多个拖车。这就涉及到将货物拆分（或分区）以适合装入不一样的集装箱并协调拖车安排。
使用特殊的装运方法。对于没法拆分到多个标准集装箱的货物（太大、太重等），则须要使用高度专业化的方法（如驳船）。这些方法一般要比标准货物装运昂贵得多。

从这个比方能够看出，在 Azure（一般是云计算）中，每种资源都有一个限值。不管是单独的角色实例、存储账户、云服务或甚至是数据中心 – Azure 中的每一个可用资源都具备某种肯定的限制。有些多是很是大的限制，如数据中心内可用的存储空间量（相似于最大的驳船可装运超过 10,000 个集装箱），但它们也是有限的。

有了这个概念后，扩展的方法将是：对负载进行分区，而后拆分组合到多个扩展单元（多个 VM、数据库、存储账户、云服务或数据中心）。

在本文中，咱们使用术语“扩展单元”来指示知足如下条件的一组资源：(a) 处理必定程度的负载；(b) 组合在一块儿来处理附加负载。例如，一个 Azure 存储账户的最大大小为 100 TB。若是你须要存储超过 100 TB 的数据，你将须要使用多个存储账户（也即，至少两个存储扩展单元）。

后面的章节将讨论 Azure 的每一个核心服务或组件的常规容量设计指南，以及用于组合这些服务以实现附加扩展的建议方法。

可用性设计

在内部构建高度灵活的应用程序已投入了大量的时间、精力以及智力资本。一般，这归根结底是将应用程序拆分为低状态组件（应用程序服务器、网络）和高状态组件（数据库、SAN），并使每一个组件可灵活地应对故障模式。

在这一上下文中，故障模式指的是如下二者的组合：(a) 观察到系统处于故障状态；(b) 故障缘由所致使的结果。例如，因为错误地配置了密码更新而致使数据库没法访问就是故障模式；故障状态是没法链接（拒绝链接，不接受凭据），而故障缘由是没法与应用程序代码正确通讯的密码更新。

低状态组件借助于集成到由外部系统管理的系统，经过松散偶合的冗余性来提供灵活性。例如，在负载平衡器以后放置其余 Web 服务器；每一个 Web 服务器与其余 Web 服务器彻底相同（使添加新容量变成只是克隆基本 Web 服务器映像的过程），并集成到由负载平衡器管理的总体应用程序中。

而高状态组件则借助于集成到由组件之间紧密管理的系统，经过紧密偶合的冗余性来提供灵活性。如下是一些示例：

SQL Server。要添加一个冗余的 SQL Server 实例做为主动/被动群集的一部分，要求谨慎地选择兼容（也即彻底相同！）的硬件和共享的存储设备（如 SAN），以便在多个节点之间提供事务上一致的故障转移。
供电。提供冗余的电力是一个很是复杂的示例，这要求多个系统协同发挥做用，以缓解本地（一台服务器多个电源，板载硬件在主电源和辅助电源之间切换）与中心（备用发电机以防断电）范围的问题。

基于紧密耦合方法的灵活性解决方案自己就比松散耦合的“添加更多克隆项”的方法更昂贵，由于前者要求通过良好培训的人员、专门的硬件以及仔细的配置和测试。这不只难以实现，并且实现起来也成本高昂。

这种专一于确保硬件平台高度灵活的方法也可称为“钛金蛋壳”。为了保护蛋里的内容，咱们用一层坚固（但昂贵）的钛金覆上了一层壳。

大范围运行系统的经验（有关进一步的讨论，请参阅 http://www.mvdirona.com/jrh/TalksAndPapers/JamesRH_Lisa.pdf）代表，在任何足够大的系统（如处于 Azure 范围内的数据系统）中，物理上处于运动状态的部件总数致使系统的某些部分始终处于易于破坏的状态。Azure 平台的设计已规避了这一局限性，这种设计不是消除这种局限性，而是依赖于从节点级的故障事件中自动恢复。这种设计意图贯穿全部核心的 Azure 服务，它对于设计可以使用 Azure 可用性模型的应用程序而言相当重要。

转换到 Azure 后，灵活性会话从基础结构冗余性挑战变为服务冗余性挑战。对内部可用性计划起支配做用的许多核心服务在 Azure 中“仅仅维持正常工做”：

SQL Database 自动为你的数据维护多个事务上一致的副本。数据库的节点级故障自动故障转移到一致的辅助副本；请将这种体验的便利性与提供内部灵活性所需的时间和费用进行对比。
Azure 存储自动维护数据的多个一致的副本（要了解详情，请参阅 http://sigops.org/sosp/sosp11/current/2011-Cascais/11-calder-online.pdf）。存储卷的节点级故障自动故障转移到一致的辅助副本。对于 SQL Database，请将这种彻底托管的体验与在内部群集或 SAN 中直接管理灵活存储进行对比。

可是，这一部分的主旨是可用性，而不是灵活性。灵活性只是在 SLA 的范围内持续向用户交付价值的整体过程的一部分。若是服务的全部基础结构组件运行情况均正常，但该服务没法处理预期的用户量，则此服务不可用，也没法交付价值。

以移动设备或社交为中心的工做负荷（如公共 Web 应用程序以及移动设备应用程序）与面向固定受众的工做负荷相比，前者的动态程度要高得多；这种工做负荷要求采用更高级的方法来处理大量突发事件和峰值负载。本文档通篇介绍为 Azure 应用程序设计可用性时要记住的关键概念，这些概念基于如下要点：

Azure 中的每一个服务或组件都提供了某种服务级别协议 (SLA)；这种 SLA 可能并不与运行你的应用程序所需的可用性指标直接关联。了解系统中的全部组件、其可用性 SLA以及它们的交互方式对于理解可提供给用户的整体可用性相当重要。
- 避免出现将致使 SLA 降级的单点故障，如单实例角色。
- 组合或回退到多个组件，以减轻因特定设备脱机或不可用而致使的影响。
Azure 中的每一个服务或组件均可能遇到故障：要么是短时间临时事件，要么是长期事件。你的应用程序应编写为可以从容地应对故障。
- 对于临时故障，提供适当的重试机制以从新链接或从新提交工做。
- 对于其余故障事件，提供丰富的检测机制来处理故障事件（向运营部门报告错误），并向用户返回适当的错误消息。
- 若是可能，能够回退到其余服务或工做流。例如，若是将数据插入 SQL Database 的请求失败（因为非临时缘由，如架构无效），则以序列化格式将数据写入 Blob 存储区。这样，就能够持久捕获数据，并在解决架构问题以后将数据提交到数据库。
全部服务都具备一个峰值容量，要么显式指定（经过限制策略或峰值负载渐近线），要么隐式指定（达到系统资源限制）。
- 将你的应用程序设计为在达到资源限制时从容降级，并采起适当的措施减轻对用户的影响。
- 实施适当的退让/重试逻辑，以免对服务产生“护航”效应。若是没有适当的退让机制，则在经历峰值事件以后，下游服务将始终没有机会遇上正常步伐（由于应用程序将持续尝试将更多负载推动服务中，从而触发限制政策或资源枯竭）。
可能经历快速突发事件的服务一般须要经过舍弃功能来处理超过其峰值设计负载的状况。
- 就像人体在极冷状况下会限制血液流向末端同样，将你的服务设计为在极端负载事件期间舍弃不过重要的服务。
- 此时的必然结果是：你的应用程序所提供的全部服务不能都具备同等的业务重要性，它们能够听从不一样的 SLA。

这些高级概念将在描述核心 Azure 服务的每一个章节中详细说明，同时还有适用于每一个服务或组件的可用性目标以及如何针对可用性进行设计的建议。请记住，数据中心仍然是大型应用程序的单一故障点；从电源错误（请在此处查看示例）到系统错误（请在此处查看示例），基础结构和应用程序问题都会致使数据中心崩溃。要求最高级别正常工做时间的应用程序应部署在多个冗余的数据中心内，但这种状况极为罕见。

在多个数据中心部署应用程序要求若干基础结构和应用程序功能：

（基于地理位置、用户分区或其余关联逻辑）将服务的用户路由到适当的数据中心的应用程序逻辑。
在数据中心之间以适当的延迟和一致性级别同步和复制应用程序状态。
自主部署应用程序，以便最大限度下降数据中心之间的相互依赖（也即，避免数据中心 A 的故障致使数据中心 B 出现故障的状况）。

业务连续性设计

关于可用性，（在数据中心丢失的状况下）提供灾难恢复解决方案须要大量的时间、精力和资金。这一部分将集中讨论在面对系统故障和数据丢失（不管是系统触发仍是用户触发）时提供业务连续性的方法和注意事项，由于术语“灾难恢复”围绕着数据库连续性的实施方法具备特定的含义。

交付业务连续性的过程可分解为：

在发生灾难性基础结构故障时，维护对关键业务系统的访问以及可用性（针对持久状态运行的应用程序）。
在发生灾难性基础结构故障时，维护对关键业务数据的访问以及可用性（持久状态）。
在发生操做员错误或意外删除、修改或损害时，维护关键业务数据的可用性（持久状态）。

前两个元素传统上已在地理灾难恢复 (geo-DR) 的上下文中得以解决，而第三个元素则属于数据备份和数据还原的领域。

Azure 大大改变了关键业务系统可用性的平等分布方式，从而可以快速将关键应用程序部署到地理上分散的全球各数据中心。事实上，发布地理上分布的应用程序与发布单个云服务的过程之间的差别并不明显。

关键的难题仍然是管理对持久状态的访问；跨数据中心访问持久状态服务（如 Azure 存储和 SQL Database）一般会因延迟较高和/或不肯定而致使结果达不到最佳状态，从而在数据中心发生故障时没法知足业务连续性要求。

对于灵活性，许多 Azure 服务提供（或者在其路线图中具备）自动地理复制功能。例如，除非另行专门配置，不然全部写入 Azure 存储（blob、队列或表）中的内容都会自动复制到另外一个数据中心（每一个数据中心在同一个地理区域内都有一个特定的“镜像”目标）。这大大减小了在 Azure 基础之上提供传统灾难恢复解决方案所需的时间和努力。后面的章节概述管理持久状态的核心 Azure 服务的地理复制功能。

为了在面对用户错误或操做员错误时维护业务连续性，在应用程序设计中应考虑若干其余注意事项。尽管 Azure 存储经过“存储分析”功能提供了有限的审核功能（在后面的章节中介绍），但它没有提供任什么时候点还原功能。在面对意外删除或修改时要求灵活性的服务将须要考察以应用程序为中心的方法，如按期将 blob 复制到其余存储账户。

SQL Database 提供了用于维护数据的历史快照的基本功能，包括 DB 复制以及经过 bacpac 导入/导出。本文档后面将详细讨论这些选项。

密度是商品成本

借助于 Azure 平台提供的灵活扩展，供给曲线能够与需求曲线密切匹配（而不是用大量额外容量来知足峰值负载）。

借助灵活扩展，商品成本由如下各因素驱动：

解决方案中利用了多少个扩展单元；虚拟机、存储账户等（组合以进行扩展）
这些扩展单元执行工做的效率如何。

咱们将针对给定容量可执行的工做量称为应用程序的密度。服务和框架的密度越大，针对给定的资源部署执行的工做量就越大；也就是说，提升密度后会减小所部署的容量（和成本），或者可以以相同的部署容量吸取附加负载。密度由两种主要因素驱动：

在一个扩展单元内执行工做的效率。这是传统的性能优化方式 – 管理线程争用和锁、优化算法、优化 SQL 查询。
跨扩展单元协调工做的效率。若是系统由大量的较小单元组成，则将它们高效地结合起来的能力对于实现高效率而言相当重要。这涉及到跨组件进行通讯的框架和工具，如 SOAP 消息传递堆栈（如 WCF）、ORM（如实体框架）、TDS 调用（SQL 客户端代码）和对象序列化（如数据合同或 JSON）。

除了针对单一计算机（或数据库）使用的传统优化方法以外，优化分布式通讯和操做对于交付可扩展、高效的 Azure 服务而言是相当重要的。后面的章节将详细介绍这些关键的优化：

块区并不意味着琐碎。对于每一个分布式操做（也即致使网络调用的操做），针对包组帧、序列化、处理等都有必定量的开销。为了最大限度地减小开销，可尝试批处理为数量较少的“块区”操做，而不是大量“琐碎”的操做。请记住，批处理琐碎的操做的确会增长延迟，并可能致使丢失数据。正确的批处理行为的示例以下所示：
- SQL。在单一批处理中执行多个操做。
- REST 和 SOAP 服务（如 WCF）。利用以消息为中心的操做界面而不是琐碎的 RPC 样式，若是可能，还可考虑基于 REST 的方法。
- Azure 存储（blob、表、队列）。成批（而非单独）发布多个更新。
序列化的影响。在计算机之间移动数据（以及移入和移出持久存储）一般要求将数据序列化为线路格式。此操做的效率（即所需时间和占用的空间）在很大程度上影响了较大型系统的整体应用程序性能。
- 利用高效率的序列化框架。
- 使用 JSON 与设备通讯，或者用于可互操做（用户可读）的应用程序。
- 当你同时控制两个端点时，使用很是高效的二进制序列化（如 protobuf 或 Avro）来进行服务间通讯。
使用高效框架。许多丰富的框架可用于进行开发，它们具备大量高级的功能集。其中许多框架的缺点是你常常会为不使用的功能耗费性能成本。
- 在通用界面以后隔离服务和客户端 API，以便容许替换或并行评估（经过静态工厂或倒置控制容器）。例如，提供一个针对通用界面发挥做用的可插拔 caching 层，而不是特定实现（如 Azure 缓存）。

了解 Azure 云服务

在前一节中，咱们介绍了要构建利用由 Azure 提供的云结构的应用程序，应涉及的关键设计概念和观点。本节将讨论核心平台服务和特性，阐述其功能、扩展边界和可用性模式。

由于每一个 Azure 服务或基础结构组件都经过可用性 SLA 提供有限的容量，因此，了解这些限制和行为对于为你的可扩展性目标和最终用户 SLA 作出适当的设计选择而言相当重要。每一个核心 Azure 服务都体现为如下四个中心环节：功能及其意图、密度、可扩展性和可用性。

Azure 订阅

Azure 订阅是最基本的管理、结算和服务配额单元。每一个 Azure 订阅都具备一组默认配额，旨在防止意外覆盖或占用资源，但你能够经过与支持部门联系来增长这些配额。

每一个订阅都有一个账户全部者和经过 Microsoft 账户（之前称为 Live ID）受权的一组联合管理员，他们经过管理门户对订阅中的资源具备彻底控制权。他们能够建立存储账户、部署云服务、更改配置，并能够添加或删除联合管理员。

Azure 管理 API（基于 REST 的 Web 服务）提供了一个自动执行界面，用于建立、配置和部署 Azure 服务（由管理门户在后台使用）。对这些 API 的访问是使用管理证书来限制的。

服务	默认限制
云服务	20
存储账户	20
Cores	20
SQL Database 逻辑服务器	5

提示
有关最新的 Azure 订阅和服务限制，请参阅 Azure 订阅和服务限制、配额与约束

云服务

Azure 云服务（之前称为托管服务）是基本的部署和扩展单元。每一个云服务都由两个部署（生产和临时）组成，每一个部署具备一组角色。云服务对于生产部署具备公共 DNS 条目（格式为 servicename.cloudapp.net），并具备一个临时部署 DNS 条目（格式为 someguid.cloudapp.net）。

每一个部署都包含一个或多个角色（要么是 Web 角色，要么是辅助角色），它们反过来又包含一个或多个实例（非持久 VM）。每一个实例都包含该角色的软件包的一个彻底相同、不可变、非持久的快照（也即，给定角色的全部实例都部署了彻底相同的内部版本）。这些实例运行 Windows Server 针对 Azure 专门推出的版本（默认状况下为提升安全性禁用了许多服务，配置为与 Azure 网络和服务结构等很好地协做），而且默认状况下由 Azure 结构自动进行修补。实时修补是经过滚动升级方案来处理的，介绍以下。

云服务能够部署到任何 Azure 数据中心，能够直接部署（在建立服务时选择目标区域），也能够经过关联组。关联组是对部署目标的间接引用，而部署目标可用来简化将应用程序的全部组件部署到相同数据中心的过程。

Web 角色预配置了 IIS 实例，该实例承载着应用程序代码。辅助角色中承载的应用程序代码在预配置的长期运行的应用程序主机中执行。每一个云服务可能最多具备 25 个角色。角色默认配置是执行 .NET 代码，但角色可配置为运行与 Windows Server 兼容的任何代码– Java、Python、Ruby、node.js 等等。本文档中提到的全部平台功能均可以从任何平台中得到，但可能要求进行额外的客户端-代理开发以指向基于 REST 的 API。

在云服务内，全部实例都分配有专用 IP 地址（在 10.x 块中）；全部传出链接看起来都是经过网络地址转换来自单个虚拟 IP 地址或 VIP（这是云服务部署的 VIP）。入站链接必须经由已配置的端点；这些端点针对内部角色和端口提供负载平衡的访问。例如，默认状况下，到云服务部署的入站 HTTP/HTTPS（端口 80 和 443）链接针对主 Web 角色的全部可用实例实现了负载平衡。

请注意，跨服务延迟（也即，使 NAT 跨越一个云服务并经过负载平衡器进入另外一个云服务）比内部延迟相比，前者的可变程度要高得多，它是鼓励进行批处理或大批量跨服务链接以实现可扩展性的缘由之一。

Azure 结构还为云服务部署中的全部实例提供了可用的配置服务。服务定义中提供了一组预期的静态配置参数（做为开发周期的一部分），并提供了在将服务发布到 Azure 时随服务一块儿部署的一组初始配置值。这组配置值可用做针对服务部署中的全部实例的运行时查找，能够在运行时经过 REST 接口、Azure 门户或 PowerShell 脚本进行修改。

当更改运行时配置时，全部实例能够选择（在应用程序代码中）挂接配置更改通知并在内部处理配置更新。若是应用程序代码未配置为捕获配置更改事件，则此角色中的全部实例都将遇到滚动从新启动，以更新其配置。

每一个实例的状态都是非持久的；基本 Azure 映像（专门的 Windows Server VM）之上的任何配置都要求启动时配置，以建立性能计数器、优化 IIS 设置、安装依赖软件等等。这些配置脚本一般做为由云服务配置定义的启动任务来运行。

在云服务内部，Azure 结构提供有关配置、内部 IP 地址、服务配置等的信息，而此结构是经过 RoleEnvironment 提供的。在 Azure 实例之上运行的全部进程均可以访问 RoleEnvironment 信息，以检索配置、发现网络拓扑等等。你还能够使用 Azure 管理 API 从外部访问此信息。

升级域和故障域

Azure 结构提出了两个用于管理组件故障、从新配置以及升级/修补的核心概念：升级域和故障域。

升级域是 Azure 服务内的逻辑分组；默认状况下，每一个服务都具备五 (5) 个升级域（能够在云服务定义中修改此值）。任何服务更改或升级一次只影响单一升级域。这些更改的示例包括修补操做系统、更改虚拟机大小、向正在运行的服务添加角色或角色实例、或者修改端点配置。

这样，就能够在保持可用性的同时实时从新配置正在运行的云服务。对于仅包含单个实例的角色，Azure 结构在升级操做期间没法提供可用性，这就是为什么运行单一实例角色没法知足 Azure SLA 的缘由。

故障域是基于基础硬件的逻辑分组。尽管没法保证直接映射到任何特定的硬件配置，但应将逻辑分组视为 Azure 结构自动将实例从表示单点故障（如单一基础物理服务器、机架等）的基础资源中分离的方法。为了知足服务 SLA，Azure 须要至少将实例部署到两个故障域。这是单一实例角色部署没法知足 Azure SLA 的另外一个缘由。

摘要

总结以下：

Azure 中的基本部署和扩展单位是云服务，由一组角色组成。每一个角色都包含一组彻底相同的角色实例，每一个实例运行 Windows Server 的一个特定的云配置版本。
除了物理拓扑（角色和实例）和应用程序代码以外，云服务还定义一个服务范围的配置。此配置能够在运行时更新。
每一个角色实例都是非持久的（更改、文件等都不能保证在从新引导、修补、故障事件中持久存在）。
每一个云服务都同时针对入站和出站通讯公开单个虚拟 IP。云服务公开端点，而端点向内部角色和端口提供（循环法）负载平衡的映射。
Azure 使用升级域在逻辑上划分实例组，并提供滚动更新或修改（同时保持可用性）。
Azure 使用故障域在物理上将实例分组，使之脱离单点故障（如在同一台基础物理计算机上运行全部实例）。
利用多个订阅以隔离部署、测试、临时和生产环境。

计算（角色实例）

每一个角色都包含一组实例（由一个或多个实例组成）。其中每一个实例都是虚拟机，运行 Windows Server 的一个特定版本。实例（虚拟机）当前有五种规模：特别小一直到特别大。其中，每种规模都分配了必定量的 CPU、内存、存储空间和带宽。

虚拟机规模	CPU 内核数	内存	Web 角色和辅助角色的本地存储资源磁盘空间	虚拟机角色的本地存储资源磁盘空间	分配的带宽 (Mbps)
特别小	共享	768 MB	19,480 MB （6,144 MB 预留用于系统文件）	20 GB	5
小型	1	1.75 GB	229,400 MB （6,144 MB 预留用于系统文件）	165 GB	100
中型	2	3.5 GB	500,760 MB （6,144 MB 预留用于系统文件）	340 GB	200
大型	4	7 GB	1,023,000 MB （6,144 MB 预留用于系统文件）	850 GB	400
特别大	8	14 GB	2,087,960 MB （6,144 MB 预留用于系统文件）	1890 GB	800

提示
有关最新的 Azure 订阅和服务限制，请参阅 Azure 订阅和服务限制、配额与约束

当两个或更多实例部署在不一样的故障域和升级域中时，Azure 为云服务提供如下 SLA：

针对面向 Internet 的角色（具备外部端点的角色）提供 99.95% 的外部链接
在两分钟内检测到角色实例问题的概率达到 99.9% 并启动纠正措施

角色实例大小和计数在运行的应用程序中可能动态发生变化（注意，更改角色实例大小将触发滚动从新部署）。在给定用于构建 Azure 应用程序的向外扩展方法的状况下，当须要选择实例大小时，并不是实例越大就必定越好。这一点同时适用于成本（为你不使用的功能付费）和性能（取决于你的工做负荷是 CPU 绑定、I/O 绑定等等）。本文档的“最佳实践”部分将更详细地探讨实例数目和实例大小。

存储

Azure 存储是 Azure 的基线持久数据服务，提供 blob（文件）、队列和表存储（键到值）。存储账户是扩展和可用性的基本单元，同时提供如下功能。与存储设备之间的全部通讯均基于经过 HTTP 的 REST 接口。

提示
有关最新的 Azure 订阅和服务限制，请参阅 Azure 订阅和服务限制、配额与约束

Azure 存储可用性 SLA 保证，在至少 99.9% 的时间内，通过正确格式化的用于添加、更新、读取和删除数据的请求将成功并正确地获得处理，此外，存储账户与 Internet 网关之间保持链接。

在任何状况下使用此单独存储账户都会遵循这些限制；也即，每秒操做数和整体带宽在表、blob 和队列之间共享。若是应用程序超过每秒总操做数，则服务可能返回 HTTP 代码（503 服务器忙）。操做特定于每一个存储环节（表、队列或 blob），下面各小节将介绍这些内容。

根据前面的集装箱比方，每一个存储账户都是一个可提供必定容量的集装箱。超过单个账户（集装箱）的限制就要求在同一个应用程序中利用多个账户。

Azure 存储默认状况下提供了可用性和灵活性；全部写入或更新 Azure 存储的操做都在三个存储节点间透明、一致地复制（这三个节点处于不一样的升级域和故障域中）。对 Azure 存储的访问是以访问密钥方式以单因素身份验证来控制的。每一个存储账户都具备主密钥和辅助密钥，这样就能够在循环主密钥时实现持续可用性。Azure 存储中的数据可自动经过地理复制而复制到“镜像”数据中心（除非使用门户专门禁用此功能）。地理复制是不透明的，在主数据中心出现故障的状况下，利用 DNS 重定向将客户端故障转移到辅助位置。

请注意，尽管 Azure 存储经过自动化副本提供了数据复原功能，但这不会防止你的应用程序代码（或开发人员/用户）由于意外或无意的删除、更新等操做而形成数据损坏。在遇到应用程序或用户错误时保持数据保真须要更为先进的技术，如将数据和审核日志复制到辅助存储位置。Blob 存储提供了快照功能，这一功能可在 blob 内容的时间快照中建立只读点，这可用做 blob 的数据保真度解决方案的基础。

Azure 存储经过其存储分析功能提供了遥测功能，同时收集和公开有关针对表、队列和 blob 的单独存储调用的使用状况数据。须要使用收集策略（收集全部内容、仅搜集表等等）和保留策略（保留数据的时间长度）针对每一个存储账户启用存储分析。

Blob

Blob 存储在 Azure 中提供了文件管理服务，同时提供可用性高、经济高效的方法来存储成批的未结构化数据。此服务提供两种类型的 blob：

块 blob。块 blob 用于高效地管理大型数据 blob。每一个块 blob 由多达 50,000 个块组成，每一个块最大可达 4 MB（总的最大块 blob 大小为 200 GB）。块 blob 支持并行上载，以便经过网络高效和并发移动大型文件。能够插入、替换或删除各个块，但没法进行就地编辑。
页 blob。页 blob 旨在高效提供随机的读/写操做（如访问 VHD）。每一个页 blob 的最大大小为 1 TB，由 512 字节的页面组成。能够添加或更新单个页面或一组页面，并能够就地覆盖。

下表中列出了 blob 存储的设计限制。请记住，全部这些操做都针对整体存储账户限制进行计数。

Blob 类别	限制
最大 blob 大小（块）	200 GB（50k 个块）
最大块大小	4 MB
最大 blob 大小（页）	1 TB
页大小	512 字节
最大带宽/blob	480 Mbps

当超出单个 blob 的大小或带宽限制后，应用程序能够写入多个并发（或序列）blob 文件。若是你的应用程序超出单个存储账户的限制，请利用多个存储账户以提供更多容量。

队列

Azure 队列在发布服务器与订阅服务器之间提供中间（中转）消息传递服务。队列支持多个并发发布服务器和订阅服务器，但自身并不公开较高顺序的消息传递基元（如发布/订阅或基于主题的路由）。它们一般用于将工做项（如消息、文档、任务等）分发到一组辅助角色实例（或在多个托管服务等之间分发这些工做项）。

若是应用程序未检索和删除队列消息，则 7 天后将自动删除这些消息。它们在信息的发布服务器与使用方之间提供解除关联功能；只要双方都具备存储账户密钥和队列名称，它们就能够通讯。

队列类别	限制
队列中的最大消息数	无（最大为存储账户限制）
消息的最大生存期	1 周（自动清除）
最大消息大小	64 kB
最大吞吐量	每秒高达 500 条消息

队列旨在传递控制消息，而非原始数据。若是你的消息过大而没法放入一个队列中，则能够重构消息以便分离数据和命令。将数据存储在 blob 存储中，添加对存储在队列消息中的数据和意图的引用 (URI)（意图也即 blob 存储中的数据的用途）。

为了提升单个队列中的吞吐量，请在单一消息内批处理多条消息，而后利用“更新消息”命令来跟踪封装消息的任务的进度。另外一种方法是将多条消息放入一个 blob 中，并由一个指针指向队列消息中的 blob。

若是你的应用程序须要的吞吐量高于单个队列所能提供的吞吐量，则利用多个并发队列。在这一上下文中，你的应用程序必须实现适当的分区和路由逻辑。

表

Azure 表存储为列（二维）数据提供了持久性高、可扩展性高且一致的存储区。它提供了 { partition key, row key } -> { data[] } 语义以存储和访问数据，以下图中所示。每一个表都按分区进行分解，而分区中包括实体。每一个实体都有其本身的（平面）架构或属性列表（列）。

每一个分区每秒支持高达 500 个操做；反过来，每一个表最高支持存储账户中提供的最大操做数。由于每一个实体不只包含实际数据，还包含列元数据（由于每一个实例可能具备不一样架构），因此不建议采用长列名，尤为对于大型方法。

表类别	限制
每一个分区每秒最大操做数	500
最大实体大小（列名 + 数据）	1 MB
最大列大小（byte[] 或字符串）	64 kB
最大行数	无（最大为存储账户限制）
支持的数据类型	byte[]、Boolean、datetime、double、Guid、int3二、int6四、string

各实体（你能够将其视为行）的最大大小为 1 MB，各列的最大大小限制为 64 kB。上表中列出了支持的数据类型；对于不支持的类型（如 DateTimeOffset），你的应用程序代码中须要一个序列化代理（例如，以标准字符串格式存储 DateTimeOffset）。

表存储使用与分区和实体、分区扫描或实体扫描关联的键来提供对所存储数据的访问。它支持筛选器投影，由于筛选表达式能够做为查询的一部分推送到表存储，并在表存储中执行。表存储不提供辅助索引，所以，任何非基于分区键或实体键的查找都要求进行表扫描和/或分区扫描。对于包含大量实体的分区，这一般对性能有重大影响。

任何超过 5 秒的查询处理都会返回一个继续标记，而应用程序能够使用此继续标记来继续接收查询的结果。检索的实体数超过 1,000 的查询必须利用分页模型，以便将数据返回到包含 1,000 个实体的块中（表存储 API 自己就支持块）。

目前对于表存储支持的惟一查询表达式是筛选和选择（选择特定属性）；表存储不提供服务器端聚合或分组语义。为了构建要求丰富的聚合或分析功能的应用程序，一般更好的选择是以聚合格式存储数据或使用关系引擎（如 Azure SQL Database）。某些应用程序采用混合方法，将表存储中的数据聚合到一个辅助 SQL Database 中，而后用于查询和报告目的。

选择适当的分区函数对于高效和有效地利用表存储而言相当重要。对于分区函数的类型，有两种主要选择：

时间。经常使用于存储时间序列数据，如 Azure 诊断性能计数器（本文档的遥测部分中介绍了用法），基于时间的分区函数将当前时间转换为表示时间窗口的值（当前分钟、小时等）。
这样，就能够高效地查找和定位特定分区（由于表存储的筛选子句支持 >=、<= 等等），但若是所选时间窗口太窄而且发生了峰值事件，则容易受到限制。例如，若是所选分区函数是当前分钟值并发生了峰值事件，则过多的客户端可能尝试并发写入同一个分区。这不只影响插入时的吞吐量，并且影响查询时的吞吐量。
数据。以数据为中心的分区函数基于要存储（或检索）的数据的一个或多个属性来计算分区值。选择适当的数据驱动的分区函数取决于几个因素：查询模式、分区密钥密度（分区中最终用了多少个实体）以及没法预测的增加（这对于使很是大的表从新达到平衡多是个挑战）。常见模式包括：
- 单一字段。分区键是源数据中的单一字段（如订单信息中的客户 ID）。
- 多字段。分区键或行键是源数据中多个字段的组合（一般是串联）。当选择分区键时，请注意，批处理操做要求全部实体位于同一个分区中（也即具备相同的分区键）。
- 计算字段。分区键是基于一个肯定性函数从一个或多个字段计算得出的。一个常见的示例是将用户配置文件分配到多个分区中。将使用为实现相对统一的分配而设计的哈希函数来对用户 ID 进行哈希处理，而后针对所需分区的数量进行取模。

任何重要的应用程序都要求使用多个分区。甚至对于具备总实体数中少许实体的表（如 200 个实体），若是应用程序每秒将发出几千个请求，则须要用多个分区才能知足吞吐量要求。

单一表/单一分区。最简单的选项（恒定的分区键值），可知足小规模的工做负荷、有限的数据量以及请求吞吐量要求（< 500 个实体/秒）。
单一表/多个分区。大多数部署的典型选项；认真选择与目标查询模式匹配的分区键。
多存储账户/多分区。若是负载投影超过每秒 5,000 个操做，则要求跨多个存储账户使用表。

一旦选择，则数据达到从新平衡（从新分区）可能会很是昂贵，这涉及读取和复制具备新分区键的全部实体，而后删除旧数据。请注意，分区没有最小大小限制；分区能够由单个实体（也即行）组成。

若是你的应用程序须要的吞吐量高于单一表所能提供的吞吐量（在仔细选择分区以后），请在不一样的存储账户中利用多个并发表。在这一上下文中，你的应用程序须要实现适当的路由逻辑，以便选择适当的存储账户。

内容传送网络 (CDN)

Azure 内容传送网络 (CDN) 提供了一种高效的方法，在全球分布的缓存网络中缓存静态内容（从 blob 或应用程序输出）。这会减轻应用程序传送静态内容的压力，并改进整体最终用户体验。

内容传送网络可用性 SLA 确保按月以 99.9% 的可用性传送缓存的对象。

使用 CDN 要求为你的订阅激活此功能。在此，能够缓存 blob 内容（来自公开提供/匿名访问容器）和匿名应用程序输出内容（例如 http://www.myapp.com/cdn/somepage.aspx）。

一般，对于任何大规模的应用程序，全部常访问的静态内容（图片、css 等等）都应经过 CDN 并借助适当的缓存到期策略来进行传送。

例如，考虑一个具备一百万册书的在线电子书商店。在 CDN 中包括全部图书的内容（图片等）将会很是昂贵（由于绝大多数内容都不会频繁访问而且会持续过时），而只加入前面的内容（例如，前 50 本图书）将使缓存与价格之间达到最佳组合。

Azure 诊断

成功传送大规模服务的核心元素之一是遥测，也即深刻了解应用程序的操做、性能和最终用户体验。Azure 应用程序的遥测方法须要同时考虑平台的向外扩展/分布式性质，以及可用于收集、分析和使用遥测的平台服务。

Azure 中用于收集和理解遥测的基本计数组件是 Azure 诊断 (WAD)。WAD 由一个代理以及一组用于存储和访问数据的标准结构和约定组成，而代理负责从各个实例收集数据并将它们转发至一个中心收集点（存储账户）。代理支持若干配置方法，包括代码 (.NET)、在部署的项目代码内嵌入的配置文件或部署到 blob 存储的集中化的配置文件。配置在最后的实例中必定程度上是动态的，以便容许将更新后的诊断文件推送到 blob 存储，而后向下拉取到目标代理。

WAD 配置面向若干数据源而提供；其中每一个数据源都按期进行收集、经过用于 Windows 的事件跟踪（称为 ETW）会话进行批处理，并发布到目标存储账户。代理负责处理临时链接问题、重试等其余事项。可用数据源以下所示：

性能计数器。捕获到本地 ETW 会话并按期暂存至表存储中的性能计数器值的子集（CPU、内存等）。
Windows 事件日志。捕获到本地 ETW 会话并按期暂存至表存储中的 Windows 事件记录（应用程序、系统等等）的子集。
Azure 日志。应用程序代码（经过 System.Diagnostics.Trace）发布并由 DiagnosticMonitorTraceListener 跟踪侦听程序捕获的应用程序日志（跟踪消息）。这些日志将发布到目标存储账户的“WAD 性能计数器”表中。
IIS 7.0 日志。关于 IIS 记录的请求的标准 IIS 日志信息（仅限 Web 角色）。日志将收集到本地文件中，并按期暂存至 blob 存储区。
IIS 失败请求日志。来自 IIS 的关于失败请求的信息，这些信息将收集到本地文件中，并按期暂存至 blob 存储区。
崩溃转储。系统一旦崩溃，即捕获关于操做系统状态的日志并发布至 blob 存储区。
数据源。WAD 能够监视更多本地目录（如本地存储区中的日志目录），并按期将这些数据复制到 blob 存储区的自定义容器中。

以上每种数据源都配置有要收集的数据子集（例如，性能计数器列表）以及收集/发布时间间隔。还能够经过一些 PowerShell 脚原本更改运行时配置，或强制从代理向目标存储账户当即发布数据。

重要提示
将遥测数据记录到单独的存储账户中。将遥测数据和应用程序数据记录到同一存储账户中将致使大规模的严重争用问题。

SQL Database

Azure SQL Database 提供数据库即服务，支持应用程序快速设置关系数据库、向其中插入数据以及查询该数据库。它提供许多熟悉的 SQL Server 功能，同时减小了硬件、配置、修补和复原方面的负担。

备注
SQL Database 并不提供与 SQL Server 一一对应的功能，其目的在于知足专门适用于云应用程序的一套不一样的要求（经过弹性扩展、数据库即服务来下降维护成本等）。有关详细信息，请参阅 http://blogs.msdn.com/b/windowsazure/archive/2012/06/26/data-series-sql-server-in-windows-azure-virtual-machine-vs-sql-database.aspx。

该服务运行在多租户共享环境中，其中的数据库来自基于商用硬件构建的基础结构上运行的多个用户和订阅（横向扩展，而非纵向扩展）。

数据库设置在逻辑服务器内部；每一个逻辑服务器默认包含最多 150 个数据库（包括 master 数据库）。默认状况下，每一个订阅能够设置五 (5) 个逻辑服务器；但经过调用支持能够提升此限额以及每一个逻辑服务器包含的最大数据库数。

每一个逻辑服务器都分配有一个公共的惟一辈子成的 DNS 名称（格式为 [服务器名称].database.windows.net），订阅中的每一个逻辑服务器都共享同一个公共 IP 地址。经过标准的 SQL 端口 (TCP/1433) 访问逻辑服务器（和数据库），同时经过基于 REST 的管理 API 访问端口 TCP/833。

默认状况下，限定只能根据针对 Azure 管理门户的基于 IP 的防火墙规则来访问逻辑服务器及其中的全部数据库（能够针对逻辑服务器或单个数据库设置规则）。若要支持访问 Azure 应用程序以及从 Azure 外部直接链接应用程序（例如，链接 SQL Server Management Studio），须要配置防火墙规则。能够经过 Azure Web 管理门户使用管理服务 API 调用来配置这些规则。

SQL Database 提供 SQL Server 中现有的多数关键功能，但也有一些重要的例外状况，包括：

全部表都必须包含 CLUSTERED INDEX；在定义 CLUSTERED INDEX 以前不能将数据 INSERT（插入）SQL Database 中的表。
没有内置的公共语言运行时 (CLR) 支持、数据库镜像、Service Broker、数据压缩或表分区功能。
没有 XML 索引；不支持 XML 数据类型。
不支持透明数据加密 (TDE) 或数据审核。
不支持全文搜索。

每一个数据库在建立时，都配置了大小上限。当前可用的容量上限包括 1 GB、5 GB、10 GB、20 GB、30 GB、40 GB、50 GB、100 GB 和 150 GB（当前可用的最大容量）。当数据库达到大小限制时，它会拒绝其余 INSERT 或 UPDATE 命令（仍然能够查询和删除数据）。还能够经过发出 ALTER DATABASE 命令来建立数据库大小（增大或缩小）。

因为要依据天天使用的平均大小对数据库计费，预计快速增加或增加不可预测的应用程序能够选择将数据库最大容量最初设置为 150 GB。将数据库扩展至 150 GB 以上须要利用横向扩展方法，下一节将对此进行详细介绍。

SQL Database 为节点级别的故障提供内置的故障恢复功能。全部写入数据库的内容会使用仲裁提交技术自动复制到两个或多个背景节点（主要副本和至少一个辅助副本必须先确认活动写入事务日志，而后才将事务视为成功并返回）。在节点失败时，数据库会自动故障转移到其中一个辅助副本。这将致使客户端应用程序出现暂时性链接中断，这就是为什么全部 SQL Database 客户端都必须执行某种形式的暂时性链接处理的主要缘由之一（请参阅下文，了解有关执行暂时性链接处理的详细信息）。

月度可用性 SLA 要求 99.9% 的正常运行时间，即要求可以在 5 分钟的时间间隔内于 30 秒内链接到 SQL Database。上一段中所述的故障转移事件一般出现的时间不超过 30 秒，这更加迫切地须要你的应用程序可以处理暂时性链接故障。

SQL Database 经过动态管理视图 (DMV) 提供关于数据库运行情况和性能的深刻分析信息；这些 DMV 包含有关系统主要方面的信息，如查询性能、数据库和表大小等。应用程序负责按期自主要 DMV 收集和分析信息，并将其整合到范围更大的遥测和洞察框架中。

有若干业务连续性（备份、恢复）选项可用于 SQL Database。数据库能够经过数据库复制功能或 DAC 导入/导出服务进行复制。数据库复制提供业务一致的结果，而 bacpac（经过导入/导出服务）则不会提供业务一致的结果。这两个选项都做为数据中心内基于队列的服务来运行，而且当前都未提供完成时间 SLA。

请注意，数据库复制和导入/导出服务都会给源数据库带来至关大的负载，而且可能触发资源争用或限制事件（在下文中的“共享资源和限制”一节中介绍）。因为以上两种方式都不能提供 SQL Server 支持的同等程度的增量备份，因此当前正在预审一项用来启用时间点恢复功能的新功能。时间点恢复功能容许用户将其数据库恢复到近两周之内的任意一个时点。

当前惟一支持的身份验证方法就是 SQL 身份验证，这是一种基于数据库中已注册用户的单因素用户名/密码登陆方式。Active Directory 或双因素身份验证功能尚不提供。极力推荐使用 ADO.NET、ODBC 等接口中现有的内置加密支持对 SQL Database 链接加密。数据库级权限与 SQL Server 的权限一致。有关设置 Azure SQL Database 安全性的详细介绍，请参阅在 Azure SQL Database 中管理数据库和登陆名。

SQL Database 提供一套功能齐全的动态管理视图，可用于观测查询性能和数据库运行情况；但并未提供用来收集和分析这些数据的自动化基础结构（同时也未提供直连式事件探查器和操做系统级别的性能计数器等用户熟悉的工具）。用于收集和分析的方法在本文档的“遥测”一节中介绍。

共享资源和限制

如上所述，SQL Database 是一种运行在共享基础结构之上的多租户服务。来自不一样租户的数据库共享基于商用硬件构建的底层物理节点。其余系统用户能够使用同一底层基础结构之上的关键资源（工做线程、事务日志、I/O 等）。资源的使用要接受监管，这样即可将数据库限定在既定的资源限定范围以内。一旦超出这些限制，在租户或物理节点级别，SQL Database 就会停止使用或断开链接。这些限制列在下表中。

资源	每一个事务/会话的最大值	每一个物理节点的最大值	软停止限制	硬停止限制
工做线程	N/A	512	305	410
数据库大小	每一个数据库配置的最大容量为 150 GB	N/A	无	100%；达到限值后不接受插入或更新
事务日志增加	每一个事务 2 GB	500 GB	N/A	N/A
事务日志长度	总日志空间 (100 GB) 的 20%	500 GB	N/A	N/A
锁计数	每一个事务一百万	N/A	N/A	N/A
阻止系统任务	20 秒	N/A	N/A	N/A
临时数据库空间	5 GB	N/A	N/A	5 GB
内存	N/A	N/A	N/A	16 MB/20 秒
最大并行请求数	每一个数据库 400 个请求	N/A	N/A	N/A

一旦达到事务限值，系统就会取消该事务。一旦数据库达到软停止限制，事务处理和链接的速度就会减慢或停止。一旦达到硬停止限制，底层物理节点上的全部数据库（和用户）都会受到影响，致使终止现有操做而且阻止新操做或链接，直到资源使用量降低到停止阈值之下。

以上有些停止限制致使应用程序的设计和性能限值可能不直观。例如，限制事务日志增加到每一个事务最大 2 GB 将阻止针对大型表构建索引（由于构建索引将生成超过 2 GB 的事务日志）。本文档的“最佳实践”一节会介绍关于执行此类操做的方法。

处理这些类型的限制条件和暂时性错误要求慎重设计和实施客户端代码；解决这些问题须要横向扩展数据库层，以便同时利用多个数据库（下一节将介绍横向扩展）。

SQL 客户端应用程序代码应该：

实施能够识别与限制有关的 SQL 错误代码的重试代码，并提供相应的退让逻辑。若是应用程序中不存在某种形式的退让逻辑，数据库可能因不断地承受峰期负载而被锁定在持续限制状态。
记录限制错误，用重试代码来区分暂时性链接、限制和硬故障 - 语法、缺失存储过程等。这将有助于跟踪和解决应用程序可用性问题。
实施断路器模式。适当选择的重试策略一旦失效（针对应用程序的重试频率权衡滞后时间与系统响应），需调用某一代码路径来处理非暂时性错误（即断路器脱扣）。应用程序代码随后能够：
- 回退到另外一服务或方式。若是应用程序未能将新数据插入 SQL Database（而且这些数据不须要即时可用），那么这些数据可改成序列化为 DataTable 中的数据（或其余 XML/JSON 格式），并写入 blob 存储区中的文件。该应用程序随后可能向用户（或 API 调用）返回成功代码，稍后再将这些数据插入数据库。
- 经过返回 Null 值无提示失败（若是数据或工做流是可选的，即不影响最终用户体验）。
- 经过返回错误代码快速失败（若是未提供有用的/适当的回退机制）。

基于横向扩展的交付

SQL Database 能够轻松交付大量的相对较小的扩展单元（数据库）。利用 SQL Database 在 Azure 上实施高度可扩展的应用程序要求采用横向扩展方式，结合使用多个数据库的资源来知足变化莫测的需求。以往应用程序都是面向“钛金蛋壳”（即单个纵向扩展的高度灵活的数据库服务器）来设计，而今须要经过周密的设计实现应用程序转型，使其可以高效利用横向扩展的数据库服务。

和其余 Azure 核心服务同样，对于 SQL Database，横向扩展和组合是进一步的扩展（数据库大小、吞吐量）和资源（工做线程等）利用的关键所在。有两种核心方法可实施 SQL Database 的分区/分片（进而实施横向扩展）；这两种方法在一个应用程序内部并不互斥：

水平分区。在水平分区方法中，完整的表或数据集被分隔到各个数据库中。例如，对于为不一样客户群服务的多租户应用程序，该应用程序能够为每一个客户都建立一个数据库。对于大型单租户应用程序，客户表能够位于与订单表不一样的数据库中。分区键一般就是租户标识符（例如，客户 ID）。在下图中，数据集水平分区到三个不一样的数据库中，以通过哈希处理的电子邮件做为分区值（即，分区键是电子邮件，分区函数使用这个通过哈希处理的键映射到目标数据库）。
垂直分区。在垂直分区方法中，数据集根据架构分区分布在多个物理表或数据库中。例如，客户数据和订单数据可能分布在不一样的物理数据库中。在下图中，数据集垂直分区到两个不一样的数据库中。核心用户信息（姓名、电子邮件）存储在 DB1 中，用户配置文件信息（如虚拟形象图片的 URI）存储在 DB2 中。

许多应用程序都混合使用水平分区和垂直分区（混合分区），此外还会归入其余存储服务。例如，在上例中，用户的虚拟形象图片做为 ID 存储在数据库中，而应用程序会将其展开为完整的 URL。此 URL 随后会映射到 blob 中存储的图像。

在使用横向扩展的关系数据存储区时，可用性的计算极为不一样。在分片数目较多的系统中，某个数据段脱机的几率较高，而整个应用程序不可用的几率要低得多。应用程序还需考虑到后端数据存储区不彻底可用的状况。利用横向扩展数据模式，数据再也不是要么彻底可用，要么彻底不可用。

对数据从新分区可能有些难度，特别是在使用模式或数据分布随时间变化的状况下。基于范围的分区键，不管是基于固定数字（使用通过哈希处理的分区值的模数）仍是基于分区值的分布，都要求在各个分片之间从新平衡分布数据。基于范围的分区方案每每利用二进制拆分或合并来简化从新平衡操做。

例如，固定范围的分区方法（如姓氏首字母）可能最初是平衡分布的，但随着新用户的出现（用户各有各的姓氏，而这些姓氏在字母表中不必定均匀分布），其分布可能迅速转变为高度失衡。须要谨记：随着时间推移，可能要根据须要调整分区机制和从新平衡数据的成本。

基于查找的分区方案实施难度更大，每一个数据租户或分区都须要高性能的查找机制，但因为这些方案容许逐个将单个租户从新平衡分布到新分区，因此更适用于细化的从新平衡。这些方案还支持向系统添加更多容量（新数据库等），而无需复制数据。

不管如何搭配使用分片方法，移至横向扩展的分片关系数据库都带有特定的限制，要求采用不一样的数据管理和查询方法：

以往，“良好”的 SQL 数据存储和查询设计都利用高度规范化的数据模型进行了存储和一致性方面的优化。这种方法假定利用交叉引用和表间 JOIN（联接）造成了全局一致的数据空间。但随着数据分布到物理上分散的多个节点上，JOIN 和交叉引用仅在单个分片内适用。SQL Database 不支持多个数据库上的分布式查询；须要在客户端层处理数据合并，而且在分片之间进行数据的非规范化处理和复制。
引用数据和元数据一般都被集中到引用表中。在横向扩展方法中，这些引用表以及公共分区键没法分隔的全部数据都须要在分片之间复制并保持一致。
因为没有切实可行的方法在分片之间提供可扩展、高性能的分布式事务，因此数据（乃至架构更新！）永远不可能在分片之间保持事务上的一致性。应用程序代码需认定分片之间存在必定程度的松散一致性，并将其做为一种考虑因素。
应用程序代码须要了解分片机制（是水平分区仍是垂直分区）才能链接正确的分片。
经常使用的 ORM（如实体框架）自己并不了解横向扩展数据模型；普遍利用大型 ORM 的应用程序可能须要大规模从新设计才能与水平分片兼容。对于以垂直分片法将租户（客户集）隔离到单个数据库的设计，一般在数据访问层所需的从新设计较少。纯垂直分片模型的缺点是：每一个单独分片的容量受单个数据库容量的限制。
须要访问（读取或写入）多个分片的查询要使用散播-汇集模式来实施，这种模式将针对目标分片执行各个查询，随后在客户端数据访问层聚合结果集。

要横向扩展 SQL Database，须要将数据手动分区或分片到多个 SQL Database 上。这种横向扩展方法可随着扩展实现几乎线性的成本增加；但若是须要，弹性增加或按需扩容所需的成本可呈增量式增加。并非全部应用程序都须要通过大规模从新设计才支持这种横向扩展模式。

不能保证架构更新在事务上的一致性，特别是在更新大量分片时。应用程序要么须要接受计划的停机期间，要么可以处理多个并行的已部署架构版本。
业务连续型流程（备份/恢复等）须要可以处理多个数据分片。

用于解决这些难题的设计建议和最佳实践在本文档的“最佳实践”一节中介绍。

最佳实践

下文中侧重于依据现实世界中的经验和从这些经验中汲取的教训，介绍使用 Azure 和 SQL Database 交付高度可扩展应用程序的最佳实践。每项最佳实践都讨论目标优化和组件、实施方法和固有的优缺点。和任何其余最佳实践同样，这些建议高度依赖于它们的适用环境。根据上一节所述的平台功能评估每项最佳实践的适用性。

备注
这些经验是从一些未听从典型 OLTP（联机事务处理）模式的客户项目中总结出来的。务必要意识到：有些最佳实践不能直接套用在要求较强或较严格的数据一致性的应用程序上；只有你本身了解你应用程序及其环境的确切业务要求。

每项最佳实践都将与一个或多个方面的优化有关：

吞吐量。如何增长经过系统的操做（事务、服务调用等）的数量，以及如何减小资源争用。
滞后时间。如何缩短聚合和单个操做上的滞后时间。
密度。在直接上下文（例如，SQL Database 的应用程序代码）和聚合上下文（利用多个存储账户以提升扩展性）环境中编写服务时，如何减小争用点。
可管理性。诊断、遥测和洞察 - 如何理解大规模部署的服务的运行情况和性能。
可用性。如何经过减少故障点和模式的影响来提升总体应用程序可用性（availability-under-load 将在吞吐量/滞后时间/密度部分中介绍）。

云服务

托管服务是 Azure 中的基本扩展单元，因此周密地设计和部署托管服务是提供高度可扩展的可用服务的关键。

托管服务中的实例和升级域数量可能极大影响部署、配置和升级托管服务所需的时间。须要在性能和可扩展性优点与这些优点所带来的复杂性之间权衡利弊。提升可扩展性和灵活性每每会增长解决方案的开发和管理成本。
避免单实例角色；此配置不符合 Azure SLA 要求。在节点发生故障或执行升级的过程当中，单实例角色将脱机。因此只应将单实例角色限制用于优先级较低的“维护”任务。
每一个数据中心都具备有限（尽管较大）的容量，能够在极少数状况下用做单个故障点。要求最高级别扩展和可用性的服务必须实施支持多个托管服务的多数据中心拓扑结构。可是：
若是不须要最高级别的可用性（请参阅上一个条目），应确保应用程序和依赖服务彻底包含在单个数据中心内。在解决方案必须使用多个数据中心的状况下，请遵循如下原则：
- 避免为实时操做（专门的跨站点同步操做除外）执行跨数据中心网络调用。数据中心之间的长时间延迟变数极大，可能产生意外或用户不但愿出现的应用程序性能问题。
- 只准备好访问其余数据中心中的服务所需的最基本的功能。一般，这些活动与业务连续性和数据复制有关。

分布式 Caching

对于大型分布式应用程序，对有状态应用程序数据的访问相当重要。应用程序的总体吞吐量和滞后时间一般取决于检索、共享和更新所需数据和上下文的时间能有多快。为了知足此类需求，Azure Caching 和 Memcache 之类的分布式缓存服务应运而生。应用程序应利用分布式缓存平台。请考虑如下原则：

利用分布式缓存平台，将其做为你托管服务中的辅助角色。缓存的这种邻近客户端特性减小了负载平衡器遍历所形成的延迟和吞吐量障碍。Azure Cache 上的角色中缓存在云服务内的辅助角色上承载缓存。
将分布式缓存平台用做访问经常使用应用程序数据和对象（例如，用户配置文件和会话状态）的主存储库，而且由 SQL Database 或其余持久性存储区提供通读或缓存预留支持。
缓存对象都有生存时间，该时间影响它们在分布式缓存中的有效期。应用程序要么对缓存对象明确设定生存时间，要么为缓存容器配置默认生存时间。应该在可用性（缓存命中率）与内存压力和数据陈旧程度之间权衡生存时间的选择。
缓存具备 key->byte[] 语义；应注意可能产生重叠写入，形成缓存中的数据不一致。分布式缓存一般不会为存储数据的原子更新提供 API，由于缓存没法识别存储数据的结构。
- 对于要求并发写入严格一致的应用程序，请使用为更新实体提供锁定机制的分布式缓存平台。对于 Azure Caching，能够经过 GetAndLock/PutAndUnlock 来实现。注意：这将对吞吐量产生负面影响。
缓存性能在应用程序层上受限于序列化和反序列化对象所需的时间。若要优化此过程，请利用相对对称（数据编码/解码所需时间相同）、高效的二进制序列化程序，如 protobuf。
- 若要成功使用自定义序列化，请设计要在缓存中序列化的数据传输对象 (DTO)，对序列化使用正确的批注、避免循环依赖，并利用单元测试跟踪高效序列化。

链接关联

默认状况下，各个服务层之间的链接（包括经过负载平衡器传入的链接）要以循环方式分配，但链接次数有限。如下各图演示了各层与外部服务之间造成的典型链接网（左侧演示典型的仅限 Web 层的应用程序）。尽管该链接网没有为轻型链接协议（如 HTTP）显示任何重大性能问题，但有些链接要么因成本太高而没法链接/初始化，要么就是管制（受限）资源。例如，SQL Database 链接就属于这一类链接。要优化这些外部服务和组件的使用，强烈建议你针对特定实例关联资源调用。

在上述关系图中，右边的拓扑具备位于同一托管服务内的单独 Web 层和辅助层（角色）。此拓扑还实现了 Web 层和应用程序层的关联，以未来自特定应用程序实例的调用固定到特定数据库。例如，要从数据库 1 (DB1) 请求数据，Web 实例必须经过应用程序实例 1 或 2 请求数据。由于 Azure 负载平衡器当前只实现了循环技术，在你的应用程序中提供关联并不要求进行认真设计和实现。

使用单独的 Web 层和应用程序层设计应用程序，在 Web 层和应用程序层之间实现分区或资源级关联。
实现将内部服务调用透明路由到目标应用程序实例的路由逻辑。使用外部或下游资源（如 SQL Database）使用的分区机制知识。

此多层体系结构的实际实现要求在 Web 层和应用程序层之间使用轻型协议进行高效的服务通讯。

计算和应用程序代码

Azure 应用程序的开发技术与 Windows Server 的开发技术没有本质不一样。可是，前者的弹性结构更须要利用最高效使用计算资源的代码，也更能发挥其优点。

假定全部服务、网络调用和从属资源可能不可靠，致使暂时性故障（例如，本主题下面将介绍如何实现 SQL Database 的重试逻辑）：
- 对全部服务调用（SQL Database、存储等）实现合适的重试策略以处理暂时性故障和链接丢失问题。
- 在重试逻辑中实现退让策略以免“护航”效应（对延长中断时间的服务累积的重试）。
- 实现富客户端遥测以便记录包含上下文信息（目标服务、用户/账户上下文、活动等）的错误消息和故障事件。
不要直接建立线程来计划做业；请利用现有计划和并发框架（如 .NET 任务并行库）。线程是相对重型的对象，一般不宜建立和释放。针对共享线程池工做的计划程序能够更高效计划和执行做业。此体系结构还提供更高级的语义来描述持续和错误处理。
为序列化和网络传输优化数据传输对象 (DTO)。若是 Azure 应用程序是高度分散的，则可扩展性受系统的各个组件在网络上通讯的效率影响。在通讯或存储的网络上传输的任何数据应采用带适当提示的 JSON 文本序列化或更高效的二进制格式，以尽量减少网络上传输的元数据量（如线路上更短的字段名称）。
- 若是注重互操做，请使用高效的文本格式（如 JSON）以支持互操做性和带内元数据。
- 若是注重高吞吐量（如在你控制两端的服务到服务通讯中），请考虑采用高效打包的二进制格式（如 bson 或 protobuf）。
  - 避免频繁进行小对象的数据传输。服务之间的频繁通讯会将大量系统资源浪费在管理开销任务上，致使变量延迟响应。
  - 序列化和反序列化对象的测试应是自动测试框架的核心组成部分。功能测试确保数据类可序列化，且没有循环的依赖关系。性能测试验证所需的延迟时间和编码大小。
实际实施时，将轻型框架用于组件和服务之间的通讯。.NET 堆栈中的不少传统技术提供了丰富的功能集，可是该功能集可能不知足分布式 Azure 的要求。提供意图和执行间高度抽象的组件可能严重影响性能。
- 若是你不要求协议互操做性或高级协议支持，请考虑使用 ASP.NET Web API 替代 WCF 来实现 Web 服务。
- 若是你不要求实体框架具备丰富功能，请考虑使用微型 ORM（如 Dapper）来实现 SQL 客户端层。
经过容许将 IIS 中的 HTTP 压缩用于出站数据，减小从数据中心传送的数据量。
关联层之间的链接以减小链接的频率和上下文切换次数。
要减少应用程序的负载，请使用 blob 存储区来存储较大的静态内容 (> 100 kB)。
要减少应用程序的负载，请使用借助 blob 存储区的内容传送网络 (CDN) 来传送静态内容（如图像或 CSS）。
避免将 SQL Database 用于会话数据。请改用分布式缓存或 cookie。

存储

Azure 存储是 Azure 应用程序中耐用的数据支柱。尽管能够提供高度可靠、可扩展的“开箱”体验，可是大型应用程序须要遵循适当的设计和使用准则。

利用多个存储账户可得到更大的可扩展性，不管是增大大小 (> 100 TB) 仍是实现更大的吞吐量（每秒 > 5,000 个操做）。确保你的应用程序代码能够配置为使用多个存储账户，使用适当的分区函数将做业路由到存储账户。将添加更多存储账户的功能设计为配置更改而非代码更改。
谨慎选择表存储的分区函数，以在确保插入和查询性能的前提下支持所需的规模。将基于时间的分区方法用于遥测数据，使复合键基于非时间数据的行数据。使分区大小处在最佳性能的合理范围内；分区太小将限制执行批处理操做的能力（包括查询），分区过大则使查询成本很高（可能致使大量并发插入的瓶颈）。
- 分区函数的选择也将从根本上影响查询性能；表存储方式提供按 {分区键, 行键} 的高效查找，可是处理 {分区键, 行匹配筛选器} 和 {分区键匹配筛选器, 行键匹配筛选器} 的效率不高。查询要求全局表扫描 ({行键匹配筛选器})。
- 分区能够像单个实体这样小；这为纯查找工做负荷（如购物车管理）提供了通过优化的性能。
尽量在存储区中将操做进行批处理。表写入应进行批处理，一般经过使用 .NET 客户端 API 中的 SaveChanges 方法来实现。将一系列行插入表，而后在一个批处理中使用 SaveChanges 方法提交更改。对 blob 存储区的更新也应使用 PutBlockList 方法成批提交。与表存储 API 同样，针对一个块范围调用 PutBlockList 而非使用单个 blocks。
为表属性选择短列名；由于元数据（属性名称）在带内存储。列名也算在最大行大小 1 MB 内。过长的属性名称会浪费系统资源。

SQL Database

如“了解 Azure”一节中所述，SQL Database 将整个关系数据库做为服务功能提供，支持以向外扩展的方式对数据存储区进行访问。在大型应用程序中成功使用 SQL Database 要求进行几个谨慎的设计和实现选择；本节将介绍一些重要的设计点和最佳作法。

不少应用程序须要使用元数据表存储诸如路由、分区和租户信息之类的详细信息。将此元数据存储在单个数据库中会致使单个故障点以及没法进行扩展。中央元数据存储区应经过结合使用如下方式向外扩展：

激进缓存：配置数据库中的信息应激进缓存到分布式缓存（如 memcache 或 Azure Caching）。
- 请注意在应用程序启动时积极尝试从多个工做线程预加载缓存的影响，这一般致使过分加载和数据库限制。若是你的应用程序须要预加载的缓存，请将加载数据的工做委托给具备可配置加载速度的专用辅助角色（或计划的任务）。
- 若是应用程序性能或可靠性依赖于缓存中是否具备某段数据，你的应用程序应拒绝传入的请求，直到预先填充了缓存。填充数据后，应用程序应返回相应的错误消息或代码。
向外扩展：按垂直（按表）或水平（跨多个分片的段表）方式对数据进行分区，以将负载分配到多个数据库。

已分区的 SQL Database 的整体可扩展性受单个数据库（分片）的规模以及这些分片组合起来以增大规模的效率的影响：

由于事务日志限制了较大的事务（如重建索引），单个表大小不该超过约 10 GB（请注意这个实际限制取决于目标表索引的大小，所以对于你的数据库该值可能大于也可能小于 10 GB）。对于大的单个表，请将它拆分为较小的几个表，并使用分区视图来提供统一覆盖。
- 保持小的单个表能够减少分阶段升级过程当中架构更改或索引重建的影响。对多个较小表的更改能够尽量减少因为阻塞操做形成的停机时间和延迟时间。
- 这个分区方式使管理技术复杂化。诸如重建索引等操做必须以迭代方式在全部组件表上执行。
使单个数据库（分片）足够小。一些持续操做（如针对 50 GB 以上数据库的数据库复制或导出）可能须要几小时才能完成（服务取消操做须要运行 24 小时以上）。

进行连续服务交付、管理分布式数据库更新或架构修改时，须要当心谨慎以确保顺利升级。在生产数据存储区中控制架构和元数据操做的全部传统最佳作法比以往更为重要。例如，在 100 个数据库中的某个数据库调试和解决意外删除的存储过程是个比以往复杂得多的任务。

由于架构更新和数据修改在分片上不是事务一致的，在过渡期应用程序更新必须同时兼容旧架构和新架构。这个要求一般表示应用程序的每一个版本必须至少与架构的当前版本和上一个版本兼容。

链接管理

转换到数据库的向外扩展集合会带来一些与链接管理有关的问题。每一个 SQL 数据库链接是相对昂贵的资源，这已由客户端 API（ADO.NET、ODBC、PHP 等）中链接池的普遍使用所证明。每一个应用程序实例并不维护多个与中央 SQL Server 的链接，而是必须潜在维护与多个数据库服务器的链接。

由于链接是昂贵可能希缺的资源，应用程序必须经过及时退回池中链接来正确管理链接。应用程序代码应使用自动链接释放机制；在 .NET 中，最佳作法是在 using 语句内封装 SqlConnection 的全部使用，例如：

using (var conn = new SqlConnection(connStr)) { // SQL client calls here }

如前文所述，针对 SQL Database 的链接受暂时性链接故障的影响。必须对全部链接和命令使用重试逻辑，以避免受这些暂时性故障的影响（有关其余详细信息，请参见下文）。

SQL Database 只支持 TCP 链接（而非命名管道），强烈建议你加密应用程序代码和 SQL Database 之间的链接。要阻止无心识的链接尝试（如尝试使用命名管道），应用程序应按如下方式设置其 SQL 链接字符串格式：

Server=tcp:{servername}.database.windows.net,1433;Database={database};User ID={userid}@{database};Password={password};Trusted_Connection=False;Encrypt=True;Connection Timeout=30;

对于大型应用程序部署，托管的服务部署和 SQL Database 群集内 SQL Database 逻辑服务器（每一个服务器具备单独的外部 IP 地址）之间的潜在默认链接数可能以指数级增加。例如，对于包含 100 个实例、50 个数据库的托管服务，在 ADO.NET 中默认链接数为 100 个链接。

MaxConnections=DatabaseCount*Instance Count*MaxConnectionPoolSize

请参考托管服务的网络拓扑；链接的每一个端（托管服务和 SQL Database 逻辑服务器）依赖 Azure 负载平衡器存活。. 每一个 Azure 负载平衡器在任意两个 IPv4 地址之间最多具备 64k 个链接。此网络拓扑与默承认用链接数的组合致使较大的应用程序出现严重的网络故障。

将较大的应用程序部署在多个托管服务上。
在多个订阅中部署数据库（不只是同一订阅中的多个逻辑服务器）能够得到更为惟一的 IP 地址。
实现多层应用程序以将出站操做关联到针对的应用程序实例（请参见有关托管服务的上一节）。
请记住链接池根据每一个惟一链接字符串来维护并对应于每一个惟一的数据库服务器、数据库和登陆组合。使用 SQL 客户端链接池并显式限制 SQL 链接池的最大大小。SQL 客户端库根据须要重用链接；小链接池可能致使应用程序在等待链接可用时延迟时间增长。

如下列表提供有关减小所需活动链接数的建议：

架构和查询设计

转换到分布式数据模型可能须要更改数据库架构的设计以及更改某些查询类型。要求跨多个数据库使用分布式事务的应用程序可能具备不合适的数据模型或实现（例如，尝试强制实施全局一致性）。这些设计必须重构。

因为可用性和可扩展性的限制，使用中央序列生成工具时应避免应用程序的任何不寻常的方面。不少应用程序利用序列提供全局惟一标识符，使用中央跟踪机制根据须要增大该序列。这个体系结构致使了一个全局争用点和瓶颈，系统的每一个组件都须要与之交互。此瓶颈对于可能断开链接的移动应用程序更为突出。

所以，应用程序应利用可在分布式系统中生成全局惟一标识符（如 GUID）的函数。根据设计 GUID 不是按顺序的，所以在做为大表中的汇集索引时它们可能致使碎片。在大数据模型中为了减少 GUID 的碎片影响，请将数据库分片，使得每一个分片相对较小。这容许 SQL Database 在副本故障转移期间对数据库自动整理碎片。

采用分布式数据模型时客户端应用程序代码必须考虑如下几个方面：

分区键：分区键应是每一个数据类或模型的一部分，并可能使用属性进行修饰以容许发现分区键。
遥测：数据访问层应自动记录有关每一个 SQL 调用的信息，包括目标、分区、上下文、延迟和全部错误代码或重试。
分布式查询：执行跨分片查询将引入几个新问题，包括路由、分区选择和部分红功的概念（一些分片成功返回了数据而另外一些分片则没有返回数据）。数据访问层应提供委托来以异步（并行）散播-汇集方式执行分布式查询，返回组合结果。分布式查询还须要考虑限制基础资源：
- 最大并行度（以免线程过多，链接压力过大）。
- 最长查询时间（以减少长时间运行的查询的整体延迟时间或下降分片速度）。

还有几个必须执行的管理任务：

引用表：没有提供全局连贯的查询空间，查询中 JOIN 的引用数据必须复制到每一个分片。要求维护并复制数据到每一个分片的引用表，以提供足够一致的本地引用数据。
从新平衡分区：单个分片可能成为不平衡的，它们可能占用过多资源并成为阻塞点，也可能由于使用率低下而浪费资源。在这些状况下，必须从新平衡分区以从新分配资源。从新平衡机制在很大程度上依赖于分区策略和实现。在大多数状况下从新平衡一般涉及：
- 将一个分片内的现有数据复制到一个或多个新分片，能够经过拆分/合并机制（对于基于范围的分区）或使用实体级复制和从新映射（对于基于查找的分区）。
- 更新分片映射以指向新分片，而后补偿在过渡期间写入旧分片的全部数据。
数据删除：随着应用程序数据的增加和收集，考虑按期删除旧的未使用的数据，以增长主系统的可用空间和容量。删除的数据不是以同步方式从 SQL Database 清除的，而是将它标记为删除，由后台进程进行清理。将数据标记为删除的经常使用方法是使用一个标记列，它能够表示行为活动、不活动或已标记为删除。这能够阻止在一段时间查询数据，若是用户指示仍须要数据，数据能够轻松移回生产系统。
删除数据还能够触发碎片，可能须要索引重建以确保查询操做的效率。较旧的数据能够存档到：
- 一个在线存储区（辅助 SQL Database），这增长了主系统的空间可是没有下降成本。
- 一个离线存储区（如 blob 存储区中的 bcp 或 bacpac 文件）；这增长了主系统的空间而且下降了成本。
- 位存储桶。你能够选择从主系统永久删除数据以增长空间。

暂时性错误处理和退让

SQL Database 中的几个常见事件能够触发暂时性链接故障，如副本故障转移。应用程序必须实现相应的代码来处理暂时性故障并正确应对资源用尽和限制：

使用重试机制处理暂时性链接故障：数据访问代码应利用策略驱动的重试机制来应对暂时性链接故障。重试机制应检测临时链接故障，从新链接到目标 SQL Database 并从新发出命令。
使用重试和退让逻辑处理限制：数据访问代码应利用策略驱动的重试和退让机制来应对限制状况。重试机制应检测限制状况并逐渐退让尝试以从新发出命令（以免可能延长限制状况的“护航”效应）。
- 数据访问代码还应能够实施退让到备用数据存储区，如 blob 存储区。这个备用存储区为捕获活动、数据和状态，避免在出现延长的限制或可用性事件时数据丢失提供耐用的机制。

.NET 应用程序可以使用可识别 SQL Database 的重试和退让逻辑框架，如云应用程序框架 (CloudFx) 或企业库暂时性故障处理程序。这些框架提供经常使用数据访问类（如 SqlConnection 和 SqlCommand）以及可直接调用的策略的包装。

var retryPolicy = RetryPolicy.Create<SqlAzureTransientErrorDetectionStrategy>(
    retryCount: 3, 
    initialInterval: TimeSpan.FromSeconds(5),
    increment: TimeSpan.FromSeconds(2));
                
using (var conn = new ReliableSqlConnection(connStr)) { conn.Open(); using (var cmd = conn.CreateCommand()) { } conn.Close(); }

上一个代码段演示在 SQL Database 上工做时如何使用 CloudFx ReliableSqlConnection 类来处理暂时性链接错误。

应用程序/客户端遥测

请注意记录对服务的 API 调用（如 SQL Database），由于可能出现复杂的故障状况。尝试捕获一些重要的上下文和性能信息。例如，全部 SQL Database 会话携带会话标识符，它可用于支持电话中，帮助直接隔离基本问题。强烈建议对于全部写入 SQL Database 日志的调用、命令和查询，记录：

服务器和数据库名称。因为可能有数百个数据库，目标服务器对于跟踪和隔离问题相当重要。
根据须要记录 SQL 存储过程或命令文本。请注意不要在日志文件中泄露敏感信息 – 一般避免记录命令文本。
调用的端到端延迟。经过使用 Stopwatch 或另外一轻型计时器在计时委托中包装调用。
调用的返回代码（成功或失败）以及重试次数和失败缘由（链接已删除、被限制等）。
链接的会话 ID，可经过 CONTEXT_INFO() 属性（使用 ReliableSqlConnection 时为 SessionTracingId 属性）访问。可是，对于每一个客户端调用请不要从 CONTEXT_INFO() 检索会话 ID 属性，由于此命令触发另外一个到服务器的往返。

批处理和异步执行

为了更高效使用 SQL Database，针对 SQL Database 的查询和数据插入应尽量进行批处理和以异步方式执行。这不只提升了应用程序效率，并且减少了 SQL Database 上的整体系统负载（容许更大的吞吐量）。

成批插入。对于连续数据插入操做（如注册新用户），数据应针对目标分片进行批处理和对齐。这些批应基于触发器按期（异步）写入 SQL Database，如目标批大小或时间窗口。对于小于 100 行的批大小，表值函数一般比大容量复制操做效率更高。
避免聊天式界面。减少执行一个查询或一组操做所需的到数据库的往返次数。聊天式界面具备很高的管理开销，它加大系统负载，下降吞吐量和效率。请尝试合并相关操做，一般使用存储过程来减小往返次数。

业务连续性和数据维护

做为保持业务连续性整体方案的一部分，在 SQL Database 中存储的数据应按期导出 blob 存储区。Blob 存储区默认状况下支持可用性和地理复制。

实现一个用于将数据库按期导出到 blob 存储区的计划任务。使用专用存储账户。此任务应在目标数据库所在的数据中心中运行，而不是从内部桌面或服务器运行。

将导出任务安排在系统活动低的时间，以尽量减少对最终用户体验的影响。导出多个数据库时，请限制并行导出的程度以减少系统影响。

SQL Database 遥测

了解你的 SQL Database 的运行情况、性能和容量是影响整体服务交付的关键因素。SQL Database 经过动态管理视图提供所需的原始信息，可是当前没有用于捕获、分析和报告关键度量值的现成基础结构。要为 SQL Database 提供此功能，请考虑如下作法：

实现一个按期任务来收集与系统负载、已用的资源（工做线程、存储空间）和传入公共存储库的数据有关的关键性能数据。例如，考虑 Azure 诊断使用的表。此任务必须从属于你的应用程序的全部数据库收集数据。收集一般以向外扩展的方式执行（即同时从多个数据库收集数据）。
实现按期任务以汇总此信息，得到有关你部署的数据库的运行情况和容量的关键性能指标。

遥测和诊断

Azure 诊断提供收集应用程序和实例级遥测数据的基线。可是，要了解在 Azure 上运行的大型应用程序的情况须要认真配置和管理数据流。与能够利用丰富的 Windows 诊断实用工具的集中式向上扩展应用程序不一样，向外扩展的分布式系统中的诊断必须在系统投入运行前实现 – 它们不可能过后再考虑。

错误处理、上下文跟踪和遥测捕获对于了解错误事件、根本缘由和解决方法是相当重要的。

不要将活动站点数据和遥测数据发布到同一存储账户。请为诊断使用专用存储账户。
为块式（高容量、高延迟、粒状数据）和聊天式（低容量、低延迟、高值数据）遥测建立单独的通道。
- 将标准 Azure 诊断源（如性能计数器和跟踪）用于聊天式信息。
- 使用通用的日志记录库（如企业应用程序框架库 log4net 或 NLog）来实现大容量记录到本地文件。使用诊断监视器配置中的自定义数据源将此信息按期复制到 blob 存储区。
记录对外部服务的全部 API 调用，记录的信息包括上下文、目标、方法、计时信息（延迟）和结果（成功/失败/重试）。使用块式记录通道以免诊断系统充斥大量遥测信息。
将写入表存储区的数据（性能计数器、事件日志、跟踪事件）写入时长 60 秒的时间分区。尝试写入过多数据（过多点源、太低的收集间隔）可能填满此分区。请确保错误尖峰信号不触发对表存储区的大量插入尝试，由于这可能触发限制事件。
- 选择要从这些源收集高值数据，包括关键性能计数器、严重/错误事件或跟踪记录。
- 选择合适的收集间隔（5–15 分钟）以减小必须传输和分析的数据量。
确保能够在运行时修改日志记录配置，而没必要强制执行实例重置。还要验证配置的粒度足以支持记录系统的特定方面，如数据库、缓存或其余服务。

Azure 诊断不提供从属服务（如 SQL Database 或分布式缓存）的数据收集。要提供应用程序及其性能特征的综合视图，请添加基础结构来收集从属服务的数据：

收集从属服务的关键性能和使用数据，并将它们做为性能计数器记录发布到 WAD 存储库。
- Azure 存储（使用 Azure 存储分析）。
- SQL Database（使用动态管理视图）。
- 专用缓存（使用性能计数器或运行情况监视 API）。
按期分析原始遥测数据来建立聚合和汇总（以计划的任务形式）。