提供：ZStack云计算
内容简介
在决定使用哪种服务器架构构建业务环境时，我们总会面对诸多考量因素，例如性能、可扩展性、可用性、可靠性、成本以及管理易行性等。
在今天的教程中，我们将共同了解五套通用型服务器设置方案的各自优势与缺点，帮助大家立足于不同需求做出最为明智的选择。
1. 全部立足于单一服务器
将整套环境运行在单一服务器上。对于常见的Web应用，其中往往包含Web服务器、应用服务器与数据库服务器。这类设置的通行性方案为LAMP堆栈，即在单一服务器上使用Linux、Apache、MySQL与PHP。
用例：能够快速实现应用程序设置，但可扩展性与组件隔离性较差。
优势：
- 简便易行
缺点
- 应用与数据库使用同一套服务器资源（CPU、内存、I/O等），可能导致性能问题并难以判断性能低下的产生根源（应用还是数据库）
- 无法简单实现横向扩展
相关教程：
2. 独立数据库服务器
数据库管理系统（简称DBMS）可从环境中拆分出来以消除应用程序与数据库对资源的争夺，同时通过确保数据库远离DMZ或公共互联网而提升安全性。
用例：快速实现应用设置，且确保应用程序与数据库不致争夺同一系统资源。
优势：
- 应用与数据库层不会争夺同一服务器资源（CPU、内存、I/O等）
- 能够有针对性地对各层进行垂直扩展
- 根据实际设置确保数据库远离DMZ以提升安全性
缺点：
- 设置复杂性较单服务器方案略高
- 如果两台服务器间网络连接延迟较高，或者传输带宽不足，则可能严重影响性能表现
相关教程
3. 负载均衡（反向代理）
负载均衡机制能够将工作负载分配至多台服务器上，从而提升服务器环境的性能与可靠性。如果其中一台服务器发生故障，其它服务器能够继续处理流量直到故障服务器重新上线。另外，其也可配合7层（即应用层）反向代理用于支持同一域名及端口下的多款应用程序。
反向代理负载均衡软件推荐：HAProxy、Nginx与Varnish。
用例：通常用于要求可通过添加更多服务器实现规模扩展的环境，即横向规模扩展。
优势：
- 可通过添加更多服务器提升环境容量，即实现横向扩展规模
- 可限制客户端的访问量与频度以防止DDoS攻击
缺点：
- 负载均衡机制可能由于资源不足或配置不当而成为性能瓶颈
- 可能带来更多复杂性因素，例如如何执行SSL终端以及如何处理粘性会话应用
- 负载均衡机制属于单一故障点，一旦其发生故障则整体服务亦将下线。单点故障在高可用性系统中绝不允许存在，相关内容请参阅如何利用Floating IP章节。
相关教程：
4. HTTP加速（缓存反向代理）
HTTP加速，或者叫缓存反向代理，机制利用一系列技术降低用户的内容获取时耗。其主要技术是利用HTTP加速机制将来自Web或应用服务器的响应内容缓存在内存当中，以备后续访问。
HTTP加速软件推荐：Varnish、Squid、Nginx。
用例：适用于内容密集型动态Web应用或者包含大量高频访问文件的环境。
优势：
- 通过缓存与压缩机制降低Web服务器上的CPU负载，从而提升站点性能
- 可作为反向代理负载均衡机制
- 部分缓存软件能够抵御DDoS攻击
缺点：
- 需要精心调整方可实现理想性能表现
- 如果缓存命中率过低，可能反而影响性能
相关教程：
- 如何在Ubuntu 12.04上安装WordPress、Nginx、PHP与Varnish
- 如何利用Varnish与Nginx配置一套集群化Web服务器
- 如何在Debian与Ubuntu上利用Apache配置Varnish for Drupal
5. 主-从数据库复制
对于读取操作明显多于写入操作的数据库系统，一大性能改进方式就是使用主-从数据库复制机制。主-从复制要求一台主节点配合一台或多台从节点。在这一设置当中，全部更新都会被发送至主节点，而后再分发至集群内其它节点。
用例：显著提升应用程序数据库层的读取性能表现。
以下为单从节点条件下的主-从复制设置示例：
优势：
- 将读取负载分发至从节点以提升数据库读取性能
- 可利用主节点单独处理更新以提升写入性能（不会对读取请求造成性能影响）
缺点：
- 访问数据库的应用程序必须具备能够检测更新发送与读取请求目标的正确数据库节点的机制
- 以异步方式更新从节点，意味着部分变更可能无法及时同步
- 如果主节点发生故障，数据库的各从节点将无法实现更新
- 在主节点性故障时，无法实现故障转移
相关教程：
示例：概念整合
我们完全可以在应用服务器之外实现缓存服务器负载均衡，同时在单一环境下使用数据库复制机制。将这些技术加以结合能够充分发挥其各自优势，同时弥补它们的不足。以下示意图即为服务器环境的可行实例：
我们假设负载均衡机制根据配置要求对静态请求进行识别（例如图像、css、javascript等）并将这些请求直接发送至缓存服务器，并将其它请求发送至应用服务器。
下面来看用户发送动态内容请求后的整个执行流程：
- 用户从http://example.com/（负载均衡）处请求动态内容
- 该负载均衡将请求发送至应用后端
- 应用后端从数据库中读取内容并将请求内容返回至负载均衡
- 负载均衡将所请求数据返回给用户
如果用户请求静态内容，则：
- 负载均衡检查缓存后端以判断请求内容是否存在于内存内
- 如果缓存命中：将请求内容返回至负载均衡，而后跳至第7步。如果缓存未命中：缓存服务器通过负载均衡将请求转发至应用后端
- 负载均衡将请求转发至应用后端
- 应用后端读取数据库内容并将其返回至负载均衡
- 负载均衡将响应内容转发至缓存后端
- 缓存后端进行内容缓存，而后将其返回至负载均衡
- 负载均衡将数据返回至用户
这套环境中仍然存在两项单点故障（即负载均衡与主数据库服务器），但能够实现我们之前提到的其它全部可靠性与性能优势。
总结
现在大家已经对各类基本服务器设置有所了解，也明确了该选择哪种设置方案支持自己的应用程序。如果大家希望进一步调整整体环境，请注意采用迭代流程以避免复杂性突然激增。
本文来源自DigitalOcean Community。英文原文：5 Common Server Setups For Your Web Application By Mitchell Anicas
翻译：diradw
853
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
