对软件系统的一些理解

前言

这篇文章是想表达我对系统软件的一些理解，风格跟之前的不太一样，整体偏“务虚”。我自己其实是不太擅长“务虚”的，甚至是有点排斥。就跟相比起看论文，我更喜欢看code，当然我也看论文，只不过相对来说少些。

毕业以来一直在数据库存储引擎领域工作，过去5年主要精力集中在阿里自研LSM-Tree存储引擎X-Engine研发上，并且在过去两年多时间我们完成了X-Engine的云原生架构升级和商业化，在公有云上承接一定规模的客户并稳定运行，在业界应该也是首个基于LSM-Tree架构实现云原生能力的TP存储引擎。完整经历一个TP存储引擎的架构规划、设计研发、落地上线，稳定性运维的全周期，并且得益于从我进入数据库领域一路以来经历的高水平团队、technology leader以及整个团队成员的出色工程能力和技术视野，加上我自己在此过程中的一些思考，阶段性的形成了一些自己的心得体会。

另外，跟业界一些优秀的架构师和工程师交流，发现对于系统工程的理解有很多的共鸣，也收到很多非常有价值的输入，当然也存在一些不同的观点。这也是促使我写这篇文章的主要原因，希望能将我自己的一些理解表达清楚，这些观点并不fashion，更谈不上创新，更多的是一些自己的思考和经验之谈。

对系统软件的看法

观点1：软件的本质是对硬件资源的消耗。不同软件的区别在于，消耗硬件资源去解决什么问题以及如何分配硬件资源的消耗。软件架构设计中经常提到"抽象"和“trade-off”，抽象本质上的就是"解决什么问题"，"trade-off"其实就是"如何分配硬件资源"。

举个例子TP存储引擎和AP存储引擎，从实现上可以列举出一大堆不同的地方，行存 VS 列存、二级索引 VS ZoneMap索引、强事务 VS 弱事务等等。这些不同之处其实都是结果，导致这些的根本原因是：

1）两者解决的问题不同，TP场景主要是online实时业务，这些业务的特征是整体数据规模相对较小(真正需要online处理的数据，历史数据可能很多)、请求短平快、数据locality明显、高并发低时延等，而AP场景整体的数据规模大、计算密度高、高吞吐等。(解决什么问题)

2）TP引擎的完整事务支持使得业务的并发控制简化很多，其实就是把业务系统本来需要做的事情，TP引擎自己做了，当然也就意味着TP引擎需要为此消耗一部分硬件资源。而AP引擎为了加快数据入库的速度，