第一章 架构设计基础

第一节 什么是架构

导读

几乎每个程序员心中都有一个成为架构师的梦想，梦想是美好的，但道路是曲折的。我也不例外，18年的时候，我开始接触架构设计，主导一个项目的重构设计，在这个过程中踩了很多坑。在这几年之中也不断的学习架构、思考和实践架构设计。

架构无处不在，架构设计是一个大家耳熟能详的词，基本都烂大街了。那对于研发技术人员来说，架构到底是指什么？估计很多人就回答不上来了。

架构定义分析

在维基百科词条中，对架构的定义是这样的：软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件模块/组件、模块/组件之间的关系，模块/组件特性以及模块/组件间关系的特性[1]。软件架构可以和建筑物的架构相比拟[2]。软件架构是构建计算机软件，开发系统以及计划进行的基础，可以列出开发团队需要完成的任务[3]。

从这段定义中，我们可以进一步概括出：

软件架构是系统（有关软件整体结构与组件）的顶层设计【rankest design】（抽象描述），她的内容包括角色【role】（软件模块/组件），关系【relation】（模块/组件之间的关系），规定【rule】（模块/组件特性以及相互间关系的特性[1]）。

精简描述为：4R架构。

软件架构指系统的顶层设计（Rankest Design），它定义了系统由哪些角色(Role)组成,角色之间的关系（Relation）和运作规则(Rule) 。

并且，一个系统的架构，只包括顶层这一个层级的架构，而不包括下属子系统层级的架构。当然，子系统也会有她自己的架构。

顶层设计【rankest design】，它是指软件架构是分层的，对应“系统”和“子系统”的分层关系。通常情况下，我们只需要关注某一层的架构，最多展示相邻两层的架构，而不需要把每一层的架构全部糅杂在一起。无论是架构设计还是画架构图，都应该采取“自顶向下，逐步细化”的方式。

角色【role】，它是指软件系统包含哪些角色，每个角色都会负责系统的一部分功能。架构设计最重要的工作之一就是将系统拆分为多个角色。最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式，拆分为多个微服务，每个微服务就是系统的一个角色。

关系【relation】，它是指软件系统的角色之间的关系，对应到架构图中其实就是连接线，角色之间的关系不能乱连，任何关系最后都需要代码来实现，包括连接方式（HTTP、TCP、UDP 和串口等）、数据协议（JSON、XML 和二进制等）以及具体的接口等。

规定【rule】，它是指软件系统角色之间如何协作来完成系统功能。我们在前面解读什么是“系统”的时候提到过：系统能力不是个体能力之和，而是产生了新的能力。那么这个新能力具体如何完成的呢？具体哪些角色参与了这个新能力呢？这就是 Rule 所要表达的内容。在架构设计的时候，核心的业务场景都需要设计 Rule。

图：

这段解释中还涉及到几个名词，模块和组件。还是来看一下他们的具体解释。

维基百科词条解释：

软件模块（Module）是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。

看完维基百科的解释，可能还是有些一头雾水。其实模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。从业务逻辑的角度来拆分系统后，得到的单元就是“模块”；从物理部署的角度来拆分系统后，得到的单元就是“组件”。划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。

其实，“组件”的英文 Component 也可翻译成中文的“零件”一词。“零件”更容易理解一些，它是一个物理的概念，并且具备“独立且可替换”的特点。

如果你是业务系统的架构师，首先需要思考怎么从业务逻辑的角度把系统拆分成一个个模块角色，其次需要思考怎么从物理部署的角度把系统拆分成组件角色，例如选择 MySQL 作为存储系统。但是对于 MySQL 内部的体系架构（Parser、Optimizer、Caches&Buffers 和 Storage Engines 等），你其实是可以不用关注的，也不需要在你的业务系统架构中展现这些内容。

架构拆解实践

kafka，Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

Kafka( [1]) 是一种高吞吐量( [2]) 的分布式发布订阅消息系统，有如下特性：

通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。

高吞吐量( [2]) ：即使是非常普通的硬件Kafka也可以支持每秒数百万( [2]) 的消息。

支持通过Kafka服务器和消费机集群来分区消息。

支持Hadoop并行数据加载。

kafka有着优良的特性，它的架构又是怎么样的尼？

我们用4R架构理论来分析一下kafka的系统。

Kafka 简要架构图

A）kafka 顶层结构是什么 ？

Producer 、Kafka Cluster 、Consumer Group

B ） Kafka 角色组成

Producer、Broker、Partition、副本(Leader/Follower)、Consumer

C）Kafka 角色关系理解

1、Producer 和 Kafka集群 关系

2、Kafka集群和Broker 关系

3、分区和副本的关系

4、Consumer Group 和 Consumer的关系

5、Gonsumer Group 和Kafka集群的关系

D）运作规则

1、Producer 发送消息到 Kafka集群

2、Kafka集群通过Broker Leader 接收 Producer的消息并且写到Partition（细节不展开）

3、一个Patition对应多个副本(冷备)备份

4、Consumer Group 通过负载均衡让Consumer消费 Patition中的消息。

到此、对一个系统比较粗的分析就出来了，kafka的架构也就出来了。对kafka的了解就更清晰了,就能做到心中有数。

总结

什么是架构？

记住4个R：软件架构指系统的顶层设计（Rankest Design），它定义了系统由哪些角色(Role)组成,角色之间的关系（Relation）和运作规则(Rule)。