一周技术思考(第34期)-系统可用性问题与数字7的渊源

1、

为什么当我们谈系统可用性问题的时候经常跟数字7有关系。

对一个事物进行总结，往往我们会列出1、2、3...出来，但是很少有人会把这个数字撑到10几个，因为大多数人的心智消化系统最大能接受到7这个数字。

再往上数，就很容易忘掉，这也就一定程度上说明了，我们做总结也好，从头开始阐述一个事情也好，最大到7就可以了。

问，一个软件系统，它的可用性跟什么有关系，跟系统可能出现的风险有关系，一定程度上可用性的问题，就是控制风险的问题。

那么，风险来自哪里，答案无疑就是【变化】。

不仅仅是系统，生活中也是如此。

只要有变化，就可能会带来风险，比如你开着一辆车行驶在马路上，如果你频繁的并线，就会增加交通事故的风险。

软件系统更是这样，上线一个系统之后，如果一直没有需求、访问量一直平稳、研发人员也一直不去变更上线，那么，这个系统出现事故的几率就很小。

但这是理想的情况。

因为唯一不变的就是变化。

2、

那，我们的系统软件的变化都来自哪些方面呢。

我先贴一张图给大家做个展示。

图2《高可用的本质》一文

这张图显示了一个“系统生态”的组成的各个部分，计算系统、存储系统、上游系统、下游系统、人、硬件设备和时间。

细心的你发现刚好是7个部分，恰好发生变化的地方也是这个7个部分。

接下来，我会逐一详细阐述说下这7大方向的变化。

3、

3.1、计算系统

让我们先看计算系统，这是最核心的部分。

当谈到计算系统的时候，我们很容易就会想到比如CPU、内存、和网络IO这些内容。因为这也是我们最为要关心的服务器的运行资源。对于内存，它有点特殊性，计算系统和存储系统里面都有它的身影。

一个软件程序为什么能运行起来，以WEB程序为例，我们把可执行的程序打成WAR包，放入Tomcat容器中，一般情况下容器为每个用户请求分配一个线程，再由JVM进程管理，继而有操作系统执行进程管理，所有这一切的基础又是物理服务器上的CPU、内存、磁盘和网卡资源再支持着。

计算系统这个部分会可能发生什么样的变化呢，主要起因是线程的变化，或者说是线程的数量变化引起了问题的变化。因为只要提供服务就有用户请求，在同步阻塞的IO模型下，一请求一线程，当Tomcat执行一个业务逻辑耗时很长代码的时候，就会很容易发生线程在短时间积压的问题，继而最终导致程序不可用。

可能你会说，那我选择其它IO模型就可以了吗，比如同步非阻塞、多路复用甚或是异步IO，这个就要我们理解这些不同的IO模型它们之间的本质区别了，当用户线程发起I/O请求后，网络数据的读取会涉及两个步骤。

1、用户线程等待内核将数据从网卡拷贝到内核空间；

2、内核将数据从内核空间拷贝到用户空间；

这四种IO模型的本质区别就是，它们实现这两个步骤的方式不一样。你比如说，我们熟悉的同步非阻塞相比较于同步阻塞，它们之间的区别在于当用户线程发起IO的read请求之后到内核从网卡上读取了数据并开始将数据从内核空间往用户空间拷贝之前的这段时间的处理方式不同。

同步阻塞在发起IO的read请求之后就阻塞了，而同步非阻塞，在第一次发起IO的read请求之后会不停地反复调用read请求，所以我们就认为了它不阻塞。

但是，当内核将数据从网卡上读取数据就绪后，开始拷贝数据的时候，也就是从内核空间将数据拷贝到用户空间这段时间，同步非阻塞实际上也是阻塞的，哪怕IO多路复用，在这个阶段也是阻塞的，IO多路复用是进阶版的同步非阻塞模型，它只是多了一个select的使用，利用事件触发机制来告诉用户线程什么时候内核准备好了数据。

