支持“普通”Web 应用程序的合理设置可能会演变如下:
- 单一组合应用程序/数据库服务器
- 不同机器上的独立数据库
- 第二个使用 DNS 循环(可怜的负载平衡)的应用服务器,或者,例如Perlbal
- 其次,复制数据库服务器(对于读取负载,需要一些应用程序逻辑更改,以便合格的数据库读取转到从属服务器)
在这一点上,评估当前的事态将有助于确定更好的扩展路径。例如,如果读取负载很高且内容不经常更改,则最好强调缓存并引入专用的前端缓存,例如Squid以避免不必要的数据库读取,尽管您需要考虑如何保持缓存一致性,通常在应用程序中。
另一方面,如果内容经常发生合理的变化,那么您可能会更喜欢更分散的解决方案;引入更多的应用程序服务器和数据库从属服务器以帮助减轻影响,并使用对象缓存(例如memcached)来避免访问数据库以获取不那么易变的内容。
对于大多数站点来说,这可能就足够了,尽管如果您确实成为了一种全球现象,那么您可能会开始考虑在区域数据中心安装硬件,并使用诸如地理负载平衡之类的技巧将访问者引导到最近的“集群” ”。到那时,你可能会雇佣到真正能对事物进行微调的工程师。
可能我能想到的最有价值的扩展建议是避免过早地担心它;专注于开发人们想要使用的服务,并使应用程序相当健壮。一些简单的早期优化是确保您的数据库设计相当可靠,并设置索引,这样您就不会做任何痛苦而疯狂的事情;此外,确保应用程序发出缓存控制标头,指导浏览器如何缓存数据。在设计的早期进行此类工作可以在以后产生好处,尤其是当您不必重新设计整个事情来处理缓存一致性问题时。
我要提出的第二条最有价值的建议是,您不应该假设适用于其他网站的方法也适用于您。检查您的日志,对您的流量进行一些分析并分析您的应用程序 - 查看您的瓶颈所在并解决它们。