在 Windows Azure 上设计大型服务的最佳做法
编者注：今天的帖子来自于Jason Roth，主编程作家。他提供了来自我们的客户咨询团队的新白皮书的概述，涉及在Windows Azure上 设计大型服务的最佳做法。我们最近发行了新的白皮书：在Windows Azure 云服务上设计大型服务的最佳做法。这份文件汇集了基于实际的客户约定的设计模式和指导方针。它结合了最好的策略和设计模式，始终如一地证明了真实世界的 Windows Azure 应用程序的成功。
首先要了解这个平台
当您阅读这个白皮书，你会注意有三个主要部分：
· 设计概念
· 探索 Windows Azure
· 最佳做法
您可能被诱惑去直接浏览最佳做法，但您应该意识到这些最佳做法源自前两节中的信息。每个应用程序是唯一的。首先去了解 Windows Azure 平台和基本的设计原则是很重要的。这对选择正确的优化以及实现正确的执行都有帮助。
好的设计 — — 值得努力
任何大型的应用程序设计需要认真思考、 规划和潜在地复杂的执行。 对Windows Azure而言，最基本的设计原则是扩展。而不是投资在功能强大 （且昂贵） 的硬件上，扩展策略通过添加更多的机器或服务实例响应不断增加的需求。
对于每个Windows Azure服务而言，许多最佳做法涉及实现扩展。例如，在Windows Azure中，不能放大运行在您的 SQL 数据库上的服务器。相反，您必须设计应用程序用来利用额外的 SQL 数据库实例。这涉及到对你的数据的某些类型的分区策略。
当然，面临的挑战是选择正确的分区策略，并成功地协调分区之间的工作。本文试图为您提供你所做选择的技术性理解和过去客户方案的实际建议。
请注意，分区提高了可扩展性，SQL 数据库是只是很明显的例子。但是要最大化平台的优势，其他角色和服务必须以类似的方式扩展出。例如，存储帐户的交易率是有上限的，虚拟机的 CPU 和内存有上限； 最大限额通过多个存储账户的使用、组件扩展出虚拟机设定尺寸的服务来实现。
虽然可伸缩性是设计背后的驱动力，还有其他非常重要的设计注意事项。文件强调，必须对遥测和诊断数据收集做规划，这个变得越来越重要，因为您的解决方案变得更多组件化和分区化。可用性和业务连续性是本文的两个其它的主要焦点。当您的服务出现故障或者不可避免地丢失数据，扩展性就与此无关了。
最佳做法和平台演化
Windows Azure 不断演变、 改进和增加新的服务。在最近的版本中，已经增加了新的功能，例如 Windows Azure 虚拟网络和基础设施作为一种服务 （IaaS）。这些新功能给大型应用程序提供了更多的选择。然而，这份文件重点关注版本1.6，并不包括添加到平台的一些最新的特征。
要了解这个决定的原因，您必须重新审视这项工作的目标。这篇文章将会提供在真实客户实践中成功的设计指导。因为这些服务可能需要数月计划、 测试和循环，在这篇文章更新了最新的服务和功能之前，它将会花费一些时间。但所有文件中的设计原则仍然适用，而且同一类型的思维可以应用于Windows Azure 的任何新功能。
继续，我们正在处理额外的文件、 代码示例和说明，演示如何执行一些最佳的做法。
不是一个核对表
每个人都喜欢核对表。思想是： 如果你可以选择所有的选框，然后你知道你将会成功。有了在 Windows Azure 云服务上设计大型服务最佳做法，不要把这些信息看作一个核对表。您的应用程序是唯一的。或许，在这个时刻，您的应用程序是"中等-高"的规模。有可能当你理解了平台和最佳做法后，只有一些建议在短时间内对你来说是至关重要的。但展望未来，规划你将会需要一些或所有的其他设计策略的可能性。
核对白皮书，在下面的评论区域分享你的反馈。
本文翻译自：
