5种改进生产 Web 应用服务器设置的方法

简介

一旦你的应用程序在云服务器环境中运行起来，你可能会想知道如何改进你的服务器环境，使其从“能用”跃升到一个完整的生产环境。本文将帮助你开始规划和实施生产环境，通过在云服务器环境中创建一个“生产环境”的宽泛定义，并向你展示一些可以添加到现有架构中的组件，以实现这一转变。

为了演示的目的，让我们假设我们从类似于《5种常见服务器设置》中描述的设置开始，就像这样一个简单提供 Web 应用程序的双服务器环境：

!应用程序设置

你的实际设置可能更简单或更复杂，但本文讨论的一般思想和组件应该在某种程度上适用于任何服务器环境。

让我们开始定义我们所说的“生产环境”是什么意思。

什么是生产环境？

从一般意义上讲，Web 应用程序的服务器环境包括硬件、软件、数据、运营计划和必要的人员，以保持应用程序的正常运行。生产环境通常指的是一个经过最大程度考虑这些因素的服务器环境：

• 可用性：应用程序在广告时间内能够被其预期用户使用的能力。可用性可能会受到任何严重影响关键组件的故障的影响（例如，应用程序由于错误而崩溃，数据库存储设备故障，或系统管理员意外关闭应用服务器）。

提高可用性的一种方法是减少环境中的单点故障的数量。例如，使用静态 IP 和监控故障转移服务可以确保用户只访问健康的负载均衡器。要了解更多信息，请阅读《如何使用保留 IP》中的这一部分以及这篇关于负载均衡的文章。

• 可恢复性：在系统故障或数据丢失的情况下，恢复应用程序环境的能力。如果关键组件发生故障，并且无法恢复，可用性将变得不存在。改善可维护性，一个相关的概念，可以减少在故障事件中执行给定恢复过程所需的时间，因此可以在故障事件中提高可用性。

• 性能：应用程序在平均或高峰负载下表现如预期（例如，它具有合理的响应性）。虽然对于用户来说非常重要，但性能只有在应用程序可用时才重要。

花些时间来定义每个上述项目的可接受水平，这取决于所讨论应用程序的重要性和性质。例如，对于为少数访问者提供服务的个人博客，偶尔出现停机或性能不佳可能是可以接受的，只要博客可以恢复，但公司的在线商店应该在各方面力争取得非常高的分数。当然，对于每个应用程序在每个类别中都达到 100% 是很好的，但由于时间和资金的限制，这通常是不可行的。

请注意，我们没有提到（a）硬件可靠性，即给定硬件组件在故障之前能够正常运行的概率，或者（b）安全性作为因素。这是因为我们假设（a）你正在使用的云服务器通常是可靠的，但有故障的潜力（因为它们运行在物理服务器上），（b）你正在尽力遵循安全最佳实践——简而言之，它们超出了本文的范围。然而，你应该意识到，可靠性和安全性是可以直接影响可用性的因素，两者都可能导致可恢复性的需求。

与其向你展示创建生产环境的逐步过程（由于每个应用程序的需求和性质不同，这是不可能的），我们将介绍一些可以利用的具体组件，将你现有的设置转变为生产环境。

让我们来看看这些组件！

1. 备份系统

备份系统将使你能够定期备份数据，并从备份中恢复数据。备份还允许你将数据回滚到先前的状态，以应对意外删除或不希望的修改，这可能是由于各种原因，包括人为错误。所有计算机硬件在某个时间点都有可能发生故障，这可能导致数据丢失。考虑到这一点，你应该保持所有重要数据的最新备份。

生产环境所需？ 是的。备份系统可以减轻数据丢失的影响，这对于实现可恢复性是必要的，因此有助于在数据丢失的情况下提高可用性——但它必须与可靠的恢复计划一起使用，这将在下一节中讨论。请注意，DigitalOcean 基于快照的备份可能不足以满足你所有的备份需求，因为它不适合对活动数据库和其他具有高磁盘写入 I/O 的应用程序进行备份——如果你运行这些类型的应用程序，或者想要更灵活的备份调度，一定要使用另一个备份系统，比如 Bacula。

