设计数据密集型应用的主要关注点

设计数据密集型应用的主要关注点

设计数据密集型系统应该主要关注哪些地方？

思维导图

数据密集型应用的概念

对于数据密集型应用，CPU的处理能力往往不是第一限制性因素，关键在于数据量、数据的复杂度以及数据的多边形。与之相对于的是计算密集型，CPU就是其限制因素，例如人工智能。

数据密集型系统主要关注的三个问题：

• 可靠性
• 可拓展性
• 可维护性

可靠性

概念

当系统发送故障时，还能正常工作，还能继续为用户提供服务。例如APP首页挂了，但是用户还能正常刷视频，其实系统底下已经异常了，返回的只是缓存数据。

一般针对较大概率可能发送的、损失比较大异常场景进行故障。例如底下数据库异常、网络抖动。当发生这些异常情况时，可以进行降级等一系列操作，来避免系统彻底GG。大公司一般会有定期的故障演习来测试一下，例如把某台容器关掉，要是这台容器只有一台，关掉系统就算彻底失效了。

硬件故障

一般是指硬盘故障、内存挂载、网线被拔了等等。关键的应用都会做冗余，例如基本的多机部署，多地部署等等。也可以使用其他软件手段，例如滚动升级。

软件错误

一般就是系统bug。这类错误平时很难发现，根本原因在于你对系统的环境做了假设，例如下标一般不会小于0啊，除灵错误啊。这些假设也很难自己意识到。当发生panic了，才会发现：哦，除数竟然还能是0

针对这类错误，一般采用的方式就是各种各样的测试和快速恢复手段。例如单元测试、接口测试、全链路测试、快速回滚等等。

人为失误

人为失误的比例是相对高的，我见过很多配置文件写错了导致系统故障的。例如配置写错了、测试代码忘记删了等。

针对此类情况，只能依靠全自动的测试和监控。全自动的测试保障修改前后对外功能是一致的，监控则可以帮你迅速发现问题。

可拓展性

可拓展性是用来描述系统应对负载增加能力的术语，主要考虑以下问题：

• 如果系统以某种方式增长，怎么应对
• 如何添加计算资源来处理额外的负载

描述负载

一般是指监控系统运行情况的参数。例如QPS、TPS、CPU使用率、缓存命中率等等。

描述性能

一般主要关注吞吐量、响应时间、延迟等数据。在观察响应时间这里，一般经常采用百分位数来描述，例如p99就是百分之99的用户的响应时间。采用较高的响应时间百分位数很重要，因为它们直接影响用户的总体服务体验。

应对负载增加的方法

垂直拓展

主要使用于数据库等有状态的服务，可以直接换个高级点的机器。因为这类服务不好做分布式，这会涉及到数据分区和数据复制，里面说起来复杂度又会上升一个量级。

水平拓展

就是加机器，做分布式。适用于无状态的服务，机器A和机器B来处理效果都一样。

初创公司或尚未定型的产品还是尽量迭代比较好，过分关注于拓展需要针对系统做假设，例如哪些操作是最频繁的，数据增长最快的。一旦做了假设，后面产品发展与预期不符合，就会白白浪费人力和资源。

可维护性

你接手过屎山吗？

可运维性

是指系统运维人员运营起来是否轻松。是否在代码里面绑定了机器，是否必须要做一些神秘操作才能让服务运行等等。我还见过线上的运行的代码竟然不是master分支的代码，接手的同学发布master包到线上直接GG了。

一句话，别做反人类的事。

简单性

简化系统复杂度。能抽象的就抽象，方便外部理解。

可演化性

易于改变。是指开发新需求很容易。一般来说简单容易懂的系统改起来就越简单。当然，也要注意复用，例如没有做抽象接口的系统，每次加功能都是复制其他接口的代码然后改一下，简单是简单了，但是很难看，总有一天当你遇到“所有接口都需要改变”的需求时，复制出来的代码就是灾难。毕竟，“重复代码”是《重构》里面代码坏味道之首。