但是，到最后内核将数据从内核空间拷贝到用户空间这个时间段一样被阻塞。

同步非阻塞IO和多路复用IO相较于同步阻塞IO从本质上只是减少了阻塞的时间段，但是，只要有阻塞就有“积压”的风险，就存在发生从量变到质变的可能性。

等等，还有一个异步IO呢。

是的，那我们看最后这个异步IO模型，它自己的处理过程是这样的。当用户线程发起一个read调用后，会立刻注册一个回调函数，同时read请求立刻返回，不阻塞，然后等待内核将内核空间的数据拷贝的用户空间之后，再调用制定的回调函数来处理。你看在这个过程中，用户线程就一直没有阻塞呀。

是的，但是，我们永远要记住一句话：在我们的软件程序领域中，成本永远不会消失，只会转移。

上面的异步IO模型中多出来的回调函数存在那里了呢，如果有持续很大量的请求，就会产生大量的回调函数，存储回调函数的空间也一样就有可能发生从量变到质变的可能。这个空间可能就是内存空间了，这个回调函数所占的大小可能是极小的，在某种程度上异步IO可以增加请求极限情况下的容忍度，但异步IO也只是在极限情况下能够延缓之前那三种IO模式下的“量变到质变的时间”，当有更大量的用户请求持续加压，一旦遇到一个拷贝问题的时候，我们的软件风险依然存在。

3.2、存储系统

之前提到计算机的内存可以被用来计算也可以被用来存储，那是因为我们知道CPU访问内存的速度要远大于外部设备，就需要CPU提前将数据读到内存里面。

内存是我们最快和最容易想到的一种存储。

实际上，我们依赖的外部缓存、数据库等也都是属于存储的范畴。

这里，我们以缓存举例。

比如，当我们使用redis缓存的时候，我们可能会遇到缓存中的数据跟数据库中数据不一致的情况。要保证缓存和数据库数据一致，我们一般采用同步直写的方式，这个过程中就要在业务应用程序中使用事务机制，进而保证缓存和数据库的更新符合原子性。

这期间就有发生变化的可能性，如果一方写失败了，就会导致数据的不一致性，也就出现了我们所说的变化的风险。

当然，我们会有我们的保障措施，比如重试机制，依靠重试来保障最后的一致性。

也可能会遇到缓存雪崩的问题，当缓存中的大量数据同时过期，进而产生缓存中的数据缺失，前台用户的请求就会被传递到数据库上面，如果用户请求持续增大，最终可能导致数据库不可用。

这个过程中的数据保存时间大量的同时过期就是一种变化。

当然，我们的应对措施可以在设置过期时间的时候增加一个小的随机数。

另外，使用Redis缓存也会遇到缓存被击穿的情况发生，当用户请求频繁地访问缓存中的某个热点数据的时候，缓存无法在短时间内进行处理，用户请求就会被送到后端的数据库上，这个跟缓存雪崩有些类似，只是缓存雪崩影响的面更大些。

其实，当缓存中的热点key被极限大的请求量访问的时候，也会有雪崩的风险发生。这个过程中的变化就是热点数据不能被缓存系统处理而发生的。

缓存还有一个问题，就是缓存穿透，这种情况就是缓存和数据库中都没有要请求的数据。对于这个问题的解决办法是在应用程序中增加布隆过滤器来处理。

其实，我们的数据库中的单表的数据量发生骤增，服务器上的堆内存空间占用持续增大，这些也都是存储系统中的变化，这些变化同样也会给我们的软件系统带来风险。

3.3、硬件设备

硬件会坏，这就是变化。

我记得好几年前，当初公司逐步开始容器化的时候，有部分研发同学对容器的使用很没有信心，因为在将应用程序逐步发布到容器的过程，经常会收到“容器毁掉”的短信通知。也记得很清楚，运维的一个同事讲了一个大白道理，这就跟家里的冰箱、电视一样，都有可能会出现大小的问题。

