本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 弹性部署 在许多情况下，单服务器部署可能不足以满足您的网站需求。在这些情况下，您需要一个多服务器、可扩展的架构。 **Topics** + [ # 参考架构 ](reference-architecture.md) + [ # 扩展 Web 层 ](scaling-the-web-tier.md) + [ # 无状态数 ](stateless-web-tier.md) # 参考架构 [ WordPress 上的 Hosting on AWS 参考架构](https://github.com/awslabs/aws-refarch-wordpress) GitHub概述了部署 WordPress 的最佳实践，AWS并包括一组可以让你快速启动和运行的 AWS CloudFormation 模板。以下架构基于该参考架构。本节的其余部分将回顾架构选择背后的原因。 2021 GitHub 年 7 AMI 月，其基础从亚马逊 Linux1 更改为亚马逊 Linux2。但是，S3 的部署模板尚未更改。 GitHub 如果在 S3 上使用模板部署参考架构时遇到问题，建议使用中的模板。 ![\[用于托管 WordPress 的参考架构 AWS\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-wordpress/images/image4.png) *用于托管 WordPress 的参考架构 AWS* **架构组件** 参考架构说明了 WordPress 网站上网站的完整最佳实践部署AWS。 + 它从 **Amazon CloudFront** (1) 中的边缘缓存开始，将内容缓存到靠近最终用户的地方，以便更快地****交付。 + CloudFront 从 **S3 存储桶** (2) 中提取静态内容，从 Web 实例前面的 Application Loa **d Balancer** (4) 中提取动态内容。 + 网络实例在由 **Amazon EC2** **实例**组成的 A **uto Scaling 组**中运行 (6)。 + 集** ElastiCache **群 (7) 会缓存经常查询的数据以****加快响应速度。 A **mazon Aurora** 我的SQL实例 (8) 托管 WordPress数据库。 + 这些 WordPress EC2实例通过每个可用区中的**EFS挂载目标** (9) 访问 **Amazon EFS** 文件系统上的共享 WordPress 数据。 + In **ternet Gateway** (3) 可实现您VPC和互联网中的资源之间的通信。 + NAT每个可用区中的@@ **网关** (5) 允许私有子网（应用程序和数据）中的EC2实例访问互联网。 **Amazon** 内VPC存在两种类型的子网：公有子网（**公**有**子**网）和私有子网（**应用程序子网**和**数据子网**）。部署到公有子网中的资源将获得一个公有 IP 地址，并且将在互联网上公开可见。此处部署了 **Application Load Balancer** (4) 和一台用于管理的 Bastion 主机。部署到私有子网中的资源只能获得私有 IP 地址，因此在互联网上不可见，从而提高了这些资源的安全性。**WordPress Web** **服务器实例** (6)、**ElastiCache集群实例** (7)、**Aurora My SQL 数据库实例** (8) 和**EFS挂载目标** (9) 都部署在私有子网中。 本节的其余部分将更详细地介绍其中的每一个注意事项。 # 扩展 Web 层 要将单服务器架构演变为多服务器、可扩展的架构，必须使用五个关键组件： + 亚马逊EC2实例 + Amazon 系统映像 (AMIs) + 负载均衡器 + 自动扩缩 + 运行状况检查 AWS提供多种EC2实例类型，让您能够根据性能和成本选择最佳服务器配置。一般而言，计算优化（例如 C4）实例类型可能是 Web 服务器的不错选择。 WordPress 您可以跨AWS区域内的多个可用区部署实例，以提高整体架构的可靠性。 由于您可以完全控制自己的EC2实例，因此您可以使用 root 权限登录，以安装和配置运行 WordPress 网站所需的所有软件组件。完成后，您可以将该配置另存为AMI，用它来启动具有您所做的所有自定义项的新实例。 要将最终用户请求分发到多个 Web 服务器节点，您需要一个负载平衡解决方案。AWS通过 [Elastic Load Bal](https://aws.amazon.com/elasticloadbalancing/) ancing 提供此功能，这是一项高度可用的服务，可将流量分配到多个EC2实例。由于您的网站通过HTTP或向用户提供内容HTTPS，因此我们建议您使用 Application Load Balancer，这是一种具有内容路由功能的应用程序层负载均衡器，并且能够在需要时在不同的域上运行多个 WordPress 网站。 Elastic Load Balancing 支持在一个AWS区域内的多个可用区之间分配请求。您还可以配置运行状况检查，以便 Application Load Balancer 自动停止向出现故障（例如，由于硬件问题或软件崩溃）的单个实例发送流量。AWS建议使用 WordPress 管理员登录页面 (`/wp-login.php`) 进行运行状况检查，因为该页面既确认 Web 服务器正在运行，也确认 Web 服务器已配置为正确提供PHP文件。 您可以选择构建一个自定义运行状况检查页面，用于检查其他依赖资源，例如数据库和缓存资源。有关更多信息，请参阅《App *lication Load Balancer* [*指南*》中的目标群体的健康检查](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)。 弹性是AWS云的关键特征。您可以在需要时启动更多的计算容量（例如 Web 服务器），而在不需要时可以减少运行的容量。[Amazon A EC2 uto Scaling](https://aws.amazon.com/ec2/autoscaling/) 是一项 AWS 服务，可帮助您自动进行此配置，从而根据您定义的条件向上或向下扩展您的 Amazon EC2 容量，无需手动干预。您可以配置 Amazon A EC2 uto Scaling，使您使用的EC2实例数量在需求高峰期间无缝增加以保持性能，并在流量减少时自动减少，从而最大限度地降低成本。 Elastic Load Balancing 还支持在负载平衡轮EC2换中动态添加和移除亚马逊主机。Elastic Load Balancing 本身还可以动态增加和减少负载平衡容量，以适应流量需求，无需人工干预。 # 无状态数 要在自动扩展配置中利用多个 Web 服务器，您的 Web 层必须处于无状态状态。无状态应用程序是指不需要知道以前的交互并且不存储会话信息的应用程序。如果是 WordPress，这意味着无论哪个 Web 服务器处理了他们的请求，所有最终用户都会收到相同的响应。无状态应用程序可以横向扩展，因为任何请求都可以由任何可用的计算资源（即 Web 服务器实例）提供服务。当不再需要该容量时，可以安全地终止任何单个资源（在耗尽正在运行的任务之后）。这些资源不需要意识到同行的存在——所需要的只是一种将工作量分配给他们的方法。 在用户会话数据存储方面， WordPress 核心是完全无状态的，因为它依赖于存储在客户端 Web 浏览器中的 Cookie。除非您安装了任何依赖本机会话的自定义代码（例如 WordPress 插件），否则不会考虑PHP会话存储。 但是， WordPress 最初是为在单台服务器上运行而设计的。因此，它将一些数据存储在服务器的本地文件系统上。在多服务器配置 WordPress 中运行时，这会产生问题，因为各个 Web 服务器之间存在不一致性。例如，如果用户上传了一张新图像，则该图像仅存储在其中一台服务器上。 这说明了为什么我们需要改进默认的 WordPress运行配置才能将重要数据移动到共享存储。最佳实践架构将数据库作为 Web 服务器之外的独立层，并利用共享存储空间来存储用户上传的内容、主题和插件。 # 共享存储（亚马逊 S3 和亚马逊EFS） 默认情况下，将用户上传的内容 WordPress 存储在本地文件系统上，因此不是无状态的。因此，我们需要将 WordPress 安装和所有用户自定义设置（例如配置、插件、主题和用户生成的上传）转移到共享数据平台中，以帮助减少 Web 服务器的负载并使 Web 层处于无状态状态。 [Amazon Elastic File](https://aws.amazon.com/efs/details/) System（亚马逊EFS）提供可扩展的网络文件系统，用于EC2实例。Amazon EFS 文件系统分布在数量不受限制的存储服务器上，使文件系统能够弹性增长，并允许从实例进行大规模并行访问EC2。Amazon 的分布式设计EFS避免了传统文件服务器固有的瓶颈和限制。 通过将整个 WordPress 安装目录移动到EFS文件系统上，并在每个实例启动时将其安装到每个EC2实例中，您的 WordPress 站点及其所有数据将自动存储在不依赖任何一个EC2实例的分布式文件系统上，从而使您的 Web 层完全处于无状态状态。这种架构的好处是，您无需在每次启动新实例时都安装插件和主题，并且可以显著加快 WordPress 实例的安装和恢复。如本文档的 “部署注意[事项” 部分所述 WordPress，在中部署](appendix-a-cloudfront-configuration.md)对插件和主题的更改也更加容易。 为确保您的网站在EFS文件系统上运行时获得最佳性能，请查看 Amaz OPcache on EFS 和[AWS参考架构的](https://github.com/awslabs/aws-refarch-wordpress#opcache)推荐配置设置 WordPress。 您还可以选择将所有静态资产（例如图像和 JavaScript 文件）卸载到前面有 CloudFront 缓存的 S3 存储桶。CSS如本白皮书的 “[静态内容](accelerating-content-delivery.md)” 部分所述，在多服务器架构中执行此操作的机制与单服务器架构完全相同。其好处与单服务器架构相同，您可以将与提供静态资产相关的工作转移到 Amazon S3，从而使您的 Web 服务器能够仅专注于生成动态内容 CloudFront，并在每台 Web 服务器上处理更多用户请求。 # 数据层（亚马逊 Aurora 和亚马逊 ElastiCache） 通过将 WordPress 安装存储在分布式、可扩展、共享的网络文件系统上，并由 Amazon S3 提供静态资产，您可以将注意力集中在剩下的有状态组件：数据库。与存储层一样，数据库不应依赖于任何一台服务器，因此不能将其托管在其中一个 Web 服务器上。而应将 WordPress 数据库托管在亚马逊 Aurora 上。 [Amazon Aurora](https://aws.amazon.com/rds/aurora) 是一种与 My SQL 和 Postgre SQL 兼容的关系数据库，结合了高端商用数据库的性能和可用性，同时还具有开源数据库的简单性和成本效益。Aurora My 将数据库引擎与由专门构建的分布式存储系统紧密集成，来SQL提高我的SQL性能和可用性。SSD它具有容错能力和自我修复功能，可在三个可用区复制六个数据副本，可用性超过 99.99%，并且可以持续备份您在 Amazon S3 中的数据。Amazon Aurora 旨在自动检测数据库崩溃并重新启动，无需进行崩溃恢复或重新构建数据库缓存。 Amazon Aurora 提供了[多种实例类型](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html)，以适应不同的应用程序配置，包括内存优化型实例和可突发实例。要提高数据库的性能，您可以选择大型实例类型来提供更多CPU和内存资源。 Amazon Aurora 会自动处理主实例和 [Aurora 副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html)之间的故障转移，以便应用程序尽快恢复数据库操作而无需手动管理干预。失效转移到失效转移通常可在不到 30 秒的时间内完成。 创建至少一个 Aurora 副本后，使用集群终端节点连接到您的主实例，以便在主实例出现故障时您的应用程序能够自动进行故障转移。您可以跨三个可用区域创建多达 15 个低延迟只读副本。 随着数据库的扩展，数据库缓存也需要扩展。如前面的 “[数据库缓存](database-caching.md)” 部分所述， ElastiCache 它具有跨 ElastiCache 集群中的多个节点以及跨区域的多个可用区扩展缓存的功能，以提高可用性。在扩展 ElastiCache 集群时，请确保将缓存插件配置为使用配置终端节点进行连接，以便 WordPress 可以在添加新集群节点时使用它们，并在移除旧集群节点后停止使用它们。您还必须将 Web 服务器设置[为使用ElastiCache群集客户端](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html)，PHP并更新您的服务器AMI以存储此更改。