下面是从应用程序代码端到网络端需要考虑的一些事情:
- Catch it和Cache it基本上都是缓存。使用缓存(Redis或memcached,对redis的+1 )来缓存(缓存/只读/数据不需要每秒更新)数据,这样您就可以避免不断地查询或从数据库或其他来源获取数据,从而减少资源的潜在超载。
- Get in一行!将传入的请求添加到队列中,并立即响应它们。然后,客户机可以通过轮询、事件流/sse或其他形式的客户机-服务器通信来跟踪响应的状态。这里的想法是使用这个请求队列异步处理用户请求并将响应推回给它们。这将需要对您的体系结构进行强烈的反思,但是,如果您还不存在,则需要切换到消息队列。您还可以添加排队等待更重的请求,这些请求可能需要比通常更长的时间,或者需要大量的资源来处理,同时保留所有其他的synchronous.
。
- Vertically扩展--可能是最简单(也是最昂贵的)事情--简单地放大主机(在CPU/核、RAM、可用带宽方面)。但请注意,到目前为止,在您真正需要更好地以更分布式的方式处理负载(如果达到流量级别的话)之前,您只能这样做。
- Perfectly均衡,因为所有事情都应该是,所以您可以设置一个负载均衡器(通过AWS、Digitalocean,如果您不使用这些负载均衡器,也许您的主机提供了一个负载均衡器),它在PHP的多个实例之间路由请求。换句话说,您需要运行PHP服务器的多个实例。同一台机器上的多个实例以及其他机器上的实例。这个设置稍微复杂一些,但它是一种经过充分尝试和测试的方法,用于构建更强的负载平衡、分布式设置.
。
- Not my concern!关注点分离--如果您有一个庞大的单块体系结构,可以考虑将您的应用程序划分成多个服务,以尝试一个微服务体系结构。这里的想法是将不同的齿轮分开,这些齿轮可以将整个体系结构相互分解成单独的可诊断单元。然后,您可以单独处理每个services/microapplications.
的缩放和可靠性问题。
还有一些其他的事情你也可以做,但是对于如何让你的web服务器变得更可靠,这些都是很好的思考点。
另一件非常重要的事情是可观察性/可观察性监测。您需要非常好的日志记录和关于您的服务器的度量,以便能够精确地确定问题。
当你开始在周日晚上得到1000名并发用户访问你的网站,重载你的数据库,几乎把你的服务器关闭,时间是最重要的。你需要能够迅速采取行动和作出反应,只有当你有信息可以采取行动时,你才能做到这一点。
访问日志很重要。同时,你可以采取的快速行动也很重要。扩展资源,增加额外的machines..etc是你可以采取的临时措施,当你研究一个更永久的解决方案时,你可以让事情保持不变。
总之,没有一个合适的解决方案。即使是大型的现代科技公司也会时不时地出现故障。几乎不可能保证100%的服务器可用性,但您肯定可以提高服务器的可靠性和可恢复性。
编辑:如果你想了解更多关于一般系统设计的知识,https://github.com/donnemartin/system-design-primer是一个非常好的资源(自述)。