架构之美-软件实现分析之道
时间：2022-09-11 07:00:00
模型和接口是系统中相对稳定的部分。
但是，如果采用不同的实现方式，相同的模型和接口在稳定性、可扩展性和性能上存在很大差异。只有熟悉实现，才能有改代码写新需求的基础。
看实现确实是一个大问题，因为有无数的细节等着你。因此，团队中的新人需要几个月的试用期来熟悉代码细节。
你不能记住项目的所有细节，但这并不妨碍你的工作。但如果你心中没有关于项目实现的地图，你就会迷路。
新人通常在几个月内熟悉代码，也就是通过代码一点一点地展开地图。然而，这不仅浪费时间，而且很难形成整体认知。
建议你直接展开地图。怎么展开？
找到两个关键点：软件结构和关键技术。
以Kafka例如，了解软件设计的三个步骤：模型、接口、实现。
先看Kafka模型和接口。
MQ模型与接口
Kafka自我介绍是一个分布式流平台，这是它目前的发展方向，但更多的人认为它是一个MQ。
MQ是Kafka该软件的核心模型，流平台显然是该核心模型存在后的扩展。因此，我们应该首先关注它Kafka的核心模型——MQ。
MQ（Messaging Queue）发送消息的一方(即生产者)是一种过程间通信方式，将消息发送给MQ，收到消息的一方(即消费者)取出并处理队列中的消息。
看模型，MQ是很简单的，不就是生产者发消息，消费者消费消息，还有个topic，分发给不同目标的消息。
基本接口也很简单：
生产者发消息：
消费者收到消息：
看完模型和接口，你会觉得MQ本身并不难。
但MQ有很多实现，Kafka只是其中之一。为什么会有这么多不同？MQ实现呢？因为每一个MQ实现重点，有其适用场景。
MQ还提供一定的信息存储能力。
Pro发消息速度>Con处理消息速度 MQ能起到缓冲作用。MQ还能“削峰填谷”：在消息量特别大时，先把消息收下来，慢慢处理，以减小系统压力。
Kafka之所以突出很多MQ实现的关键在于它优化了新闻写入，它的生产者写得很快，也就是吞吐力很强。
显然，界面和模型是不够的Kafka与其他MQ区分。因此，我们必须开始理解它的实现。
看软件实现的关键：
- 软件的结构
- 关键的技术
模型是一个抽象的概念，抽象的对象可以是聚合物实体(订单中心的订单)流程或功能(Java主存与缓存同步的规则在内存模型中)。
对于模型来说，分层是实现层次的东西，是水平方向的拆分，是实现的标准；
模型的细粒度拆分(父模型、子模型)应为垂直维度拆分，子模型的功能应高内聚，其复杂性不应扩散到外部。
软件结构
软件结构也是软件模型，但不是整体模型，而是实现细节后的模型。模型是分层的。
对于每个软件，当你从整体上理解它时，它是一个完整的部分。但当你打开它时，它变成了一个多模块组合，这也意味着分层。只要上层使用下层提供的接口。
因此，当你打开一个层次，了解实际情况时，你应该从大处开始。最好找到结构图，准确了解其结构。
如果你能找到这样的照片，你仍然很幸运。因为在真实的项目中，你可能会遇到各种可能性：
- 结构图混乱：你找到一张包含各种内容的图片。例如，有些是模块设计，有些是具体实现的，更重要的是，它还包括一些过程
- 复杂的结构图：一个相对成熟的项目，图片画了太多的内容。事实上，随着项目的发展，软件解决了越来越多的问题，它必须包含更多的模块。但对于我们第一次接触这个项目的人来说，它太复杂了
- 无结构图
想办法画一张
先了解模型和接口，因为它们永远是你的主线。
假设:现在你有了结构图，你打算做什么？
了解它的结构？是的，但还不够。不仅要知道设计的结果，还要推断设计的原因。
所以，一个更好的方法:带问题上路。
假设你是这个软件设计师，问问自己该怎么比较别人的设计，你会发现你的想法和别人的想法是一样的或不同的。
让你来设计MQ，你会怎么做？
Kafka各种架构图都可以在网上找到，看一 最简单的架构图，因为最贴近MQ基础模型：
你能看到什么？
- Kafka生产者一端发消息Kafka集群
- 消费者一端取出消息处理
这种结构和你想的一样吗？
进一步设计，会做什么？
- 生产者端封装出一个 SDK，负责发送消息
- 一个包装在消费者端 SDK，负责接收信息
- 作为生产者和消费者之间的联系，设计集群系统
你可以问自己更多的问题：
如果生产端出现网络抖动，消息没有成功发送，如何重试？
如何保证集群不重复发送消费端处理的消息？
为什么要设计一个集群呢？要防止出现单点的故障，而一旦有了集群，就会牵扯到下一个问题，集群内的节点如何保证消息的同步呢？
新闻是如何存储在集群中的？
无论是生产端还是消费端，如果一个节点完全掉线，集群该怎么办？
……
如果有更多的问题，您将在代码中进行更深入的探索。您可以根据需要打开相应的模块，进一步了解：
比如新闻重发问题，可以看生产端是怎么解决的。当问题细化到具体实现时，可以打开源代码找到答案。
结构上，Kafka这不是一个特别复杂的系统。因此，如果您的项目更复杂、更多层次，建议逐一进行各层次，首先注意整体结构，然后进行详细的探索。
核心技术
它能使软件的实现与众不同。
了解关键技术可以确保我们的代码调整不会显著恶化项目。
大多数项目都愿意谈论自己的关键技术，所以要找到这些信息并不难。
Kafka
专门优化写入，使其整体吞吐能力强。
咋做到的？
MQ通常信息存储的方法通常是将其写入磁盘，而Kafka不同之处在于，它使用磁盘顺序读写特性。
普通机械硬盘：
- 随机写作，根据机械硬盘找到地址，然后磁头做机械运动，写得很慢
- 顺序写作会大大减少磁头运动
可以这样实现，充分利用MQ本身特点：有序，技术实现与需求完美结合的产物。还可以进一步优化：利用内存映射文件减少从用户空间到内核空间复制的费用。
如果你站在理解实现的角度，你会觉得很自然。
但是，如果你想从设计的角度学到更多，你应该带着问题上路，问问自己为什么还有其他问题MQ不这么做？
这确实值得深思。Kafka哪里不容易想到这种实现？
软硬结合。
其它MQ新闻也将被写入文件中，但文件只是它们的一个通用接口。开发人员没有考虑使用硬件的特性进行开发。Kafka开发者突破这一限制，利用硬件特性，取得更好的效果。
LMAX Disruptor
线程通信库最强。经典代码片段：
要理解这个代码，我们必须理解它CPU缓存行，这也是软硬结合的设计。
Disruptor填充字段缓存行填充。Disruptor其中一个元素是一个元素volatile long占用8字节的类型。
一旦修改了一个元素，同一缓存行中的所有元素的缓存都将失效。这导致索引位1元素的变化，以及索引位0元素的缓存（在操作过程中从主内存重新加载）。
所以，Disruptor优化缓存行填充，在目标元素前后添加7个字段，两侧占据56个字节。因此，确保每个元素都独占缓存行。这是一种利用空间来改变时间的想法。
总结
理解一个实现，是以对模型和接口的理解为前提。
如果想了解一个系统的实现，应从软件结构和关键技术两个方面着手。无论是软件结构，还是关键技术，我们都需要带着自己的问题入手，而问题的出发点就是我们对模型和接口的理解。
了解软件的结构，其实，就是把分层的模型展开，看下一层模型：
- 要知道这个层次给你提供了怎样的模型
- 要带着自己的问题去了解这些模型为什么要这么设计
Kafka的实现主要是针对机械硬盘做的优化，现在的SSD硬盘越来越多，成本越来越低，这个立意的出发点已经不像以前那样稳固了。
软件的结构和核心技术应该分开，kafka之所以是：
- MQ，看的是对MQ这个模型结构的实现
就没必看存储的实现，应该看路由信息管理、消息生产、消息消费等核心实现及其旁支功能的选择(限制消息大小、故障节点延后、延迟消费) - kafka，看的是其消息存储核心技术实现
如果想知道kafka为什么在 MQ如此突出，那就得了解其核心技术实现，即这里的软硬结合的存储设计。
理解实现，带着自己的问题，了解软件的结构和关键的技术。
