5个通用服务器设置为Web应用程序
2014-05-30
分类:系统运维
阅读()
评论()
介绍
在决定为您的环境使用哪种服务器体系结构时,需要考虑很多因素,如性能,可扩展性,可用性,可靠性,成本和易于管理。 下面是常用的服务器设置列表,每个都有简短的描述,包括利弊。请记住,此处涵盖的所有概念可以彼此不同的组合使用,并且每个环境都有不同的要求,因此没有单一,正确的配置。
一个服务器上的一切
整个环境驻留在单个服务器上。对于典型的Web应用程序,将包括Web服务器,应用程序服务器和数据库服务器。这种设置的一个常见变体是LAMP,它代表Linux,Apache,MySQL和PHP,在单个服务器上。
使用案例 :适合快速建立一个应用程序,因为它是最简单的设置可能的,但它的可扩展性和组件隔离的方式提供很少。
优点 :
缺点 :
- 应用程序和数据库争用相同的服务器资源(CPU,内存,I / O等),除了可能的性能低下外,应用程序和数据库可能使得难以确定性能不佳的应用程序或数据库
- 不容易水平扩展
相关教程 :
2.单独的数据库服务器
数据库管理系统(DBMS)可以与环境的其余部分分离,以消除应用程序和数据库之间的资源争用,并且通过从DMZ或公共互联网中移除数据库来增加安全性。
使用案例 :适合快速建立一个应用程序,但保持应用程序和数据库来自相同的系统资源的战斗。
优点 :
- 应用程序和数据库层不争用相同的服务器资源(CPU,内存,I / O等)
- 您可以通过向任何服务器需要增加的容量添加更多资源来单独垂直扩展每个层
- 根据您的设置,它可以通过从DMZ中删除数据库来提高安全性
缺点 :
- 比单服务器稍微复杂的设置
- 如果两个服务器之间的网络连接是高延迟(即,服务器在地理上彼此远离)或者带宽对于传送的数据量太低,则可能出现性能问题
相关教程 :
负载均衡器(反向代理)
负载平衡器可以添加到服务器环境中,以通过在多个服务器之间分配工作负载来提高性能和可靠性。如果其中一个负载平衡的服务器失败,其他服务器将处理传入流量,直到失败的服务器再次变得健康。它还可以用于通过使用第7层(应用层)反向代理通过相同的域和端口服务多个应用。 能够进行逆向代理负载平衡的软件示例:HAProxy,Nginx和Varnish。
使用情况 :在通过添加更多的服务器,也被称为水平缩放需要缩放的环境有用。
优点 :
- 启用水平扩展,即可通过向其中添加更多服务器来扩展环境容量
- 通过将客户端连接限制为明显的数量和频率,可以防范DDOS攻击
缺点 :
- 如果负载均衡器没有足够的资源或者配置不当,它可能会成为性能瓶颈
- 可以引入需要额外考虑的复杂性,例如在何处执行SSL终止以及如何处理需要粘性会话的应用程序
- 负载均衡器是单点故障;如果它下降,你的整个服务可以下降。高可用性 (HA)的设置是没有单一故障点的基础设施。 要了解如何实现一个HA设置,你可以阅读如何使用浮动IP地址本节 。
相关教程 :
4. HTTP加速器(缓存反向代理)
HTTP加速器或高速缓存HTTP反向代理可用于减少通过各种技术向用户提供内容所需的时间。 HTTP加速器采用的主要技术是缓存来自内存中的Web或应用程序服务器的响应,因此可以快速提供对相同内容的未来请求,同时减少与Web或应用程序服务器之间的不必要的交互。 能够进行HTTP加速的软件示例:Varnish,Squid,Nginx。
使用案例 :在内容为主的动态Web应用程序的环境中有用,或者与许多常用访问的文件。
优点 :
- 通过减少Web服务器上的CPU负载,通过缓存和压缩,提高站点性能,从而增加用户容量
- 可以用作逆向代理负载均衡器
- 一些缓存软件可以防止DDOS攻击
缺点 :
- 需要调整以获得最佳性能
- 如果缓存命中率低,则可能降低性能
相关教程 :
5.主从数据库复制
与写操作(例如CMS)相比,提高执行许多读取操作的数据库系统性能的一种方法是使用主从数据库复制。主从复制需要主节点和一个或多个从节点。在此设置中,所有更新都发送到主节点,读取可以分布在所有节点上。
用例 :适合增加读性能为一个应用程序的数据库层。 以下是具有单个从节点的主从复制设置的示例:
优点 :
- 通过在从服务器上传播读操作来提高数据库读取性能
- 可以通过专门使用主控更新来提高写性能(它没有时间提供读请求)
缺点 :
- 访问数据库的应用程序必须有一个机制来确定它应该向其发送更新和读取请求的数据库节点
- 对从属的更新是异步的,因此它们的内容可能已过期
- 如果主服务器失败,则无法对数据库执行更新,直到问题得到纠正
- 在主节点故障的情况下没有内置故障转移
相关教程 :
示例:组合概念
除了应用程序服务器之外,还可以对缓存服务器进行负载平衡,并在单个环境中使用数据库复制。组合这些技术的目的是获得每个技术的益处而不引入太多的问题或复杂性。以下是服务器环境可能类似的示例图:
让我们假设负载均衡器被配置为识别静态请求(如图像,css,javascript等),并将这些请求直接发送到缓存服务器,并向应用服务器发送其他请求。 以下是用户发送请求动态内容时会发生什么的说明:
- 用户从请求动态内容http://example.com/ (负载均衡)
- 负载均衡器向app-backend发送请求
- app-backend从数据库读取并将请求的内容返回到负载平衡器
- 负载平衡器将请求的数据返回给用户
如果用户请求静态内容:
- 负载平衡器检查缓存后端以查看请求的内容是否被缓存(缓存命中)或不缓存(缓存未命中)
- 如果缓存命中 :所请求的内容返回到负载均衡器,并跳转到第7步。 如果高速缓存未命中 :高速缓存服务器将请求转发到App-后端,通过负载平衡器
- 负载平衡器将请求转发到应用后端
- 应用程序后端读取从数据库然后返回请求的内容到负载平衡器
- 负载平衡器将响应转发到缓存后端
- 缓存后端缓存内容 ,然后返回到负载平衡器
- 负载平衡器将请求的数据返回给用户
此环境仍然有两个单点故障(负载平衡器和主数据库服务器),但它提供了上面每个部分中描述的所有其他可靠性和性能优势。
结论
现在你已经熟悉了一些基本的服务器设置,你应该知道你将使用什么样的设置为你自己的应用程序。如果你正在努力改善你自己的环境,记住一个迭代的过程是最好避免太快地引入太多的复杂性。 让我们知道您推荐的任何设置,或者想在下面的评论中了解更多信息!
觉得文章有用就打赏一下文章作者
支付宝扫一扫打赏
微信扫一扫打赏