!备份系统示例

上图是一个基本备份系统的示例。备份服务器位于与应用服务器相同的数据中心，初始备份是在那里创建的。稍后，备份的离线副本将制作到不同数据中心的服务器上，以确保数据在发生自然灾害等情况下得到保护。

考虑因素

• 备份选择： 需要备份的数据。至少要备份任何无法从其他来源可靠地再现的数据
• 备份计划： 何时以及多频繁地执行完整或增量备份。必须特别考虑对某些类型数据的备份，比如活动数据库，这可能会影响备份计划
• 数据保留期： 在删除备份之前要保留备份的时间长度
• 备份所需磁盘空间： 三个前述项目的组合影响备份系统所需的磁盘空间。利用压缩和增量备份来减少备份所需的磁盘空间
• 离站备份： 为了防止本地灾难对备份的影响，在特定数据中心内，建议在地理位置上分离的位置保留备份的副本。在上面的图表中，NYC3 的备份被复制到 SFO1 以实现这一目的
• 备份恢复测试： 定期测试备份恢复流程，确保备份正常工作

相关教程

• 如何为你的 VPS 选择有效的备份策略
• 如何在 Ubuntu 14.04 上安装 Bacula 服务器
• 如何使用 Rsync 同步 VPS 上的本地和远程目录
• 理解 DigitalOcean Droplet 备份

2. 恢复计划

恢复计划是一组记录的程序，用于从潜在故障或管理错误中恢复你的生产环境。至少，你会希望为你认为不可避免会发生的每种严重情况制定一个恢复计划，比如服务器硬件故障或意外数据删除。例如，针对服务器故障的一个非常基本的恢复计划可能包括你执行初始服务器部署的步骤列表，并额外添加从备份中恢复应用数据的程序。一个更好的恢复计划可能会利用部署脚本和配置管理工具（如 Ansible、Chef 或 Puppet）来自动化和加快恢复过程，除了良好的文档。

生产环境所需？ 是的。尽管恢复计划在你的服务器环境中并不存在作为软件，但它们是生产设置的必要组成部分。它们使你能够有效地利用你的备份，并为在需要时重建你的环境或回滚到期望的状态提供了蓝图。

!恢复计划示例

上图是一个针对失败的数据库服务器的恢复计划概述。在这种情况下，数据库服务器将被一个安装了相同软件的新服务器替换，并且将使用最近的良好备份来恢复服务器配置和数据。最后，应用服务器将被配置为使用新的数据库服务器。

考虑因素

• 程序文档： 在故障事件中应该遵循的一系列文件。一个很好的起点是建立一个逐步文档，你可以按照其中的步骤重建失败的服务器，然后添加从备份中恢复各种应用数据和配置的步骤
• 自动化工具： 脚本和配置管理软件提供自动化，可以改进部署和恢复过程。虽然逐步指南通常足以简单地从故障中恢复，但它们必须由人执行，因此不如自动化过程快速和一致
• 关键组件： 你的应用程序正常运行所必需的组件。在上面的示例中，应用服务器和数据库服务器都是关键组件，因为如果其中一个失败，应用程序将变得不可用
• 单点故障： 没有自动故障转移机制的关键组件被视为单点故障。你应该尽力消除单点故障，以提高可用性
• 修订： 随着你的部署和恢复过程的改进，更新你的文档

3. 负载均衡

负载均衡可以添加到服务器环境中，通过在多个服务器之间分配工作负载来提高性能和可用性。如果其中一个被负载均衡的服务器失败，其他服务器将处理传入的流量，直到失败的服务器再次变得健康。在云服务器环境中，负载均衡通常可以通过在运行特定应用程序组件的多个服务器前面添加运行负载均衡器（反向代理）软件的负载均衡器服务器来实现。

生产环境所需？ 不一定。负载均衡并不总是生产环境所必需的，但如果正确实施，它可以是减少系统中单点故障数量的有效方式。它还可以通过水平扩展来提高性能。

!负载均衡

