对于在本地运行的关键任务应用，您可以将数据备份到 Google Cloud 并在云端维护副本，如下图所示。备份频率以及副本是否需要主动或被动取决于您的恢复时间目标 (RTO) 和恢复点目标 (RPO)。当本地应用因计划内或计划外事件而停机时，您可以在 Google Cloud 中激活副本，以将应用恢复到生产环境。
针对云应用的本地开发
对于在 Google Cloud中运行的应用，您可以将开发环境保留在本地，并使用 CI/CD 流水线将更新推送到云端，如下图所示。此架构让您可保持对开发活动的控制，同时获享Google Cloud 提供的可伸缩性、费用优化和可靠性的优势。
使用云功能增强本地应用
Google Cloud 在许多方面都提供高级功能，包括存储、人工智能 (AI) 和机器学习 (ML)、大数据和分析。混合部署原型可让您使用这些高级Google Cloud 功能，即使是对于您在本地运行的应用也是如此。以下是这些功能的示例：
[[["易于理解","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 hybrid deployment archetype involves deploying parts of an application in Google Cloud while other parts remain on-premises.\u003c/p\u003e\n"],["\u003cp\u003eCommon use cases include using Google Cloud as a disaster recovery site for on-premises applications, maintaining on-premises development environments for cloud applications, and enhancing on-premises applications with Google Cloud capabilities like AI, ML, or data analytics.\u003c/p\u003e\n"],["\u003cp\u003eA tiered hybrid topology can be used where the application's frontend is in Google Cloud and the backend is on-premises, or vice versa, which is useful for global applications needing a single controlled backend.\u003c/p\u003e\n"],["\u003cp\u003eDesigning a hybrid architecture requires careful consideration of network connectivity, setup and operational complexity, and the potential cost of redundant resources.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing GKE enterprise is useful when managing containerized hybrid applications, which provides a unified management platform.\u003c/p\u003e\n"]]],[],null,["# Google Cloud hybrid deployment archetype\n\nThis section of the\n[Google Cloud deployment archetypes](/architecture/deployment-archetypes)\nguide describes the hybrid deployment archetype, provides examples of use cases,\nand discusses design considerations.\n\nIn an architecture that's based on the hybrid deployment archetype, some parts\nof the application are deployed in Google Cloud, and other parts run\non-premises.\n\nUse cases\n---------\n\nThe following sections provide examples of use cases for which the hybrid\ndeployment archetype is an appropriate choice.\n| **Note:** For each of these use cases, the Google Cloud part of the architecture can use the zonal, regional, multi-regional, or global deployment archetype.\n\n### Disaster recovery (DR) site for an on-premises application\n\nFor mission-critical applications that you run on-premises, you can back up the\ndata to Google Cloud and maintain a replica in the cloud, as shown in the\nfollowing diagram. The backup frequency and whether the replica needs to be\nactive or passive depends on your recovery time objective (RTO) and recovery\npoint objective (RPO). When the on-premises application is down due to planned\nor unplanned events, you can activate the replica in Google Cloud to\nrestore the application to production.\n\n### On-premises development for cloud applications\n\nFor an application that runs in Google Cloud, you can keep the development\nenvironments on-premises, and use a CI/CD pipeline to push updates to the cloud,\nas shown in the following diagram. This architecture lets you retain control\nover your development activities while enjoying the benefits that\nGoogle Cloud offers for scalability, cost optimization, and reliability.\n\n### Enhancing on-premises applications with cloud capabilities\n\nGoogle Cloud offers advanced capabilities in many areas, including\nstorage, artificial intelligence (AI) and machine learning (ML), big data, and\nanalytics. The hybrid deployment archetype lets you use these advanced\nGoogle Cloud capabilities even for applications that you run on-premises.\nThe following are examples of these capabilities:\n\n- Low-cost, unlimited [archive storage](/storage) in the cloud for an on-premises application.\n- [AI and ML](/products/ai) applications in the cloud for data generated by an on-premises application.\n- Cloud-based data warehouse and analytics processes using [BigQuery](/bigquery/docs/introduction) for data ingested from on-premises data sources.\n- [Cloud bursting](/architecture/hybrid-multicloud-patterns-and-practices/cloud-bursting-pattern), to handle overflow traffic when the load on the on-premises application reaches peak capacity.\n\nThe following diagram shows a hybrid topology where data from an on-premises\napplication is uploaded to Google Cloud. Data analysts analyze the\nuploaded data by using advanced AI, ML, big data, and analytics capabilities in\nGoogle Cloud.\n\n### Tiered hybrid topology\n\nIn this topology, which is sometimes called a split-stack deployment, the\napplication's frontend is in Google Cloud, and the backend is on-premises.\nThe frontend might include capabilities like load balancing, CDN, DDoS\nprotection, and access policies. The frontend sends traffic to the on-premises\nbackend for processing, as shown in the following diagram:\n\nThis architecture might be suitable when an application is used globally but the\nbackend needs to be within a single, controlled environment. A variation of this\nuse case is to run the frontend on-premises and deploy the backend in\nGoogle Cloud.\n\n### More information\n\nFor more information about the rationale and use cases for the hybrid deployment\narchetype, see\n[Build hybrid and multicloud architectures using Google Cloud](/architecture/hybrid-multicloud-patterns).\n\nDesign considerations\n---------------------\n\nWhen you build an architecture that's based on the hybrid deployment archetype,\nconsider the following design factors.\n\n### On-premises to cloud network connection\n\nFor efficient network communication between your on-premises environment and the\nresources in Google Cloud, you need a network connection that's reliable\nand secure. For more information about hybrid\nconnectivity options offered by Google Cloud, see\n[Choosing a Network Connectivity product](/network-connectivity/docs/how-to/choose-product).\n\n### Setup effort and operational complexity\n\nSetting up and operating a hybrid topology requires more effort than an\narchitecture that uses only Google Cloud. To operate this topology, you\nneed to manage resources consistently across the on-premises and\nGoogle Cloud environments. To manage containerized hybrid applications,\nyou can use\n[GKE Enterprise](/anthos),\nwhich is a unified orchestration platform to manage Kubernetes clusters in\nmultiple locations.\n\n### Cost of redundant resources\n\nA hybrid deployment is potentially more expensive than a cloud-only deployment,\nbecause data might need to be stored redundantly on-premises and in the cloud.\nAlso, some of the redundant resources might be underutilized. When you build an\narchitecture that's based on the hybrid deployment archetype, consider the\npotentially higher overall cost of resources.\n\nExample architectures\n---------------------\n\nFor examples of architectures that use the hybrid deployment archetype, see\n[Build hybrid and multicloud architectures using Google Cloud](/architecture/hybrid-multicloud-patterns)."]]
