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