所以，每年的大促备战和日常运维，都会去定期监测那些临过保的机器。硬件的损坏肯定会影响上层软件的使用，不过，现在都是基于分布式的环境，另外还有各种软硬监测机制，都会来保障当硬件损坏的情况下的系统可运行性。

3.4、上游系统

上游系统，这一说法，是对照我们上图中标识【系统】的这部分来说的。

上游系统的变化，主要就是请求变大。

一般是有3个维度的请求形式，一个是API形式的请求，比如我们的HTTP请求或者是RPC请求。第二个是key形式的请求，当然key也是嵌入到API请求中的，是API请求的一种个例，这点在存储系统中，是我们没有介绍的大key请求。第三个是网络流量的变化，也是API请求中的一种案例，如果API的数据请求数据很大，就会占用很大的网络带宽，直至造成网络阻塞。

可能，你会说其实就一种API形式的请求，是的，我们是从为了更细粒度的来说明我们可能会遇到的问题的角度说说的，把API的形式细粒度区分了API中的变化、KEY形式中的变化和网络流量的变化。

3.5、下游系统

下游系统，这一说法，是对照我们上图中标识【系统】的这部分来说的。

下游系统会发生哪些变化呢。

实际上，到这里我们就很容易想到了，在我们讲计算系统和存储系统中的可能所发生的变化，在我们的下游系统中都有可能会出现。随之而带来的变化就是相应变慢、相应出错。

下游响应变慢可能会拖慢上游，下游响应错误可能会影响上游运行结果。

3.6、人

人，实际上在我们今天所讲述的这个体系中是个最大的变数。

因为人会动。

人会上线，人会修改配置，人也会将他不会的东西发布到程序里面。

人的安全意识、对线上生产环境的敬畏意识这些都是会给系统带来变化的不稳定变量。

3.7、时间

你可能不会想到，或者压根就不会意识到，时间怎么会跟可用性有关系。

时间过期，来的总是那么突然和那么的具有全局破坏性。

比如，秘钥到期，证书到期，费用到期，跨时区，跨年，跨月，跨日等。你都要充分的考虑到。

2019年日本运营商软银因证书到期引发3000w用户长达4小时通信中断。

业务上的场景比如商家续签，商家结算，每当这个时候你都要提前有意识的提防，实在不行，就就给自己设置个年单位的闹钟吧。

以上，是我们从那幅图开始，从里面的7个方向，或者7个部分来讲述了我们系统的可用性问题一旦发生，都会来自哪些方面，现在，你应该有自己清晰的判断方向了，这些变化就是来自我们今天所讲的7个方向的内容。

4、

到了这里，你已经知道了系统可用性跟7个方向有关系，似乎跟7的故事已经结束。

接下来，我还要告诉你一个跟7相关的方向，知道了“矛”，再知道“盾”。

高可用架构设计的7大核心原则：

1、少依赖原则：能不依赖的，尽可能不依赖，越少越好

2、弱依赖原则：一定要依赖的，尽可能弱依赖，越弱越好

3、分散原则：鸡蛋不要放一个篮子，分散风险

4、均衡原则：均匀分散风险，避免不均衡

5、隔离原则：控制风险不扩散，不放大

6、无单点原则：要有冗余或其他版本,做到有路可退

7、自我保护原则：少流血，牺牲一部分，保护另外一部分

5、

本周读到一句话，分享给你。

“人生就是这样，用大部分时间迷茫，在几个瞬间成长。”

恭喜你，又完成一次思考。

参考资料：

https://mp.weixin.qq.com/s/CkFHTuxqoj1WJ7d0HUEbAg 乐羊.高可用的本质 图2出自本文

https://time.geekbang.org/column/article/295812 蒋德钧.缓存异常

https://time.geekbang.org/column/article/100307 李号双.Tomcat如何实现非阻塞IO