在基于全球部署原型的架构中，应用在全球多个 Google Cloud 区域运行。您可以将应用部署为分布式位置未知型堆栈或多个区域隔离的堆栈。在任何一种情况下，全球任播负载平衡器都会将流量分配到适当的区域。该应用将数据写入在所有区域都提供的同步复制数据库（如具有多区域配置的 Spanner）中，并从中读取数据。应用堆栈的其他组件也可以是全球组件，例如缓存和对象存储。
下图展示了全球部署原型的分布式位置未知型变体：
上图显示了一个位置未知型应用堆栈，其前端和后端实例（通常是微服务）分布在三个 Google Cloud 区域的多个可用区中。全球任播负载均衡器将传入流量分配到适当的前端实例。这种分布取决于实例的可用性和容量，以及它们与流量来源的地理邻近度。跨区域内部负载均衡器会根据其可用性和容量，将来自前端实例的流量分配到相应的后端实例。该应用使用可以跨区域同步复制和可用的数据库。
下图展示了使用区域隔离应用堆栈的全球部署原型的变体
上图显示了在两个 Google Cloud 区域的多个可用区中运行的区域隔离应用堆栈。此拓扑与多区域部署原型类似，但使用的是全球任播负载平衡器，而不是 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 global deployment archetype involves running an application in multiple Google Cloud regions worldwide, utilizing a global anycast load balancer to direct traffic.\u003c/p\u003e\n"],["\u003cp\u003eApplications in a global deployment can be either location-unaware, with instances distributed across regions, or regionally isolated, with separate stacks in each region.\u003c/p\u003e\n"],["\u003cp\u003eA key component of this architecture is a synchronously replicated database, like Spanner, ensuring data consistency across all regions.\u003c/p\u003e\n"],["\u003cp\u003eThis deployment strategy is ideal for applications needing high availability and robustness for a global audience, offering the potential for reduced costs and simpler operations compared to multi-regional setups.\u003c/p\u003e\n"],["\u003cp\u003eConsiderations for global deployment include potential increases in storage, replication, and networking costs, as well as careful management of global resource changes to avoid single points of failure.\u003c/p\u003e\n"]]],[],null,["# Google Cloud global deployment archetype\n\nThis section of the\n[Google Cloud deployment archetypes](/architecture/deployment-archetypes)\nguide describes the global deployment archetype.\n\nIn an architecture that's based on the global deployment archetype, the\napplication runs in multiple\n[Google Cloud regions](/docs/geography-and-regions#regions_and_zones)\nacross the globe. You can deploy the application either as a distributed\nlocation-unaware stack or as multiple regionally isolated stacks. In either\ncase, a global\n[anycast](https://wikipedia.org/wiki/Anycast)\nload balancer distributes traffic to the appropriate region. The application\nwrites data to, and reads from, a synchronously replicated database that's\navailable in all the regions, like\n[Spanner with multi-region configuration](/spanner/docs/instance-configurations#multi-region-configurations).\nOther components of the application stack can also be global, such as the cache\nand object store.\n\nThe following diagram shows the distributed location-unaware variant of the\nglobal deployment archetype:\n\nThe preceding diagram shows a location-unaware application stack, with frontend\nand backend instances (typically microservices) that are distributed across\nmultiple zones in three Google Cloud regions. A global anycast load\nbalancer distributes incoming traffic to an appropriate frontend instance. This\ndistribution is based on the availability and capacity of the instances and\ntheir geographical proximity to the source of the traffic. Cross-region\ninternal load balancers distribute traffic from the frontend instances to\nappropriate backend instances based on their availability and capacity. The\napplication uses a database that is synchronously replicated and available\nacross regions.\n\nThe following diagram shows a variant of the global deployment archetype with\nregionally isolated application stacks:\n\nThe preceding diagram shows regionally isolated application stacks that run in\nmultiple zones in two Google Cloud regions. This topology is similar to\nthe\n[multi-regional deployment archetype](/architecture/deployment-archetypes/multiregional),\nbut it uses a global anycast load balancer instead of DNS routing. The global\nload balancer distributes incoming traffic to a frontend in the region\nthat's nearest to the user. Both the application stacks write data to, and read\nfrom, a database that is synchronously replicated and available across both the\nregions. If an outage occurs in any one of the two regions, the global load\nbalancer sends user requests to a frontend in the other region.\n\nUse cases\n---------\n\nThe following sections provide examples of use cases for which the global\ndeployment archetype is an appropriate choice.\n\n### Highly available application for a global audience\n\nWe recommend the global deployment archetype for applications that serve users\nacross the world and, therefore, need high availability and robustness against\noutages in multiple regions.\n\n### Opportunity to optimize cost and simplify operations\n\nWith the global deployment archetype, you can use highly available global\nresources like a global load balancer and a global database. Compared to a\nmulti-regional deployment, a global deployment can help lower costs and simplify\noperations because you provision and manage fewer resources.\n\nDesign considerations\n---------------------\n\nWhen you build an architecture that's based on the global deployment archetype,\nconsider the following design factors.\n\n### Storage, replication, and networking costs\n\nIn a globally distributed architecture, the volume of cross-location network\ntraffic can be high compared to a regional deployment. You might also store and\nreplicate more data. When you build an architecture that's based on the global\ndeployment archetype, consider the potentially higher cost for data storage and\nnetworking. For business-critical applications, the availability advantage of a\nglobally distributed architecture might outweigh the higher networking and\nstorage costs.\n\n### Managing changes to global resources\n\nThe opportunity to use highly available global resources can help you to\noptimize cost and simplify operations. However, to ensure that the global\nresources don't become single points of failure (SPOF), you must carefully\n[manage configuration changes to global resources](/architecture/infra-reliability-guide/building-blocks#careful_management_of_changes_to_global_resources).\n\nReference architecture\n----------------------\n\nFor a reference architecture that you can use to design a global deployment, see\n[Global deployment with Compute Engine and Spanner](/architecture/global-deployment-compute-engine-spanner)."]]
