架构师案例分析

        架构的本质是管理复杂性，抽象、分层、分治和演化思维是我们工程师 / 架构师应对和管理复杂性的四种最基本武器。

        在我之前写的文章 《优秀架构师必须掌握的架构思维》 中，我先介绍了抽象、分层、分治和演化这四种应对复杂性的基本武器。在本篇文章中，我会通过四个案例，讲解如何综合运用这些武器，分别对小型系统、中型系统、基础架构以及组织技术体系进行架构和设计。

小型系统案例：分布式消息系统

        这个是一个真实生产化的消息系统案例，由 1 个架构师 +2 个高级工程师设计开发，第一期研发测试到上生产约 3 个月，目前该系统日处理消息量过亿。

假定公司因为业务需要，要构建一套分布式消息系统 MQ，类似 Kafka 这样的，这个问题看起来很大很复杂，但是如果你抽丝剥茧，透过现象看本质，Kafka 这样的消息系统本质上是下图这样的抽象概念：

1. 队列其实就是类似数组一样的结构（用数组建模有个好处，有索引可以重复消费），里头存放消息 (Msg)，数组一头进消息，一头出消息；
2. 左边是若干生产者 (Producer)，往队列里头发消息；
3. 右边是若干消费者 (Consumer)，从队列里头消费消息；
4. 对于生产者和消费者来说，他们不关心队列实现细节，所以给队列一个更抽象的名字，叫主题 (Topic)；
5. 考虑到系统的扩容和分布式能力，一般一个主题由若干个队列组成，这些队列也叫分区 (Partition)，而且这些队列可能还是分布在不同机器上的，例如下图中 Topic A 的两个队列分布在 DataNode1 节点上，另外两个队列分布在 DataNode2 节点上，这样以后 Topic 可以按需扩容，DataNode 也可以按需增加。当然这些细节由 MQ 系统屏蔽，用户只关心主题，不关心底层实现。

单个数组队列的建模是整个 MQ 系统的关键，我们知道 Kafka 使用 append only file 建模队列，存取速度快。假设我们要存业务数据需要更高可靠性，也可以用数据库表来建模数组队列，如下图所示：

一个队列 (或者一个分区) 对应一张数据库表，表中的一个记录就是一条消息，表采用自增 id