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