介绍
一旦您的应用程序在云服务器环境中启动并运行，您可能想知道如何改进您的服务器环境以实现从“可以工作”到成熟的生产环境的飞跃。 本文将帮助您开始规划和实施生产环境，方法是在云服务器环境中的 Web 应用程序上下文中创建“生产”的松散定义，并向您展示一些可以添加到现有的组件架构进行过渡。
出于本演示的目的，假设我们从类似于 5 通用服务器设置 中描述的设置开始，例如这个仅服务于 Web 应用程序的两服务器环境：
您的实际设置可能更简单或更复杂，但此处讨论的一般思想和组件应在某种程度上适用于任何服务器环境。
让我们开始定义我们所说的“生产环境”的含义。
什么是生产环境？
一般而言，Web 应用程序的服务器环境由保持应用程序正常运行所必需的硬件、软件、数据、操作计划和人员组成。 生产环境通常是指在设计和实施时充分考虑了以下因素的可接受水平的服务器环境：
- 可用性：应用程序在广告时间可供其预期用户使用的能力。 任何严重影响关键组件的故障（例如 错误导致应用程序崩溃、数据库存储设备故障或系统管理员意外关闭应用程序服务器电源）。
提高可用性的一种方法是减少环境中 单点故障 的数量。 例如，使用静态 IP 和监控故障转移服务可确保用户仅访问健康负载 平衡器。要 了解更多信息，请阅读 如何使用浮动 IP 的此部分和此 [X206X ]关于负载平衡的文章。
- Recoverability：在系统故障或数据丢失的情况下恢复应用程序环境的能力。 如果关键组件发生故障并且无法恢复，则可用性将变得不存在。 提高 可维护性 是一个相关概念，减少了在发生故障时执行给定恢复过程所需的时间，因此可以提高发生故障时的可用性
- Performance：应用程序在平均或峰值负载下按预期执行（例如 它是合理的响应）。 虽然对您的用户非常重要，但性能仅在应用程序可用时才重要
在您的应用程序的上下文中，花一些时间为刚刚提到的每个项目定义可接受的级别。 这将根据所讨论应用程序的重要性和性质而有所不同。 例如，个人博客服务的访问者很少，偶尔会出现宕机或性能不佳的情况，只要博客可以恢复，这可能是可以接受的，但公司的在线商店应该争取非常高的分数。 当然，为每个应用程序在每个类别中实现 100% in 会很好，但由于时间和金钱的限制，这通常是不可行的。
请注意，我们没有提到 (a) 硬件可靠性，给定硬件组件在故障前指定时间内正常运行的概率，或 (b) 安全性作为因素。 这是因为我们假设 (a) 您使用的云服务器通常是可靠的，但有可能出现故障（因为它们在物理服务器上运行），并且 (b) 您正在尽最大努力遵循安全最佳实践——简而言之，它们超出了本文的范围。 但是，您应该知道，可靠性和安全性是可以直接影响可用性的因素，并且两者都可以促成对可恢复性的需求。
我们不会向您展示创建生产环境的分步过程（由于每个应用程序的需求和性质不同，这是不可能的），我们将展示一些可用于将现有设置转换为生产环境的有形组件。
让我们来看看组件！
1. 备份系统
备份系统将使您能够创建数据的定期备份，并从备份中恢复数据。 备份还允许在意外删除或意外修改的情况下将数据回滚到以前的状态，这可能由于各种原因（包括人为错误）而发生。 所有计算机硬件都有可能在某个时间点出现故障，这可能会导致数据丢失。 考虑到这一点，您应该维护所有重要数据的最新备份。
生产需要吗？ 是的。 备份系统可以减轻数据丢失的影响，这是实现可恢复性所必需的，因此在数据丢失的情况下有助于提高可用性，但它必须与可靠的 恢复计划 结合使用，这些计划是下一节讨论。 请注意，DigitalOcean 基于快照的备份可能不足以满足您的所有备份需求，因为它不适合备份活动数据库和其他具有高磁盘写入 I/O 的应用程序——如果您运行这些类型的应用程序，或者想要更多的备份计划灵活性，请务必使用其他备份系统，例如 Bacula。
上图是基本备份系统的示例。 备份服务器与创建初始备份的应用程序服务器位于同一数据中心。 随后，将备份的异地副本制作到不同数据中心的服务器上，以确保在发生自然灾害时保留数据。
注意事项
- 备份选择：您要备份的数据。 最少备份任何无法从替代来源可靠复制的数据
- 备份计划： 执行完整备份或增量备份的时间和频率。 某些类型的数据（例如活动数据库）的备份必须特别注意，这可能会影响您的备份计划
- 数据保留期限：在删除备份之前您将保留多长时间
- 用于备份的磁盘空间： 前面三个项目的组合会影响备份系统所需的磁盘空间量。 利用压缩和增量备份来减少备份所需的磁盘空间
- 异地备份： 为保护您的备份免受本地灾难的影响，在特定数据中心内，建议在地理上独立的位置维护备份副本。 在上图中，为此目的，将 NYC3 的备份复制到 SFO1
- 备份恢复测试：定期测试您的备份恢复过程，以确保您的备份正常工作
相关教程
- 如何为您的 VPS 选择有效的备份策略
- 如何在 Ubuntu 14.04 上安装 Bacula 服务器
- 如何使用 Rsync 在 VPS 上同步本地和远程目录
- 了解 DigitalOcean Droplet 备份
2. 恢复计划
恢复计划是一组记录在案的程序，用于从生产环境中的潜在故障或管理错误中恢复。 至少，您需要为每个您认为不可避免会发生的严重情况制定恢复计划，例如服务器硬件故障或意外数据删除。 例如，一个非常基本的服务器故障恢复计划可能包含执行初始服务器部署所采取的步骤列表，以及从备份中恢复应用程序数据的额外过程。 除了良好的文档之外，更好的恢复计划还可以利用部署脚本和配置管理工具（例如 Ansible、Chef 或 Puppet）来帮助自动化和加快恢复过程。
生产需要吗？ 是的。 尽管恢复计划在您的服务器环境中不作为软件存在，但它们是生产设置的必要组件。 它们使您能够有效地利用备份，并为重建环境或在需要时回滚到所需状态提供蓝图。
上图概述了故障数据库服务器的恢复计划。 在这种情况下，数据库服务器将被替换为安装了相同软件的新服务器，并且将使用上次良好的备份来恢复服务器配置和数据。 最后，应用服务器将被配置为使用新的数据库服务器。
注意事项
- Procedure Documentation： 在失败事件中应遵循的文档集。 一个好的起点是构建一个循序渐进的文档，您可以按照该文档重建故障服务器，然后添加从备份中恢复各种应用程序数据和配置的步骤
- 自动化工具：脚本和配置管理软件提供自动化，可以改进部署和恢复过程。 虽然分步指南通常足以简单地从故障中恢复，但它们必须由人执行，因此不如自动化过程快速或一致
- 关键组件： 应用程序正常运行所必需的组件。 在上面的示例中，应用程序和数据库服务器都是关键组件，因为如果其中任何一个发生故障，应用程序将变得不可用
- 单点故障： 没有自动故障转移机制的关键组件被认为是单点故障。 您应该尽最大努力消除单点故障，以提高可用性
- 修订： 随着部署和恢复过程的改进，更新您的文档
3. 负载均衡
可以将负载平衡添加到服务器环境中，通过将工作负载分布在多个服务器上来提高性能和可用性。 如果负载平衡的服务器之一发生故障，其他服务器将处理传入流量，直到故障服务器再次恢复健康。 在云服务器环境中，负载平衡通常可以通过在运行应用程序特定组件的多个服务器前面添加运行负载平衡器（反向代理）软件的负载平衡器服务器来实现。
生产需要？ 不一定。 生产环境并不总是需要负载平衡，但如果实施得当，它可以成为减少系统中单点故障数量的有效方法。 它还可以通过水平扩展增加更多容量来提高性能。
上图添加了一个额外的应用服务器来分担负载，以及一个负载均衡器来将用户请求分散到两个应用服务器上。 如果单个应用程序服务器难以跟上流量，此设置可以帮助提高性能，并且如果其中一个应用程序服务器出现故障，它还可以帮助保持应用程序可用。 但是，它仍然在数据库服务器和负载平衡器服务器本身中存在两个单点故障。
笔记： DigitalOcean 负载均衡器 are a fully-managed, highly available load balancing service. If you are running your application on DigitalOcean, the Load Balancer service may a good fit for your environment.
注意事项
- 负载平衡组件： 并非环境中的所有组件都可以轻松进行负载平衡。 必须特别考虑某些类型的软件，例如数据库或有状态的应用程序
- 应用程序数据复制： 如果负载均衡的应用程序服务器在本地存储应用程序数据，例如上传的文件，则这些数据必须通过复制或共享文件系统等方法提供给其他应用程序服务器。 这对于确保无论选择哪个应用程序服务器来服务用户请求，应用程序数据都是可用的是必要的
- 性能瓶颈：如果负载均衡器没有足够的资源或配置不正确，它实际上会降低应用程序的性能
- 单点故障：虽然负载均衡可用于消除单点故障，但计划不周的负载均衡实际上会增加更多单点故障。 负载平衡通过在一对前面包含一个具有静态 IP 的第二个负载平衡器来增强，该负载平衡器根据可用性向其中一个或另一个发送流量。
相关教程
- HAProxy 和负载平衡概念简介
- 如何在 Ubuntu 14.04 上使用 HAProxy 实现 SSL 终止
- 如何在 Ubuntu 14.04 上使用 HAProxy 作为 WordPress 和 Nginx 的第 7 层负载均衡器
- 了解 Nginx HTTP 代理、负载平衡、缓冲和缓存
- 如何创建您的第一个 DigitalOcean 负载均衡器
- 如何使用浮动 IP
4. 监控
监控可以通过跟踪服务状态和服务器资源利用率的趋势来支持服务器环境，从而为您的环境提供很好的可见性。 监控系统的最大好处之一是它们可以配置为触发操作，例如运行脚本或发送通知，当服务或服务器出现故障时，或者如果某个资源（如 CPU、内存或存储，变得过度使用。 这些通知使您能够在任何问题发生时立即做出反应，这有助于最大限度地减少或防止应用程序的停机时间。
生产需要？ 不一定，但是随着生产环境的规模和复杂性的增加，监控的需求也会增加。 它提供了一种简单的方法来跟踪您的关键服务和服务器资源。 反过来，监控可以提高可恢复性，并为您的设置的规划和维护提供信息。
上图是一个监控系统的例子。 通常，监控服务器会向运行在应用程序和数据库服务器上的代理软件请求状态数据，每个代理都会以软件和硬件状态信息进行响应。 然后，系统管理员可以使用监控控制台查看应用程序的整体状态，并根据需要深入了解更详细的信息。
注意事项
- 要监控的服务： 您将监控的服务和软件。 最低限度，您应该监控所有服务的状态，这些服务需要处于健康运行状态才能使您的应用程序正常运行
- 要监控的资源： 您将监控的资源。 资源示例包括 CPU、内存、存储和网络利用率，以及整个服务器的状态
- 数据保留： 丢弃监控数据之前保留的时间段。 这与您选择要监控的项目一起，将影响您的监控系统所需的磁盘空间量
- 问题检测规则： 确定服务或资源是否处于正常状态的阈值和规则。 例如，如果服务或服务器正在运行并为请求提供服务，则它可能被认为是健康的，而诸如存储之类的资源可能会在其利用率在一定时间内达到某个阈值时触发警告
- 通知规则： 确定是否应发送通知的阈值和规则。 虽然通知很重要，但调整通知规则也同样重要，以免收到太多通知； 一个装满警告和警报的收件箱通常会被忽略，使它们几乎像没有通知一样无用
相关教程
- 如何在 Ubuntu 14.04 上安装 Nagios 4 并监控您的服务器
- 如何使用 Icinga 监控 Ubuntu 14.04 上的服务器和服务
- 如何在 Ubuntu 上安装 Zabbix 并将其配置为监控多个 VPS 服务器
- 使用 SNMP 监控和管理您的网络
- 如何在 Ubuntu 14.04 上配置 Sensu 监控、RabbitMQ 和 Redis
5. 集中记录
集中式日志记录可以通过提供一种简单的方式来查看和搜索您的日志来支持服务器环境，这些日志通常存储在整个环境中的各个服务器上，在一个地方。 除了不必登录到单个服务器来阅读日志的便利之外，集中式日志记录还允许您通过在特定时间范围内关联它们的日志和指标来轻松识别跨多个服务器的问题。 它还在日志保留方面提供了更大的灵活性，因为本地日志可以从应用程序服务器卸载到具有自己独立存储的集中式日志服务器。
生产需要吗？ 不，但是像监控一样，随着服务器环境的规模和复杂性的增长，集中式日志记录可以提供对您的服务器环境的宝贵洞察力。 除了比传统日志记录更方便之外，它还使您能够以更高的可见性快速审核您的服务器日志。
上图是集中式日志记录系统的简化示例。 每个服务器上都安装了一个日志传送代理，并配置为将重要的应用程序和数据库日志发送到集中式日志服务器。 然后，系统管理员可以从单个控制台查看、过滤和搜索所有重要日志。
注意事项
- 要收集的日志： 您将从服务器传送到集中式日志记录服务器的特定日志。 您应该从所有服务器收集重要日志
- 数据保留： 在丢弃日志之前保留日志的时间段。 这与您选择收集的日志一起，将影响您的集中式日志记录系统所需的磁盘空间量
- 日志过滤器：将普通日志解析为结构化日志数据的过滤器。 过滤日志将提高您以有意义的方式查询、分析和绘制数据的能力
- 服务器时钟：确保您的服务器时钟同步并使用设置为相同的时区，这样您的日志时间线在整个环境中都是准确的
相关教程
- 如何在 Ubuntu 14.04 上安装 Elasticsearch、Logstash 和 Kibana 4
- 如何使用 DigitalOcean ELK Stack 一键式应用程序
- 服务器跟踪统计简介
- 如何在 Ubuntu 14.04 上安装 Graylog2 并集中日志
结论
当您将所有组件放在一起时，您的生产环境可能如下所示：
现在您已经熟悉了可用于支持和改进生产服务器设置的组件，您应该考虑如何将它们集成到您自己的服务器环境中。 当然，我们并没有涵盖所有可能性，但这应该让您知道从哪里开始。 请记住根据可用资源和您自己的生产目标的平衡来设计和实施您的服务器环境。
如果您对设置上述环境感兴趣，请查看本教程：Building for Production: Web Applications。
