如果应用在没有故障切换可用区的单个可用区中运行,则在发生可用区服务中断时,应用无法处理请求。为防止出现这种情况,您必须在同一区域中的其他(故障切换)可用区维护基础架构堆栈的被动副本。如果主要可用区发生服务中断,您可以将故障切换可用区中的数据库提升为主数据库,并确保传入流量路由到故障切换可用区中的前端。
Google 解决服务中断问题后,您可以选择故障恢复到主要可用区或将其用作新的故障切换可用区。
区域服务中断
如果区域服务中断,您必须等待 Google 解决服务中断故障,然后验证应用是否按预期工作。如果您需要稳健性来应对区域服务中断,请考虑使用多区域部署原型。
[[["易于理解","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 zonal deployment archetype involves running an application within a single Google Cloud zone, suitable for environments like development, testing, or applications that can tolerate downtime.\u003c/p\u003e\n"],["\u003cp\u003eTo recover from zone outages, a dual-zone architecture can be implemented, using a passive replica in a failover zone, that you can promote to primary in case of a primary zone outage.\u003c/p\u003e\n"],["\u003cp\u003eThis architecture is appropriate for applications requiring low-latency networking between components, migrating commodity workloads, or operating license-restricted software.\u003c/p\u003e\n"],["\u003cp\u003eDuring zone outages in a single-zone setup, the application becomes unavailable; therefore, using a failover zone is recommended to ensure continued operation.\u003c/p\u003e\n"],["\u003cp\u003eRegion outages will cause service interruption, so for applications needing protection from this, a multi-regional deployment archetype should be considered instead.\u003c/p\u003e\n"]]],[],null,["# Google Cloud zonal deployment archetype\n\nThis section of the\n[Google Cloud deployment archetypes](/architecture/deployment-archetypes)\nguide describes the zonal deployment archetype.\n\nIn a cloud architecture that uses the basic zonal deployment archetype, the\napplication runs in a single Google Cloud zone, as shown in the following\ndiagram:\n\nTo be able to recover from zone outages, you can use a dual-zone architecture\nwhere a passive replica of the application stack is provisioned in a second\n(failover) zone, as shown in the following diagram:\n\nIf an outage occurs in the primary zone, you can promote the standby database\nto be the primary (write) database and update the load balancer to send traffic\nto the frontend in the failover zone.\n| **Note:** For more information about region-specific considerations, see [Geography and regions](/docs/geography-and-regions#regions_and_zones).\n\nUse cases\n---------\n\nThe following are examples of use cases for which the zonal deployment\narchetype is an appropriate choice:\n\n- **Cloud development and test environments**: You can use the zonal deployment archetype to build a low-cost environment for development and testing.\n- **Applications that don't need high availability**: The zonal deployment archetype might be sufficient for applications that can tolerate downtime.\n- **Low-latency networking between application components**: A single-zone architecture might be well suited for applications such as batch computing that need low-latency and high-bandwidth network connections among the compute nodes.\n- **Migration of commodity workloads**: The zonal deployment archetype provides a cloud migration path for commodity on-premises apps for which you have no control over the code or that can't support architectures beyond a basic active-passive topology.\n- **Running license-restricted software**: The zonal deployment archetype might be well suited for license-restricted systems where running more than one instance at a time is either too expensive or isn't permitted.\n\nDesign considerations\n---------------------\n\nWhen you build an architecture that's based on the zonal deployment archetype,\nconsider the potential downtime during zone and region outages.\n\n### Zone outages\n\nIf the application runs in a single zone with no failover zone, then when a zone\noutage occurs, the application can't serve requests. To prevent this situation,\nyou must maintain a passive replica of the infrastructure stack in another\n(failover) zone in the same region. If an outage occurs in the primary zone, you\ncan promote the database in the failover zone to be the primary database, and\nensure that incoming traffic is routed to the frontend in the failover zone.\nAfter Google resolves the outage, you can choose to either *fail back* to the\nprimary zone or make it the new failover zone.\n| **Note:** For more information about region-specific considerations, see [Geography and regions](/docs/geography-and-regions#regions_and_zones).\n\n### Region outages\n\nIf a region outage occurs, you must wait for Google to resolve the outage and\nthen verify that the application works as expected. If you need robustness\nagainst region outages, consider using the multi-regional deployment archetype.\n\nReference architecture\n----------------------\n\nFor a reference architecture that you can use to design a zonal deployment on\nCompute Engine VMs, see\n[Single-zone deployment on Compute Engine](/architecture/single-zone-deployment-compute-engine)."]]