繁杂的技术栈背后的本质是什么
对于计算机科学或技术而言，网络上存在大量的可用资源，内容涉及到了计算机技术的方方面面。如果你是一名互联网从业人员，特别是后端或中台研发人员，相信你一定在使用过或了解过MySQL、Mongo、TiDB、Kafka、Memcached、Redis、RocketMQ、RabbitMQ、Spring、Hadoop、Spark、Spark Stream、Flink、TensorFlow等等诸多中间件或技术栈，有些则通过大致的解决的问题域类型进行划分，比如关系型数据库、NoSQL数据库、时序数据库、缓存中间件、消息中间件、分布式文件系统、批处理和流式计算等等。每个技术组件都有各自要解决的细分领域问题，除了要从具体的技术细节了解每个技术中间件的使用方式之外，还需要我们从宏观的角度思考计算机系统所关注的核心问题是到底是什么。
计算机系统主要涉及三个核心问题：存储（Data Store）、计算（Compute）和通信（Communication）
不论是单机系统还是分布式系统，底层抽象都要处理如上的核心问题。数据存储关注的是数据的存取问题，如何进行数据存储和高效获取。通信关注不同单元或分布式组件间的数据交互。Compute则是基于计算机系统进行各项计算任务。
数据存储：Data Store
数据存储主要关注数据存取问题，包括存和取两个层面。
寄存器和高速缓存是最接近CPU的存储介质，具备一定的数据存储能力，访问速度快，但存储能力有限且成本比较高。内存是我们最熟悉的存储介质，相对于寄存器和高速缓存来说，内存存储容量增加但访问速度降低，同时成本也减少。另外，就是磁盘了，磁盘以文件系统形式存储数据，相比于内存的数据断电丢失风险，磁盘持久化更安全也是主要的数据存储位置。这些都是典型单机硬件层面最为直观的存储方式。
对于单机存储而言，我们除了在内存和磁盘文件系统存储数据外，基于数据结构形式和访问性能，还有数据库存储系统，典型的比如像MySQL/SQLServer/Oracle支持关系型存储的系统，再比如像MongoDB、TiDB等NoSQL数据库系统。数据库系统本质上都是基于磁盘文件系统的存储系统，但其对数据结构形式进行了逻辑抽象，支持对数据进行结构化或非结构化存储。另外，也提供了其他存储和数据访问的特性。
存储还面临的重要问题是：如果数据规模扩展至海量数据呢？单机存储能力有限，必须扩展至分布式存储领域。
对于基于磁盘文件系统而言，从单机文件系统扩展至支持海量数据存储的分布式存储，比如分布式文件系统。
对于数据库系统而言，从单机方案过渡到分布式集群方案，常规的数据库系统都支持集群化部署。
对于内存存储而言，从单机内存扩展到分布式的缓存中间件，比如像Redis、Memcache这类缓存系统。
计算：Compute
计算的逻辑模型就是基于输入进行运算并产生输出。
对于计算逻辑简单、数据输入规模小、数据存储在单机的计算场景来说，利用单机物理资源以及相应的运算逻辑在单进程内即可完成计算任务。
但如果
计算场景复杂、数据规模扩展至海量数据且是分布式存储情况下，这种复杂任务就不是单机计算能力所能承载的。因此，相应的计算模式也扩展至分布式计算。Map-Reduce就是典型分布式计算模式，基于分而治之的思想，将复杂计算认为拆分成多个小规模计算任务，并对计算结果进行聚合。MR存在的问题是中间计算结果需要频繁写入文件系统导致计算效率的降低，Spark对此作了改进，本质上是基于内存计算，降低中间结果对文件系统的写入，并且，计算过程的数据遵循就近获取原则，尽量将任务分配到离数据最近的节点进行。
不论是MR还是Spark还是属于批处理的范畴，计算实时性并不高。对于存在实时计算的场景，需要通过流式计算引擎进行处理。在流式计算领域，像Spark通过Spark Stream以支持流式计算（Spark Stream本质是是微批处理，通过缩短批处理的规模窗口模拟流式计算），另外还有Flink、TenorFlow这样的流式计算引擎。
不同的计算引擎、中间件或框架分别对应了分布式计算领域的不同问题，本质上解决的还是计算问题。
通信：Communication
解决不同组件间的信息交互问题
单进程内的单元或组件通信通过调用形式直接发生，跨进程间的通信可以通过共享内存、管道、信号量、消息等实现。
对于典型的分布式系统说，这些组件间的通信又有哪些方式呢？分布式组件间的通信的本质是通过网络进行组件间的数据传输，底层基于OSI的七层网络模型。
基于消息形式
这种形式在互联网后端系统中比较常见，分布式组件通信基于第三方的消息中间件进行。这种消息中间件一般支持发布-订阅模式，通信双方作为生产者和消费者，生产者像中间件发送数据，消费者订阅数据进行消费，由此完成通信。典型的像Kafka、RocketMQ、RabbitMQ都具备消息中间件的内力。
基于RPC调用
RPC即远程过程调用，其直观表现是像调用本地方法一样对远程进程的方法进行调用。
典型的RPC实现都会涉及请求协议的序列化和反序列化、远程节点绑定、数据传输和压缩等。RPC框架很多，比如Spring Cloud、Dubbo、gRPC、Thrift等，序列化和反序列化协议也很多，比如Json、Protocol Buffer或其他RPC框架的内置序列化协议。
基于HTTP形式
与RPC的表现形式不同，HTTP形式基于HTTP协议对远程服务URI进行调用，并路由至远程服务接口。比如基于Http Rest API或基于Web Service。
最后
存储、计算和通信是计算机系统要解决的核心问题，针对每个特定的领域有不同的细分领域问题，也有不同的技术栈或框架进行支持。从宏观的角度了解这些核心问题，是典型的基于抽象进行分析的方式，这有助于我们在繁杂的技术栈中梳理出一条知识主线，以期更好的完备自身的知识体系。
閱讀更多 瘋狂架構 的文章
