架构之美-软件实现分析之道

「爱情、让人受尽委屈。」 2022-08-28 10:39 127阅读 0赞

在一个系统中，模型和接口是相对稳定的部分。  
但同样的模型和接口，若采用不同实现，稳定性、可扩展性和性能等诸多方面相差极大。只有熟悉实现，才有改代码写新需求的基础。

“看实现”的确是个大难题，因有无数细节怪在等你。所以，团队的新人都需要几个月试用期去熟悉代码细节。

你不可能记住项目所有细节，但这不妨碍你工作。但若你心中没有一份关于项目实现的地图，你就一定会迷失。

新人一般用几个月熟悉代码，就是在通过代码一点点展开地图，但是，这不仅极其浪费时间，也很难形成整体认知。

> 推荐你应该直接把地图展开。怎么展开？

要找到两个关键点：软件的结构和关键的技术。

以Kafka为例，了解一个软件设计三步走：“模型、接口、实现”。  
先看Kafka的模型和接口。

# MQ的模型与接口 #

Kafka自我介绍是个分布式流平台，这是它现在的发展方向，但更多人觉得它是个MQ。  
MQ是Kafka这个软件的核心模型，而流平台显然是这个核心模型存在之后的扩展。所以，要先把焦点放在Kafka的核心模型——MQ。

MQ（Messaging Queue）是一种进程间通信方式，发消息的一方（即生产者）将消息发给MQ，收消息的一方（即消费者）将队列中的消息取出并处理。

看模型，MQ是很简单的，不就是生产者发消息，消费者消费消息，还有个topic，区分发给不同目标的消息。

基本接口也很简单：  
生产者发消息：  
![201185670ef445798199f9224f4bb5c4.png][]  
消费者收消息：  
![在这里插入图片描述][77042fe28bee460b9321cfda28384769.png]  
看完模型和接口，你会感觉MQ本身并不难。

但MQ实现有很多，Kafka只是其中一种，为什么会有这么多不同MQ实现呢？因为每个MQ实现有所侧重，有其适用场景。

MQ还提供一定的消息存储能力。当

Pro发消息速度>Con处理消息速度

MQ可起到缓冲作用。所以MQ还能“削峰填谷”：在消息量特别大时，先把消息收下来，慢慢处理，以减小系统压力。

Kafka之所以突出于一大堆MQ实现，关键在于它针对消息写入做优化，它的生产者写入特快，即吞吐力特强。

显然，接口和模型不足以将Kafka与其他MQ实现区分。所以，必须开始了解它的实现。  
看软件实现时的关键：

*  软件的结构
 *  关键的技术

模型是个抽象概念，被抽象的对象可以是某个聚合实体(订单中心中的订单)，也可以是某个流程或功能(Java内存模型中的主存与缓存同步的规则)。  
分层对模型来说是实现层面的东西，是一种水平方向的拆分，是一个实现上的规范；  
模型的细粒度拆分（父模型、子模型），应该是一种垂直维度的拆分，子模型的功能要高内聚，其复杂性不该发散到外部。

# 软件结构 #

软件结构也是软件模型，只不过，它不是整体上的模型，而是展开实现细节之后的模型。模型是分层的。

对每个软件，当你从整体去了解它时，它是完整的一块。但当你打开它的时候，就成了多模块组合，这也是“分层”意义。上一层只要使用下一层提供给它的接口。

所以，当打开一个层次，了解其实现时，先从大处着手。最好找到一张结构图，准确了解它的结构。

如果你能够找到这样一张图，你还是很幸运的。因为在真实的项目中，你可能会碰到各种可能性：

*  结构图混乱：你找到一张图，上面包含了各种内容。比如，有的是模块设计，有的是具体实现，更有甚者，还包括了一些流程
 *  结构图复杂：一个比较成熟的项目，图上画了太多的内容。确实，随着项目的发展，软件解决的问题越来越多，它必然包含了更多的模块。但对于初次接触这个项目的我们而言，它就过于复杂了
 *  无结构图  
    想办法画一张

先了解模型和接口，因为它们永远是你的主线。

假设：现在你有了一张结构图，你打算做什么？  
了解它的结构？是，但不够。不仅要知道一个设计的结果，最好还要推断出设计原因。

所以，一种更好的做法：带问题上路。  
假设自己就是这个软件设计者，问问自己要怎么做。再去对比别人的设计，你就会发现，自己的想法和别人想法的相同或不同。

让你来设计MQ，你会怎么做？  
Kafka网上能搜到各种架构图，看个 最简单的架构图，因为最贴近MQ基础模型：  
![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASmF2YUVkZ2Uu_size_20_color_FFFFFF_t_70_g_se_x_16][]  
你能看到什么？

*  Kafka的生产者一端将消息发给Kafka集群
 *  消费者一端将消息取出来进行处理

这样的结构和你想的是不是一样？

> 进一步设计，会干啥？

