设计强大的云应用程序
当我向开发人员谈及将应用程序作为产品开发与作为服务开发之间的区别时，他们纷纷投来异样的目光。您在本地编写的应用程序将写入您所购买且已在您个人所有的计算机硬件上安装和配置的软件中。而在云中编写的应用程序将写入一系列可供您和公众使用的服务中。现在我们来探讨一下这两者之间有何不同。
当您为本地服务器编写应用程序时，您对此硬件和软件集满怀期待。您期望每次登录都能成功连接。您掌控着此服务器上运行的应用程序，因此您期望其性能水平保持不变。您了解并掌控着数据的安全性上下文。您亲手配置软件和硬件，因此您期望在出现问题时，只需看一下事件记录便可大概猜出原因。在大多数情况下，您对您个人所有、管理和维护的服务器上应用程序的行为了如指掌。而另一方面，您也清楚，如果超出此服务器的计算能力，则必须转向其他能力更强的系统配置。相反，如果事实证明服务器的计算能力比应用程序实际需要的大，则说明您浪费了计算能力，需要将其他工作负荷迁移到该服务器上，以便更好地利用您所拥有的计算能力。最后，如果容量全部得到利用并开始运行，则需要维护硬件和软件。由于这些原因 - 当然这并非全部原因 - 当您希望降低整体计算成本时，您可能会考虑云计算。
现在，您决定迁移应用程序或在云中构建应用程序。您在云中具有的功能与在本地相同，例如：身份验证服务、应用程序服务（缓存、消息传递等）、数据库服务和可用性服务等等。与此同时，您还拥有巨大的新机遇，例如，您可以按需扩展，并享受硬件商品即付即用带来的成本效益。如果需要，您还可按照类似于编写本地应用程序的方式将这些应用程序作为服务开发，这在大多数情况下均行之有效。
但是，构建强大的云应用程序还得多花点功夫。
要最大限度地提高为 Windows Azure 编写的云应用程序的性能、可扩展性和可管理性，需精心构造和编码，以利用云平台的独特功能。例如：
- 在编码过程中始终捕获应用程序远程控制信息，以便主动实时响应应用程序行为。
- 利用计算和存储节点的扩展功能扩大规模，或利用多个数据中心提高可用性。如果将应用程序设计为在部署新“规模单元”（计算、存储和数据库组）时增长，即可配置计划内和计划外的增长。
- 在确保应用程序可继续运行的前提下，容许任何单个组件故障。世界上最出色的云应用程序可以做到这一点，但还需要您在编写应用程序时牢记以下理念，即能够预测潜在组件故障并在不对最终用户造成严重影响的情况下实时响应停机情况。
- 尽可能利用缓存来检索数据，并通过在多个单独的数据库（碎片）之间分散处理数据库请求来支持可扩展性，并最大程度地提高性能。
为了帮助大家快速开始学习如何编写强大的云应用程序，本博客将介绍七个可复用云组件，并提供示例代码和文档。这些组件几乎适用于在 Microsoft Windows Azure 平台上开发的任何 PaaS 应用程序。
我们做了什么： AzureCAT（Microsoft 客户工程咨询团队）参与了成百上千个 Azure PaaS 应用程序的设计、构建和部署工作。我们从中受益良多，并决定编写和分享以下七个可复用组件，让其他人明白我们所说的作为服务编写是什么意思。我们将这些组件作为一整个端到端应用程序来编写，确保它们能够无缝工作。这个应用程序本身相当简单，即让用户注册、登录并发表评论。它已经过需要添加遥测功能和分区代码规模的构建和测试，以保证良好性能。
编写 PaaS 应用程序的人都可从这七个可复用组件的示例代码和文档中受益。这些组件包括：
- 配置 – 配置文件是实现应用程序无缝管理的关键
- 记录 - 记录应用程序、事件和性能遥测
- 数据访问 – 这实际上是两个组件：a) 数据库命令和连接重试逻辑；b) 使用自定义哈希算法进行分区
- 缓存 – 将用户数据写入缓存/从缓存中读取用户数据
- 调度 - 实时收集遥测数据并将其移至 SQL Azure 中自定义 ops 数据库的后台worker role
- 报告 – 报告 SQL Azure ops 数据库中收集的遥测
- 应用程序请求路由 (ARR) – 用于将用户路由到多个托管服务（应用程序工作负荷平衡）的 IIS 技术
以下是此材料的链接 – 应用程序代码已发布到 MSDN 代码库：
- Windows Azure 中的云服务基础：
- https://code.msdn.microsoft.com/Cloud-Fundamentals-in-1a3ab1bd
总结：本博客仅介绍了基本信息，之后将发布另外几篇博客，更详细地介绍各个组件。如果您阅读本博客后认识到编写强大的云应用程序需要编写代码，以充分利用云服务，本博客便达到目的了。这些示例代码是真实存在的且可正常工作（即共同发挥作用）。这些示例代码源自真实世界中的实现，并已经过大规模测试。
本文翻译自：