系统架构之高可用与高并发

高可用设计

为什么要高可用

• 硬件故障&软件Bug，硬件是具有生命周期的，在大规模的服务器集群中，必然有一定的概率会有一些机器发生故障。
• 突发流量。

网站可用性衡量指标

网站可用性(availability)也即网站正常运行时间的百分比，业界用 N 个9 来量化可用性， 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。 百度网站的可用性号称是5个9，即99.999% 。更合理的可用性指标是正常响应流量的百分比。

如何提高网站的可用性？

基于负载均衡的故障转移

对于业务逻辑服务，一般会设计成无状态化的服务，无状态化也就是服务模块只处理业务逻辑，而无需关心业务请求的上下文信息。所以无状态化的服务器之间是相互平等和独立的。

服务冗余&服务备份

冗余备份就是针对某一个服务通过服务器集群或多机房部署来达到服务器冗余和相互备份的目的。为了达到更高的可用性，我们还可以考虑通过多机房的冗余备份，冗余备份可以达到避免单点，系统容量备份，多方式容灾等目的。

无状态服务

session的问题。

超时设置

一般网站服务都会有主调服务和被调服务之分。超时设置就是主调服务在调用被调服务的时候设置一个超时等待时间Timeout，主调服务发现超时后，主动进入超时处理流程。

例如：主调服务A调用被调服务B时，设置超时等待时间为3秒，可能由于B服务宕机、网络情况不好或程序BUG而导致B服务不能及时回复A服务的调用，此时A服务在等待3秒后，将触发超时逻辑而不再关心B服务的回复情况。A服务的超时逻辑可以依据情况而定，比如可以采取重试，或到另一个对等的B服务去请求，或直接放弃直接对外进行回包。

超时设置的好处在于当某个服务不可用时，不至于整个系统发生连锁反应。

异步调用

采用异步调用的方式调用被调服务，有利于将主调服务和被调服务进行解耦，同时提高系统的处理性能。

例如：当你在微信发布朋友圈时，微信APP的后台服务器需要把文字和图片存储到不同的服务模块上去，这时后台服务收到请求后，将两种不同的数据以异步调用的方式分发到不同的功能模块，这样的后台服务处理会更高效，同时即使图片存储模块响应时间长也不会影响到文字存储过程。

服务分级和降级

在一个大系统中，一般会有核心服务和次要服务之分，那么对于不同的服务可以采用不同的处理方案，出现故障时应该优先保证核心服务的运行。再者就是针对一个完善的服务，可能需要1-2-3 三步才能完成，但是1-2两步也可以满足基本需要，那么可以将1-2 两步完成的服务是 1-2-3三步完成的服务的降级。

监控告警

大型网站系统的服务模块众多，经常会因为各种原因出现进程core掉，网络质量不好，机器宕机等现象，我们设计的系统应该具备监控上报和告警的能力，运维和开发能够通过监控报表实时的查看系统的运行状态。服务一旦出现问题能够及时发现，通过自动化处理，或者人工介入处理，从而达到缩短系统的不可用时间，提高可用性。

防雪崩机制

对于设计的任何一个系统，都需要进行容量的预估和最大容量设置，当外部请求量超过最大容量时，应该启动防雪崩机制，以避免大量外部请求把服务压跨而不能对外提供服务。

例如A服务的最大QPS是5W/S，那么当外部请求达到5W/S时，A服务只服务5W/S的QPS，超过的部分直接拒绝服务，而不是强吞下导致A服务完全不可用。

流量缓冲机制

在服务内可以建立队列，当流量过大时，储存一定的用户请求到队列，当流量偏小时再拿出来快速处理，从而达到削峰填谷的作用。在请求数据库时，这个方案使用得很多，避免写入高峰时压跨数据库。

数据复制

数据冗余，分布式数据。

高并发设计

高并发衡量指标

响应延时 吞吐量

吞吐量是指系统在单位时间内处理请求的数量。

响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间。

空间换时间

缓存，内存换cpu

时间换空间

网络传输是瓶颈，cpu计算差值来，文件压缩

找到系统的瓶颈，从整体到细节。

减少传输的数据量。