如今是网站和应用程序数量爆炸的时代。如果您是企业，您需要一个相关的 Web 平台。应用程序使您能够轻松地向目标客户营销和交付您的服务。
无论创建Web 应用程序的原因如何，您都需要确定如何构建它。在部署服务器时，您有许多选项。您选择的服务器部署方案将决定您如何运行和管理环境中的所有内容。
● 适用场景：如果您时间不足，这种类型的安排效果最好。这是最简单、最快速的部署方案，它适用于简单化的 Web 应用程序。
● 优点：简单易懂，易于理解和实施;只需很少的时间即可部署全部内容。
● 缺点：不允许水平可扩展性;在组件隔离方面提供很少;由于处于同一台服务器中，应用程序和数据库本质上是在争夺相同的资源;可能遇到不佳的应用程序运行表现。
二、独立 数据库服务器
使用单台服务器的主要问题是对有限资源的竞争。这种部署方案旨在解决此问题。在这里，数据库管理系统(DBMS)与应用程序服务器保持独立。数据库服务器位于内网中，并拥有自己的资源。这可以提高性能并提高安全性。
● 适用场景：负载平衡器对于您需要执行水平缩放非常有用。水平缩放基本上意味着向环境中添加更多的服务器。您还可以使用应用层反向代理同时使用一个域名和端口为多个应用程序提供服务。Nginx就是性能非常好的反向代理服务器，用来做负载均衡。
● 好处：如果线路中的一台服务器出现故障，其他服务器会通过平衡工作负载来补偿其功能;允许您执行水平缩放以增加或减少环境容量;它还可以限制提供防止 DDOS 攻击的客户端连接。
● 缺点：如果系统资源不足，负载平衡器可能会限制应用的性能;需要适当的配置来确保适当的性能;比单台服务器或单独的服务器部署复杂得多;您需要考虑诸如 SSL 终止和需要粘性会话的应用程序等因素;使用负载平衡器的主要关注点是它是一个故障点。这意味着，如果负载平衡器无法工作，您的整个服务将下降。
四、 HTTP 加速器或缓存反向代理
您可以通过这种部署方案，来提高您为应用程序用户提供内容的速度。当用户第一次请求时，HTTP 加速器会保存其中的内容。此后，当任何类似的请求进来时，它会快速为内容提供服务，而无需与应用程序服务器交互。我们可以使用 Nginx 实现 HTTP 缓存加速。
● 适用场景：正如我们提到的，基于复制的数据库部署方案有助于提高系统的读取性能。您可以将其用于CMS等应用程序。
● 好处：它提高了数据库的读取性能，因为它将其传播到副本中;如果您仅使用主节点进行更新，您还可以提高写入性能。
● 缺点：任何尝试访问数据库的应用程序必须能够决定向哪个节点发送更新和阅读请求;如果主副本发生故障，则更新将停止。您必须解决问题才能继续更新;没有故障转移机制来适应潜在的主节点故障。
六、 使用 多种组合部署 服务器
你也可以结合各种技术和架构，以获得预期的结果。这意味着您可以在单个环境中加载应用程序服务器负载均衡与缓存服务器，并复制数据库。这样做可以让您利用两台服务器的功能。但是，它不会使部署更加复杂或麻烦。例如下图所示环境：
在这样的环境中，负载平衡器将向缓存服务器发送静态请求。静态内容包括CSS、图像和Javascript等。它将将任何其他类型的内容请求直接发送到应用程序服务器。
假设用户正在从环境中请求一些静态内容，服务器的反应如下：
● 负载平衡器将首先确定内容是缓存命中还是缓存误用。缓存命中的内容存在于缓存中，而缓存未命中的内容不存在。它通过检查缓存后端来做到这一点。
● 如果缓存命中，负载平衡器会将内容发送给用户;
● 如果缓存错过，缓存服务器将请求转发到应用程序的后端。
● 应用后端将从数据库中查找和发送内容。
● 缓存后端接收负载平衡器中的内容。它还在将其返回到负载平衡器之前缓存此内容。
● 后者然后转发给用户的响应。
另一方面，如果用户请求动态内容，将会发生如下情况：
● 请求将从用户到负载平衡器。
● 此请求请访问应用后端。
● 应用后端定位所请求的内容并将其返回到负载平衡器。
● 用户接收内容。
这种综合环境的主要好处之一是它更可靠。不仅如此，它还具有卓越的性能能力。但是，仍有两个故障点：负载平衡器和主数据库服务器。
结论
您可以在您的环境中自行使用相应的服务器部署方案。同时，您也可以将其中几个组合在一起，创建个性化的解决方案。这完全取决于您希望从架构中获得的功能。了解每种服务器部署方案的工作原理，将有助于您为自己的应用程序做出决策。最好的办法就是从小型架构开始做起，在获得经验时不断增加设置的复杂性。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至253000106@qq.com举报，一经查实，本站将立刻删除。
发布者：SEO优化专员，转转请注明出处：https://www.chuangxiangniao.com/p/896832.html