上图添加了一个额外的应用服务器来共享负载，并添加了一个负载均衡器来跨两个应用服务器分发用户请求。如果单个应用服务器难以跟上流量，这种设置可以帮助提高性能，并且如果一个应用服务器失败，它还可以帮助保持应用程序可用。但是，它仍然存在两个单点故障，即数据库服务器和负载均衡器服务器本身。

考虑因素

• 可负载均衡组件： 环境中并非所有组件都能轻松地进行负载均衡。对于某些类型的软件，如数据库或有状态的应用程序，必须特别考虑
• 应用数据复制： 如果负载均衡的应用服务器将应用数据（如上传的文件）存储在本地，这些数据必须通过复制或共享文件系统的方式提供给其他应用服务器。这是为了确保无论选择哪个应用服务器来提供用户请求，应用数据都将可用
• 性能瓶颈： 如果负载均衡器资源不足或配置不当，实际上会降低应用程序的性能
• 单点故障： 虽然负载均衡可用于消除单点故障，但规划不良的负载均衡实际上可能会增加更多的单点故障。通过在一对负载均衡器前面加入具有静态 IP 的第二个负载均衡器，根据可用性将流量发送到其中一个，可以增强负载均衡。

相关教程

• HAProxy 和负载均衡概念简介
• 如何在 Ubuntu 14.04 上使用 HAProxy 实现 SSL 终止
• 如何在 Ubuntu 14.04 上将 HAProxy 用作 WordPress 和 Nginx 的第 7 层负载均衡器
• 理解 Nginx HTTP 代理、负载均衡、缓冲和缓存
• 如何创建您的第一个 DigitalOcean 负载均衡器
• 如何使用保留 IP

4. 监控

监控可以通过跟踪服务状态和服务器资源利用率趋势来支持服务器环境，从而为您的环境提供很好的可见性。监控系统最大的好处之一是可以配置触发操作，例如运行脚本或发送通知，当服务或服务器宕机，或者某些资源（如 CPU、内存或存储）过度利用时。这些通知使您能够在问题发生时立即做出反应，有助于最小化或预防应用程序的停机时间。

生产环境需要吗？ 不一定，但随着生产环境规模和复杂性的增长，对监控的需求也会增加。它提供了一种轻松跟踪关键服务和服务器资源的方式。反过来，监控可以提高可恢复性，并且可以通知您的设置的规划和维护。

!监控示例

上图是一个监控系统的示例。通常，监控服务器将从运行在应用程序和数据库服务器上的代理软件请求状态数据，每个代理都会以软件和硬件状态信息作出响应。系统的管理员可以使用监控控制台查看应用程序的整体状态，并根据需要深入了解更详细的信息。

考虑因素

• 要监控的服务： 您将要监控的服务和软件。最低限度，您应该监控所有需要处于健康运行状态才能使应用程序正常运行的服务状态
• 要监控的资源： 您将要监控的资源。资源的示例包括 CPU、内存、存储和网络利用率，以及服务器作为整体的状态
• 数据保留： 在丢弃监控数据之前保留监控数据的时间段。这个时间段，以及您选择要监控的项目，将影响监控系统所需的磁盘空间
• 问题检测规则： 确定服务或资源是否处于 OK 状态的阈值和规则。例如，如果服务或服务器正在运行并提供请求，则可能被视为健康；而资源（如存储）可能在利用率达到一定阈值一段时间后触发警告
• 通知规则： 确定是否应发送通知的阈值和规则。虽然通知很重要，但同样重要的是调整通知规则，以便您不会收到太多通知；满是警告和提醒的收件箱通常会被忽略，使它们几乎和没有通知一样无用

相关教程

• 如何在 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并集中日志

结论

当您将所有组件放在一起时，您的生产环境可能看起来像这样：

!Production

现在您已经熟悉了可以用来支持和改进生产服务器设置的组件，您应该考虑如何将它们集成到您自己的服务器环境中。当然，我们没有涵盖所有可能性，但这应该给您一个开始的方向。请记住，根据您可用的资源和自己的生产目标的平衡来设计和实施服务器环境。

如果您有兴趣设置类似上述环境，请查看本教程：构建生产环境：Web应用程序。