在使用多区域部署原型的云架构中，应用可在两个或更多 Google Cloud 区域中运行。应用数据会复制到架构的所有区域。为了确保快速、同步地复制数据，区域通常位于一个大洲内。
下图显示了在两个 Google Cloud 区域中运行的应用的云拓扑：
上图显示了在两个 Google Cloud 区域中独立运行的两个独立多层应用堆栈。在每个区域中，该应用都在 3 个可用区运行。系统会复制两个区域中的数据库。如果工作负载具有较低的恢复点目标 (RPO)，或者需要高跨区域数据一致性，则数据库复制需要同步。否则，数据库可以异步复制。用户请求使用 DNS 路由政策路由到区域负载平衡器。
如果两个区域中的任何一个发生中断，则 DNS 会将用户请求路由到另一个区域的负载均衡器。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2024-11-20。"],[[["\u003cp\u003eThe multi-regional deployment archetype involves running an application in two or more Google Cloud regions, with data replicated across all regions, typically within a continent for fast, synchronous replication.\u003c/p\u003e\n"],["\u003cp\u003eThis archetype is recommended for business-critical applications requiring high availability and robustness against region outages, ensuring minimal downtime and near-zero recovery time objective (RTO) when data is replicated synchronously.\u003c/p\u003e\n"],["\u003cp\u003eMulti-regional deployments offer low latency for users within a specific geographical area by allowing a global load balancer to route requests to other regions during an outage, maintaining performance.\u003c/p\u003e\n"],["\u003cp\u003eIt can help meet data residency and operational sovereignty requirements by deploying applications in specific Google Cloud regions and using geofenced DNS routing policies to ensure data stays within a defined geographic area.\u003c/p\u003e\n"],["\u003cp\u003eWhile this approach provides high availability, considerations include the potentially higher cost of cloud resources and network traffic, as well as the increased operational complexity due to managing redundant resources across locations.\u003c/p\u003e\n"]]],[],null,["# Google Cloud multi-regional deployment archetype\n\nThis section of the\n[Google Cloud deployment archetypes](/architecture/deployment-archetypes)\nguide describes the multi-regional deployment archetype.\n\nIn a cloud architecture that uses the multi-regional deployment archetype, the\napplication runs in two or more\n[Google Cloud regions](/docs/geography-and-regions#regions_and_zones).\nApplication data is\nreplicated across all the regions in the architecture. To ensure fast and\nsynchronous replication of data, the regions are typically within a continent.\n\nThe following diagram shows the cloud topology for an application that runs in\ntwo Google Cloud regions:\n\nThe preceding diagram shows two isolated multi-tier application stacks that run\nindependently in two Google Cloud regions. In each region, the application\nruns in three zones. The databases in the two regions are replicated. If the\nworkload has a low recovery point objective (RPO) or if it requires strong\ncross-region consistency of data, then the database replication needs to be\nsynchronous. Otherwise, the databases can be replicated asynchronously. User\nrequests are routed to regional load balancers by using a\n[DNS routing policy](/dns/docs/policies-overview#routing_policies).\nIf an outage occurs\nin any one of the two regions, DNS routes user requests to the load balancer in\nthe other region.\n\nUse cases\n---------\n\nThe following sections provide examples of use cases for which the\nmulti-regional deployment archetype is an appropriate choice.\n\n### High availability for geographically dispersed users\n\nWe recommend a multi-regional deployment for applications that are\nbusiness-critical and where high availability and robustness against region\noutages are essential. If a region becomes unavailable for any reason (even a\nlarge-scale disruption caused by a natural disaster), users of the application\ndon't experience any downtime. Traffic is routed to the application in the other\navailable regions. If data is replicated synchronously, the recovery time\nobjective (RTO) is near zero.\n\n### Low latency for application users\n\nIf your users are within a specific geographical area, such as a continent, you\ncan use a multi-regional deployment to achieve an optimal balance between\navailability and performance. When one of the regions has an outage, the global\nload balancer sends requests that originate in that region to another region.\nUsers don't perceive significant performance impact because the regions are\nwithin a geographical area.\n\n### Compliance with data residency and sovereignty requirements\n\nThe multi-regional deployment archetype can help you meet regulatory\nrequirements for\n[data residency and operational sovereignty](https://cloudsovereignty.withgoogle.com/).\nFor example, a country in Europe might require that all user data be stored and\naccessed in data centers that are located physically within the country. You can\ndeploy the application to\n[Google Cloud regions in Europe](/about/locations#europe)\nand use DNS with a\n[geofenced routing policy](/dns/docs/policies-overview#geo-fenced-policy)\nto route traffic to the appropriate region.\n\nDesign considerations\n---------------------\n\nWhen you provision and manage redundant resources across locations, the volume\nof cross-location network traffic can be high. You also store and replicate data\nacross multiple regions. When you build an architecture that uses the\nmulti-regional deployment archetype, consider the potentially higher cost of\ncloud resources and network traffic, and the complexity of operating the\ndeployment. For business-critical applications, the availability advantage of a\nmulti-region architecture might outweigh the increased cost and operational\ncomplexity.\n\nReference architecture\n----------------------\n\nFor a reference architecture that you can use to design a multi-regional\ndeployment on Compute Engine VMs, see\n[Multi-regional deployment on Compute Engine](/architecture/multiregional-vms)."]]
