[[["易于理解","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-14。"],[[["\u003cp\u003eThe regional deployment archetype involves running application instances in multiple zones within a single Google Cloud region, utilizing a shared configuration repository and synchronous data replication.\u003c/p\u003e\n"],["\u003cp\u003eThis architecture provides resilience against zone outages, ensuring continued application operation if at least one functioning component exists in each tier, but it is susceptible to region-wide outages.\u003c/p\u003e\n"],["\u003cp\u003eA passive failover replica in a separate region can be used to minimize downtime during region outages, with DNS routing policies directing traffic to the failover location.\u003c/p\u003e\n"],["\u003cp\u003eThis model is well-suited for applications needing low latency within a specific geographic area or for those requiring compliance with data residency and sovereignty regulations, as data and operations stay within the chosen region.\u003c/p\u003e\n"],["\u003cp\u003eImplementing a regional deployment with multi-zone architecture involves higher costs due to redundant resources, but this cost can be justified by increased availability and zone outage protection.\u003c/p\u003e\n"]]],[],null,["# Google Cloud regional deployment archetype\n\nThis section of the\n[Google Cloud deployment archetypes](/architecture/deployment-archetypes)\nguide describes the regional deployment archetype.\n\nIn a cloud architecture that uses the regional deployment archetype, instances\nof the application run in two or more zones within a single Google Cloud\nregion. All the application instances use a centrally managed, shared repository\nof configuration files. Application data is replicated synchronously across all\nthe zones in the architecture.\n\nThe following diagram shows the cloud topology for a highly available\napplication that runs independently in three zones within a single\nGoogle Cloud region:\n\nThe preceding diagram shows an application with frontend and backend components\nthat run independently in three zones in a Google Cloud region. An\nexternal load balancer forwards user requests to one of the frontends. An\ninternal load balancer forwards traffic from the frontends to the backends. The\napplication uses a database that's replicated across the zones. If a zone outage\noccurs, the database fails over to a replica in another zone.\n\nThe topology in the preceding diagram is robust against zone outages, but not\nagainst region outages. To be able to recover from region outages, you must have\ndeployed a passive replica of the application in a second (failover) region, as\nshown in the following diagram:\n\nWhen an outage occurs in the primary region, you must promote the database in\nthe failover region, and let the\n[DNS routing policies](/dns/docs/policies-overview#routing_policies)\nroute traffic to the load balancer in the failover region.\n\nTo optimize the cost of the failover infrastructure, you can operate the\nfailover region at a lower capacity by deploying fewer resources.\n\nUse cases\n---------\n\nThe following sections provide examples of use cases for which the regional\ndeployment archetype is an appropriate choice.\n\n### Highly available application with users within a geographic area\n\nWe recommend the regional deployment archetype for applications that need\nrobustness against zone outages but can tolerate some downtime caused by region\noutages. If any part of the application stack fails, the application continues\nto run if at least one functioning component with adequate capacity exists in\nevery tier. If a zone outage occurs, the application stack continues to run in\nthe other zones.\n\n### Low latency for application users\n\nIf users of an application are within a geographic area, such as a single\ncountry, the regional deployment archetype can help improve the user-perceived\nperformance of the application. You can optimize network latency for user\nrequests by deploying the application in the Google Cloud region that's\nclosest to your users.\n\n### Low-latency networking between application components\n\nA single-region architecture might be well suited for applications such as batch\ncomputing that need low-latency and high-bandwidth network connections among the\ncompute nodes. All resources are in a single Google Cloud region, so\ninter-resource network traffic remains within the region. The inter-resource\nnetwork latency is low, and you don't incur cross-region data transfer costs.\nIntra-region network costs still apply.\n\n### Compliance with data residency and sovereignty requirements\n\nThe regional deployment archetype can help you meet regulatory requirements 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. To help\nmeet this requirement, you can deploy the application to a\n[Google Cloud region in Europe](/about/locations#europe).\n\nDesign considerations\n---------------------\n\nWhen you build an architecture that's based on the regional deployment\narchetype, consider the following design factors.\n\n### Downtime during region outages\n\nWhen a region outage occurs, the application is down. You can reduce the\ndowntime caused by region outages by maintaining a passive (failover) replica of\nthe infrastructure stack in another Google Cloud region. If an outage\noccurs in the primary region, you can activate the stack in the failover region\nand use\n[DNS routing policies](/dns/docs/policies-overview#routing_policies)\nto route traffic to the load balancer in the failover region.\n\n### Cost of redundant resources\n\nA multi-zone architecture typically has more cloud resources than a single-zone\ndeployment. Consider the cost of these cloud resources when you build your\narchitecture. For applications that need robustness against zone outages, the\navailability advantage of a multi-zone architecture might justify the higher\ncost.\n| **Note:** For more information about region-specific considerations, see [Geography and regions](/docs/geography-and-regions#regions_and_zones).\n\nReference architecture\n----------------------\n\nFor a reference architecture that you can use to design a regional deployment on\nCompute Engine VMs, see\n[Regional deployment on Compute Engine](/architecture/regional-deployment-compute-engine)."]]
