cra*_*oty -1 web-applications infrastructure
我很好奇一个网络应用程序的基础设施......它是一个具有相同应用程序/源代码的克隆服务器网络，一个克隆数据库服务器网络和一个位于网络后面的媒体/资产服务器网络吗？服务器负载均衡？如果是这样，网络应用程序是否需要某种类型的功能来帮助实现这一点？
哇，这是一个非常广泛的问题 :) 这对于 serverfault 来说是非常离题的，所以它可能会被关闭一点。但由于现在是星期六下午，我有讲故事的心情，所以这里有一个答案，大致基于我们如何发展我目前工作的公司的简化版本。
简短的答案是我最喜欢的：这取决于。虽然有一些常见的模式，但没有“这就是你构建 web 应用程序的方式”的秘诀。
您的问题假设 web 应用程序在多台服务器上运行，但这不一定是正确的。每个网站都可以被认为是一个网络应用程序。像博客一样简单的东西是一个 web 应用程序，在同一个盒子上有一个数据库、代码和静态资产，没有任何高可用性。这是大多数启动 web 应用程序的启动方式。现在如果它们长大了会怎样？
在某些时候，它们超出了单个服务器的容量，因此它们会向外扩展：拆分数据库和应用程序服务器（这也处理所有静态资产）。任何非实时代码，如 cronjobs 都可以移动到另一台服务器。业务保存......现在。
因为一个健康的企业也将超越这一点。应用服务器往往易于扩展，因此您经常会看到人们在一对 HA 负载均衡器后面使用一组应用服务器。正确设置环境使用 puppet 或 func 之类的东西使它们保持同步，并为其代码使用部署方法，该方法将通过使用负载平衡器进行部署/回滚，而不会出现用户可见的停机时间。这样的设置允许您将应用服务器水平扩展到相当大的规模。
但是当然数据库会变得忙碌，因此数据库将增加一组从属设备以将读取操作卸载到上面。并且可能会构建一个缓存层来完全避免从数据库中读取数据。然后，当 master 忙于处理所有写入时，数据会被分片到多个复制链上。只要您的数据易于分片和复制，这也为您提供了很大的扩展空间。
与此同时，您的业务增长如此之快，以至于带宽和静态内容的数量也成为一个问题，因此静态资产不再由应用程序服务器提供服务，而是由一组专用服务器提供服务。也许前面有一个 CDN 来帮助处理传入的带宽。
完成所有简单的事情后，现在开始变得有趣了。当您达到这个规模时，您可能希望避免任何和所有停机时间。因此，您可以针对剩余的单点故障（例如数据库主站）查看更多高可用性选项。如果您的主数据中心出现故障，您会考虑灾难恢复。而且您还将成为互联网上各种恶意人士的目标。DDOS 攻击和试图突破您的安全边界的企图是您需要应对的持续威胁。
应用服务器是否需要一些功能来处理这一切？不，但您的环境确实如此。最好让面向客户的服务器保持笨拙和快速，并拥有智能控制机制来处理部署、一致性检查、监控和处理攻击。这允许应用服务器专注于为客户服务，这就是赚钱的原因。