第十二章 共定位模式
这种基本模式旨在避免不必要的网络延迟。
节点之间的通信速度在节点距离较近时更快。距离会增加网络延迟。在云环境中，“距离较近”指的是位于同一数据中心（有时甚至更近，例如位于同一机架）。
节点位于不同数据中心也有其合理之处，但本章重点在于确保应该位于同一数据中心的节点确实位于同一数据中心。意外地将节点部署在多个数据中心可能会导致应用程序性能严重下降，并因数据传输费用而造成不必要的成本增加。
这适用于运行应用程序代码的节点（例如计算节点）以及实现云存储和数据库服务的节点。它还涵盖相关决策，例如日志文件的存储位置。
背景
托管模式有效应对以下挑战：
- 一个节点频繁使用另一个节点，例如计算节点访问数据库
- 应用程序部署较为简单，只需一个数据中心
- 应用程序部署较为复杂，涉及多个数据中心，但每个数据中心内的节点频繁使用其他节点，这些节点可以托管在同一数据中心内
一般来说，彼此高度依赖的资源应该托管在一起。
多层应用程序通常包含一个 Web 或应用服务器层，该层会访问数据库层。为了最大限度地降低这些层之间的网络延迟，通常需要将它们托管在同一数据中心内。这有助于最大限度地提高这些层之间的性能，并避免云服务提供商的数据传输成本。
此模式通常与代客密钥模式和 CDN 模式结合使用。偏离此模式的原因，例如靠近用户和整体可靠性，将在多站点部署模式（第 15 章）中讨论。
云的重要性
公有云平台通常提供遍布全球的众多数据中心，应用程序可以轻松部署到这些数据中心。这些数据中心横跨各大洲，有时甚至在同一大洲内也有多个数据中心。应用程序可以轻松部署到任何一个数据中心，并使用其中的云平台服务。这种多数据中心灵活性带来了巨大的优势，但也带来了风险：应用程序代码和服务可能会不必要地分布在多个数据中心，从而导致额外的成本和用户体验下降。
影响
成本优化、可扩展性、用户体验
机制
仔细想想，这似乎是一个显而易见的模式，而且在很多方面确实如此。根据公司硬件基础设施的结构（无论是私有数据中心还是租用的空间），除了将数据库和访问它们的服务器托管在一起之外，可能很难做其他事情。
对于公共云提供商，通常会在多个大洲提供多个数据中心，有时甚至每个大洲或地区都有多个数据中心。如果您计划部署到单个数据中心，则可能有多个合理的选择。这既是好消息也是坏消息，因为您可以选择任何数据中心作为部署目标（而且很容易）。这样，就可以将数据库部署到一个数据中心，而将访问该数据库的服务器部署到另一个数据中心。
对于数据密集型应用程序而言，这种拆分部署可能会造成严重的性能损失。
自动化助力
强制执行托管并非技术难题，而是流程问题。不过，自动化可以有效缓解这一问题。
您需要采取积极措施，避免意外地将部署分散到不同的数据中心。将部署自动化到云端是一个良好的实践，因为它可以减少重复性任务中的人为错误。如果您的应用程序跨越多个数据中心，但每个站点基本独立运行，则需要添加检查以确保数据访问不会意外地跨越数据。
除了自动化之外，您的云平台可能还具有一些特定功能，可以降低托管错误发生的概率。
成本考量
如果您的数据库和访问它们的计算资源位于同一数据中心，运营成本通常会更低。将它们分开则会产生成本影响。
截至撰写本文时，亚马逊云服务 (AWS) 和 Windows Azure 平台不会对进入数据中心的网络流量收费，但会对离开数据中心的网络流量收费（即使是前往他们自己的另一个数据中心）。数据仅在单个数据中心内传输时，不会产生流量费用。
非技术因素
应用程序架构可能受到非技术因素的影响，导致数据库的存储位置与访问它们的计算资源的位置不同。此主题将在多站点部署模式（第 15 章）中进一步讨论。
示例：在 Windows Azure 上构建 PoP
最初开发 Page of Photos (PoP) 应用程序（前言中已介绍）时，将其部署在单个数据中心内并使用云服务是合理的。
Windows Azure 允许您为任何可部署到特定数据中心的资源指定目标数据中心。例如，可以为代码部署（例如 Web 角色、辅助角色或虚拟机）和云服务（例如 Windows Azure 存储、SQL 数据库等）指定目标数据中心。当这些资源需要一起使用时，它们应该位于同一数据中心内。
关联组
Windows Azure 对某些资源更进一步，支持关联组。关联组是将资源逻辑分组，并与数据中心关联起来。您可以为关联组提供自定义名称，使用对您的业务有意义的名称，而不是简单的通用数据中心名称。这是一个云平台功能的示例，可帮助避免托管错误。
以 PoP 为例，如果我们部署到单个北美数据中心，我们可以创建一个名为 PoP-North America-Production 的关联组，用于我们的生产数据中心。创建时，系统会自动决定选择哪个北美数据中心，这样，对于任何使用 PoP-North America-Production 关联组的下游部署，就无需再为此做决定。
截至撰写本文时，并非所有 Windows Azure 资源都支持关联组；目前仅支持 Windows Azure 计算和 Windows Azure 存储。最值得注意的是，SQL 数据库目前不支持，尽管它仍然可以与其他资源放置在同一个数据中心。
虽然关联组与特定数据中心绑定，但它们也为 Windows Azure 提供线索，以便针对受支持的资源类型进行进一步的本地优化。不仅如此，您的 Windows Azure 存储、从 Web 访问存储的代码以及工作角色之间的距离也更近，减少了路由器跳转次数，缩短了数据传输距离。这进一步降低了网络延迟。
在存储帐户和云服务中使用相同的关联组，可确保它们全部位于同一数据中心。
运行日志和指标
您可能还会使用 Windows Azure 诊断 (WAD) 和 Windows Azure 存储分析来收集运行日志文件，这些功能可通过 Windows Azure 存储帐户获得。请将与计算实例相同的关联组应用于存储。
最佳实践是将 WAD 持久化到专用的运行存储帐户（与生产系统中的其他存储帐户不同），这样既可以最大限度地减少潜在的争用，又可以更轻松地管理对日志和指标的访问。根据数据项的具体类型，各个诊断值将存储在 Windows Azure Blob 存储或 Windows Azure 表存储中。请为 WAD 存储使用相同的关联组，以确保它与应用程序的其余部分存储在同一数据中心。
Windows Azure 存储分析数据与常规数据一起存储，不会存储在单独的存储帐户中，因此会自动进行位置共享。
当由于技术或业务原因无法进行服务器托管时，Windows Azure 提供了一些可以提供帮助的服务。这些服务在多站点部署模式（第 15 章）的示例部分中有所提及。
总结
在云端入门最简单的方法是将节点托管在同一个数据中心内。这适用于许多应用程序，也应该是标准配置。除非有充分的理由，否则不要偏离此配置，并避免意外地将服务部署到多个数据中心，包括用于存储运营数据。