*  生产者端封装出一个 SDK，负责消息的发送
 *  消费者端封装出一个 SDK，负责消息的接收
 *  设计一个集群系统，作为生产者和消费者之间的连接

可以问自己更多的问题：  
生产端如果出现网络抖动，消息没有成功发送，怎么重试？  
消费端处理完的消息，如何保证集群不重复发送？  
为什么要设计一个集群呢？要防止出现单点的故障，而一旦有了集群，就会牵扯到下一个问题，集群内的节点如何保证消息的同步呢？  
消息在集群里是怎么存储的？  
生产端也好，消费端也罢，如果一个节点彻底掉线，集群该怎么处理呢？  
……

有了更多问题，你就会在代码里更深入探索。你可根据需要，打开对应模块，进一步了解实现：  
比如消息重发问题，可看生产端是如何解决的。当问题细化到具体实现时，就可以打开源码，去寻找答案。

结构上，Kafka不是一个特复杂系统。所以，若你的项目更复杂，层次更多，推荐把各层次逐一展开，先把整体结构放在心中，再做细节探索。

# 核心技术 #

就是能够让这个软件的“实现”与众不同的地方。  
了解关键技术可保证我们对代码的调整不会使项目出现明显劣化。  
大多数项目都愿意把自己的关键技术讲出来，所以，找到这些信息不难。

## Kafka ##

对写入做了专门优化，使其整体吞吐能力很强。

> 咋做到的？

MQ实现消息存储的方式通常是把它写入磁盘，而Kafka不同之处在于，它利用磁盘顺序读写特性。  
普通机械硬盘：

*  随机写，需按机械硬盘方式寻址，然后磁头做机械运动，写入很慢
 *  顺序写，会大幅减少磁头运动

可以这样实现，也是充分利用MQ本身特性：有序，**技术实现与需求完美结合的产物**。还可进一步优化：利用内存映射文件减少用户空间到内核空间复制的开销。

若站在了解实现的角度，你会觉得这都很自然。

> 但要想从设计角度学到更多，还是应带着问题上路，多问自己，为什么其它MQ不这么做？

这的确值得深思。Kafka这个实现到底是哪里不容易想到呢？  
**软硬结合。**

其它MQ实现也会把消息写入文件，但文件对于它们只是个通用接口。开发者并没有想过利用硬件的特性做开发。而Kafka开发者突破此限制，把硬件特性利用起来，取得更好结果。

## LMAX Disruptor ##

最强劲的线程通信库。经典代码片段：  
![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASmF2YUVkZ2Uu_size_20_color_FFFFFF_t_70_g_se_x_16 1][]  
要理解这段代码，必须理解CPU缓存行，这也是软硬结合的设计。  
Disruptor缓存行填充中的填充字段。Disruptor中的一个元素是个volatile long类型，占用8字节。  
一但一个元素被修改，则与其在同一缓存行的所有元素的缓存都会失效。这就导致变更索引位1的元素，会导致索引位0的元素缓存也失效(操作时需重新从主内存加载)。  
所以，Disruptor做了一个缓存行填充的优化，在目标元素的前后都加7个类型字段，两边都占据掉56个字节。故而保证每个元素都独占缓存行。是一种用空间换时间的思想。

# 总结 #

理解一个实现，是以对模型和接口的理解为前提。  
如果想了解一个系统的实现，应从软件结构和关键技术两个方面着手。无论是软件结构，还是关键技术，我们都需要带着自己的问题入手，而问题的出发点就是我们对模型和接口的理解。

了解软件的结构，其实，就是把分层的模型展开，看下一层模型：

*  要知道这个层次给你提供了怎样的模型
 *  要带着自己的问题去了解这些模型为什么要这么设计

Kafka的实现主要是针对机械硬盘做的优化，现在的SSD硬盘越来越多，成本越来越低，这个立意的出发点已经不像以前那样稳固了。

软件的结构和核心技术应该分开，kafka之所以是：

*  MQ，看的是对MQ这个模型结构的实现  
    就没必看存储的实现，应该看路由信息管理、消息生产、消息消费等核心实现及其旁支功能的选择(限制消息大小、故障节点延后、延迟消费)
 *  kafka，看的是其消息存储核心技术实现

如果想知道kafka为什么在 MQ如此突出，那就得了解其核心技术实现，即这里的软硬结合的存储设计。

**理解实现，带着自己的问题，了解软件的结构和关键的技术。**  
![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASmF2YUVkZ2Uu_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

[201185670ef445798199f9224f4bb5c4.png]: /images/20220828/802c7df17ad34f029a31551510b25a88.png
[77042fe28bee460b9321cfda28384769.png]: /images/20220828/eb4fe143ba284f6797963bd3d43e97f2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASmF2YUVkZ2Uu_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/5d3696c7f3524069bac045d84f31423e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASmF2YUVkZ2Uu_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/9c9b920efc534efe80ee0d61138a6e3e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASmF2YUVkZ2Uu_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/98d8cfd60c2b400cbdf1200b838100e4.png