服务架构及单点故障导致系统雪崩探讨

很多大型网站都是从小型网站发展而来，一开始的架构都比较简单，随着业务复杂和用户量的激增，才开始做很多架构上的改进。当它还是小型网站的时候，没有太多访客，一般来讲只需要一台服务器就够了，这时应用程序、数据库、文件等所有资源都在一台服务器上，具体架构如下图所示：



       随着网站业务的发展和用户量的增加，单台服务器就无法再满足需求了。大量用户访问导致访问速度越来越慢，而逐渐增加的数据也会导致存储空间不足。

这时就需要将应用和数据分离，应用和数据分离后整个网站使用四台服务器：应用服务器一台、文件服务器一台和数据库服务器二台、用于做主从同步，使数据读写分离，同时可以做灾备处理。这四台服务器对硬件资源的要求各不相同：

应用服务器业务逻辑，需要强大的CPU

数据库服务器对磁盘读写操作很多，需要更快的磁盘和更大的内存

文件服务器存储用户上传的文件，因此需要更大的磁盘空间

具体架构如下图所示：



        随着用户再增加，网站又会一次面临挑战：数据库压力太大导致整站访问效率再此下降，用户体验受到影响。一个网站，往往 80% 的业务访问集中在20% 的数据上，既然大部分业务访问集中在一小部分数据上，那就把这一小部分数据先提前缓存在内存中，而不是每次都去数据库读取，这样就可以减少数据库的访问压力，从而提高整个网站的访问速度。

具体架构如下图所示：



       使用缓存后，数据访问压力得到了缓解，但是单一应用服务器能够处理的请求连接有限，在网站访问高峰期，应用服务器就成了整个网站的效率瓶颈。使用分布式集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力和存储空间不足时，不要尝试去更换更强大的服务器，对大型网站而言，多么强大的服务器，都满足不了网站持续增长的业务需求。这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。

具体架构如下图所示：



随着网站业务越来越复杂，对数据检索的需求也越来越复杂，网站需要采用一些搜索引擎，如elasticsearch。

具体架构如下图所示：



      大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线。如大型购物交易网站都会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。

      具体到技术上，也会根据产品线划分，将一个网站拆分成许多不同的应用，同时不同的应用也对应不同的数据库，将之同的大而统的业务数据进行解藕，拆分成多个数据，每个应用独立部署。应用后台通过http restful类的接口进行数据的处理，应用前台可以通过一个超链接建立关系（在首页上的导航链接每个都指向不同的应用地址），也可以通过消息队列进行数据分发，报表类的系统建立独立数据仓库，具体架构如下图所示：



       在上图的网络架构，经常会遇到某个应用不可用导致整个系统不可用而出现雪崩，或者缓存服务器出现故障，导致数据库压力激增而出现雪崩，面对雪崩的应对策略大致如下：

1. 流量控制；

       流量控制分为网关限流与用户交互限流，网关限流可以采用nginx进行配置限流，用户交互限流采用加载动画,提高用户的忍耐等待时间或提交按钮添加强制等待时间机制

2. 改进缓存模式；

      同步改为异步刷新

3. 服务自动扩容；

      AWS的auto scaling

4. 服务调用者降级服务；

      对调用服务与被调用的服务进行隔离

      我们根据具体业务,将依赖服务分为: 强依赖和若依赖. 强依赖服务不可用会导致当前业务中止,而弱依赖服务的不可用不会导致当前业务的中止.

    不可用服务的调用快速失败一般通过超时机制来实现