01 | 架构到底是指什么？

Apr 28, 2018

01 | 架构到底是指什么？-极客时间



下载APP



关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

01 | 架构到底是指什么？

2018-04-28 李运华来自北京

《从0开始学架构》

课程介绍



讲述：安晓辉

时长15:56大小14.55M



你好，我是华仔。
2018 年，我发布了《从 0 开始学架构》这门课程，分享了我之前在电信业务和移动互联网业务方面的经验和感悟。
后来，我转岗去了蚂蚁国际，从事更加复杂的支付业务。为什么说支付业务更加复杂？因为它涉及的关联方多、业务流程长、业务模型复杂，对安全、高可用、高性能等都有更高的要求。我有幸参与了一个海外钱包从 0 到 1 的建设过程，积累了不少实战经验，于是对复杂业务的架构设计有了新的理解。
2020 年，因为身体等原因，我离开了蚂蚁国际，之后就一边休养身体，一边系统地总结梳理过去的经验，先后创作了《大厂晋升指南》和《架构实战营》。在打磨课程和与各位同学交流的过程中，我对于架构学习的难点和应用的痛点，又有了新的心得体会。
因此，我决定更新这门课程的部分内容，把这些新的收获也全部分享出来，希望能帮助你与时俱进地提升架构水平。
架构到底是指什么对于技术人员来说，“架构”是一个再常见不过的词了。我们会对新员工培训整个系统的架构，参加架构设计评审，学习业界开源系统（例如 MySQL 和 Hadoop）的架构，研究大公司的架构实现（例如微信架构和淘宝架构）……
虽然“架构”这个词很常见，但如果深究一下，“架构”到底是指什么，大部分人就搞不清楚了。例如以下这些问题，你能够准确地回答吗？
微信有架构，微信的登录系统也有架构，微信的支付系统也有架构，当我们谈微信架构时，到底是在谈什么架构？
Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪个架构呢？
架构和框架是什么关系？有什么区别？
身为架构师，如果你连架构的定义都搞不清楚，那么无论是自己设计架构、给别人讲解架构，还是学习别人的架构，都会暴露问题，要么无从下手，要么张冠李戴。这无疑会成为你面试、晋升和带领团队工作时的绊脚石。
比如有些同学明明在系统架构上做了不少有价值的工作，但是在给晋升面试的评委讲解的时候，只会说“我们是微服务架构”，然后就不知道讲什么了。结果得到的评价大打折扣，晋升失败，非常可惜。
要想准确地理解架构的定义，关键就在于把三组容易混淆的概念梳理清楚：
系统与子系统
模块与组件
框架与架构
系统与子系统我们先来看维基百科定义的“系统”：
系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。
我来提炼一下里面的关键内容。
关联：系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台 PC 放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
规则：系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴，将动力输出到车轮上，从而驱动汽车前进。
能力：系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。
我们再来看子系统的定义：
子系统也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。
其实，子系统的定义和系统定义是一样的，只是观察的角度有差异，一个系统可能是另外一个更大系统的子系统。
按照这个定义，系统和子系统比较容易理解，我们以微信为例来做一个分析：
微信本身是一个系统，包含聊天、登录、支付、朋友圈等子系统。
朋友圈这个系统又包括动态、评论、点赞等子系统。
评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。
评论审核子系统不再包含业务意义上的子系统，而是包括各个模块或者组件，这些模块或者组件本身也是另外一个维度上的系统。例如，MySQL、Redis 等是存储系统，但不是业务子系统。
现在，我们可以回答第一个问题了。一个系统的架构，只包括顶层这一个层级的架构，而不包括下属子系统层级的架构。所以微信架构，就是指微信系统这个层级的架构。当然，微信的子系统，比如支付系统，也有它自己的架构，同样只包括顶层。
模块与组件模块和组件两个概念在实际工作中很容易混淆，我们经常能够听到类似这样的说法：
MySQL 模块主要负责存储数据，而 Elasticsearch 模块主要负责数据搜索。
我们有安全加密组件、有审核组件。
App 的下载模块使用了第三方的组件。
造成这种现象的主要原因是，模块与组件的定义并不好理解，也不能很好地进行区分。我们来看看这两者在维基百科上的定义：
软件模块（Module）是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。
软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
可能你看完这两个定义后一头雾水，还是不知道这两者有什么区别。造成这种现象的根本原因是，模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。
从业务逻辑的角度来拆分系统后，得到的单元就是“模块”；从物理部署的角度来拆分系统后，得到的单元就是“组件”。划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。
其实，“组件”的英文 Component 也可翻译成中文的“零件”一词。“零件”更容易理解一些，它是一个物理的概念，并且具备“独立且可替换”的特点。
我以一个最简单的网站系统来为例。假设我们要做一个学生信息管理系统，这个系统从逻辑的角度来拆分，可以分为“登录注册模块”“个人信息模块”和“个人成绩模块”；从物理的角度来拆分，可以拆分为 Nginx、Web 服务器和 MySQL。
现在，我们可以回答第二个问题了。如果你是业务系统的架构师，首先需要思考怎么从业务逻辑的角度把系统拆分成一个个模块角色，其次需要思考怎么从物理部署的角度把系统拆分成组件角色，例如选择 MySQL 作为存储系统。但是对于 MySQL 内部的体系架构（Parser、Optimizer、Caches&Buffers 和 Storage Engines 等），你其实是可以不用关注的，也不需要在你的业务系统架构中展现这些内容。
框架与架构框架是和架构比较相似的概念，且两者有较强的关联关系，所以在实际工作中，这两个概念有时我们容易分不清楚。参考维基百科上框架与架构的定义，我来解释两者的区别。
软件框架（Software framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
我来提炼一下其中关键部分：
框架是组件规范：例如，MVC 就是一种最常见的开发规范，类似的还有 MVP、MVVM、J2EE 等框架。
框架提供基础功能的产品：例如，Spring MVC 是 MVC 的开发框架，除了满足 MVC 的规范，Spring 提供了很多基础功能来帮助我们实现功能，包括注解（@Controller 等）、Spring Security、Spring JPA 等很多基础功能。
软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。
单纯从定义的角度来看，框架和架构的区别还是比较明显的：框架关注的是“规范”，架构关注的是“结构”。
框架的英文是 Framework，架构的英文是 Architecture，Spring MVC 的英文文档标题就是“Web MVC framework”。
虽然如此，在实际工作中我们却经常碰到一些似是而非的说法，例如：
我们的系统是 MVC 架构。
我们需要将 Android App 重构为 MVP 架构。
我们的系统基于 SSH 框架开发。
我们是 SSH 的架构。
XX 系统是基于 Spring MVC 框架开发，标准的 MVC 架构。
……
究竟什么说法是对的，什么说法是错的呢？
其实这些说法都是对的。造成这种现象的根本原因隐藏于架构的定义中，关键就是“基础结构”这个概念，并没有明确说是从什么角度来分解的。采用不同的角度或者维度，可以将系统划分为不同的结构，其实我在“模块与组件”中的“学生管理系统”示例已经包含了这点。
从业务逻辑的角度分解，“学生管理系统”的架构是：
从物理部署的角度分解，“学生管理系统”的架构是：
从开发规范的角度分解，“学生管理系统”可以采用标准的 MVC 框架来开发，因此架构又变成了 MVC 架构：
这些“架构”，都是“学生管理系统”正确的架构，只是从不同的角度来分解而已，这也是 IBM 的 RUP 将软件架构视图分为著名的“4+1 视图”的原因。
现在，我们可以回答第三个问题了。框架是一整套开发规范，架构是某一套开发规范下的具体落地方案，包括各个模块之间的组合关系以及它们协同起来完成功能的运作规则。
重新定义架构：4R 架构参考维基百科的定义，再结合我自己的一些理解和思考，我将软件架构重新定义为：软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。
因为这个定义中的 4 个关键词，都可以用 R 开头的英文单词来表示，分别是 Rank、Role、Relation 和 Rule，所以我把定义简称为“4R 架构定义”，每个 R 的详细解释如下。
第一个 R，Rank。它是指软件架构是分层的，对应“系统”和“子系统”的分层关系。通常情况下，我们只需要关注某一层的架构，最多展示相邻两层的架构，而不需要把每一层的架构全部糅杂在一起。无论是架构设计还是画架构图，都应该采取“自顶向下，逐步细化”的方式。以微信为例，Rank 的含义如下所示：
注：L0\L1\L2 指层级，一个 L0 往下可以分解多个 L1，一个 L1 可以往下分解多个 L2，以此类推，一般建议不超过 5 层（L0~L4）。
第二个 R，Role。它是指软件系统包含哪些角色，每个角色都会负责系统的一部分功能。架构设计最重要的工作之一就是将系统拆分为多个角色。最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式，拆分为多个微服务，每个微服务就是系统的一个角色。
第三个 R，Relation。它是指软件系统的角色之间的关系，对应到架构图中其实就是连接线，角色之间的关系不能乱连，任何关系最后都需要代码来实现，包括连接方式（HTTP、TCP、UDP 和串口等）、数据协议（JSON、XML 和二进制等）以及具体的接口等。
第四个 R，Rule。它是指软件系统角色之间如何协作来完成系统功能。我们在前面解读什么是“系统”的时候提到过：系统能力不是个体能力之和，而是产生了新的能力。那么这个新能力具体如何完成的呢？具体哪些角色参与了这个新能力呢？这就是 Rule 所要表达的内容。在架构设计的时候，核心的业务场景都需要设计 Rule。
在实际工作中，为了方便理解，Rank、Role 和 Relation 是通过系统架构图来展示的，而 Rule 是通过系统序列图（System Sequence Diagram）来展示的。
我们以一个简化的支付系统为例，支付系统架构图如下所示：
“扫码支付”这个核心场景的系统序列图如下所示：
小结今天我为你梳理了与架构有关的几个容易混淆的概念，包括系统与子系统、模块与组件、框架与架构，并且提炼出了 4R 架构定义，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧。你原来理解的架构是如何定义的？对比我今天讲的架构定义，你觉得差异在哪里？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）

分享给好友，一起充电成长

赞 205

提建议

开篇词 | 照着做，你也能成为架构师！

02 | 架构设计的历史背景

 写留言

精选留言(463)

公号-技术夜未眠
2018-04-28
架构是顶层设计；框架是面向编程或配置的半成品；组件是从技术维度上的复用；模块是从业务维度上职责的划分；系统是相互协同可运行的实体。
作者回复: 精炼！
共 22 条评论
2185
每天都在找小黄车
2018-04-28
搬砖的：“头，我们要造什么？”；（做什么系统？）工程师：“龙之梦商城”；（XXX系统，比如微博系统）搬砖的：“图纸画出来了嘛？”；（架构是怎么设计的？）工程师：“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”；（相当于微博系统中的各个子系统，比如评论子系统、动态子系统、消息子系统）搬砖的：“头，说人话”；工程师：“一楼有卖衣服、化妆品的，二楼有唱歌、看电影的，三楼有吃的”；（【模块】按照逻辑区分，比如存储数据模块、搜索模块、消息推送模块）搬砖的：“有没有很知名的店啊？”；工程师：“有的，一楼有香奈儿、优衣库...、二楼有好乐迪、万达影院....、三楼有海底捞、避风塘.....”；（【组件】按照物理区分，存储数据模块对应Mysql、搜索模块对应ElasticSearch、消息推送模块对应Kafka）搬砖的：“对了，头，商城大门有啥需要叮嘱的施工规范不？或有啥简化施工工艺的新技术嘛？”；（有框架的可以用吗？）工程师猛吸了一口烟，把烟头扔在地上，用皮鞋左右撵了两下，缓缓从嘴里崩出四个字。 “老样子吧”。（Spring全家桶甩起来）
展开
作者回复: 极客时间卧虎藏龙，里面的用户个个都很有才，口才又好，长得又帅，我超喜欢😂
共 15 条评论
1054
Ivan
2018-04-28
框架是规矩，架构是按照规矩做规划。系统是学校，子系统是班级，模块是学生老师，组件是课桌椅。每一层级的作用意义和范围不一样，要求和可复用度也不一样
共 2 条评论
101
景三
2018-05-28
用人来比喻，架构是骨头，搭起整个软件。框架是大脑，约束软件应该怎么做。模块是吃喝拉撒走，负责不同的功能。组件是躯干四肢头，组成一个人。而子系统就是呼吸系统运动系统，属于软件的一部分，独立工作却又遵从指挥
作者回复: 很形象😂
共 6 条评论
84
顿晓
2018-04-28
我们要做的东西都能抽象为一个系统，架构既可做动词也可做名词，作为动词就代表系统的设计，作为名词就代表系统的表现形式。所以架构首先继承了系统的属性： 0、系统整体有价值 1、由多个有关系的个体组成 2、涌现，整体大于个体之和，也就是文中说的“流”出来的新的价值系统的架构从无到有由人来执行，所以也具备人思考和交流的属性： 0、思维带宽较小，不能同时考虑很多事情，需要把系统做分解（模块和组件） 1、线性思想和交流，多维关系要降级到二维关系（4+1视图等多种方法论） 2、人作为个体的个性化-也即多样性，架构没用统一标准，适合自己/团队/公司最重要。
展开
作者回复: 你已经开始解剖架构的本质了，后面章节会讨论这个话题。通常“架构”还是用作名词，动词就用“架构设计”，有的观点用“构架”，有点拗口和容易混淆，所以我一般宁愿用“架构设计”
80
wocow
2018-04-29
系统与子系统：系统是由一系列有关联，按特定规则组成的个体，并且产生新的能力，而系统与子系统则是观察的交角度不同模块与组件：模块是从逻辑角度去看待，而组件是从物理角度去看待框架与架构：框架是规范也是约束，可以理解为封闭性的话题，定义好，让别人如何去使用，而架构是一种结构，是一种开放性的话题，如何去设计组织架构，如何让架构更具有拓展性，减少沟通错误成本
展开
作者回复: 提炼了精华，赞
共 2 条评论
65
Joker
2018-05-22
是不是可以这么认为，就是做架构就是对于解决一个或者一类问题，构建一个系统，你需要为这个系统根据业务划分模块，需要加入能组合起来的组件和框架，然后你需要构建一系列规则，让这些组件和框架跑起来，各自发挥各自的能力，来实现一个个模块，然后这些模块又组合起来成了整个系统，所以做架构需要很熟悉业务，会业务逻辑划分，要熟悉很多框架，组件，知道他们的能力，熟悉怎么组合他们完美的运作起来！
作者回复: 非常正确：问题，模块，规则，系统，架构四要素😃
共 2 条评论
38
小龙
2018-07-08
框架和架构其实不一定有什么关联关系。架构是为了实现某个功能而设计的一种结构方式。虽然架构一词高大上，但你只要实现了自己的功能，你的结构就是架构。有了架构，你就有了工作的思路和方向。框架是实现功能的一种规范，你必须在这种规范下工作。注意，定义中说框架是定义组建的规范，所以框架里面不一定非得有组建和模块。模块是从职责划分的角度来观察，实现某个功能的职责，称之为模块。比如登陆模块。要实现的某个功能，我们一般称之为模块。组件的本质是可以独立实现某项功能的零件。它的特点是独立，可替换组件与模块的区别是，组件可能是为了实现模块而实现的。但是实现功能的模块不能称为组件。
展开
作者回复: 点赞
29
tick
2018-04-28
微信是系统，微信的登录是子系统，学生管理是系统，学生管理的登录就是模块，这是为什么呢，模块和子系统啥区别?
作者回复: 子系统是独立运行的，模块是子系统的逻辑组成部分，如果学生管理系统规模很大（例如在线学校），需要支撑每秒上万的登录请求，那么学生管理的登录模块一样可以升级为子系统。
17
余红松-北京
2018-05-06
# 阅读笔记 - 关于系统：系统和子系统其实都是系统，只不过在本业务里边的分层不同，只有顶层为系统，其他都为子系统，就像目录树一样，看你目录最深有多少层， - 模块向虚(逻辑)，组件向实(代码)。 - 框架向虚(规范)，架构向实(结构)。
展开
共 4 条评论
14
线条
2018-06-24
系统根据业务或功能划分为各个模块，某些模块可能又被升级为子系统; 模块中可能使用了很多组件来实现某些具体功能 ; 同时，也可能使用了某些框架来作为开发的基础，而架构则描述了各个子系统或模块间如何协调工作。不知这么理解合理不？
作者回复: 理解正确
10
今夕是何年
2018-05-01
架构是顶层设计，框架是具体实现。
10
feiyue
2018-04-28
大道至简。架构是宏观整体，框架是微观组成。
10
雪甫
2018-05-04
我认为的架构必然结合公司或组织内部的沟通和组织形式、业务的行业规范和发展方向、研发和运维理念以及技术能力，所以软件架构我认为首先是3个层次的：业务架构、应用架构、技术架构。业务架构是公司或组织内部当前的沟通模式，换句话说用户的流程是什么？他们怎么用？也就是业务需求。应用架构是把用户的需求按照行业标准、产品规划和当前的研发能力进行结合得出最合适的功能设计，产品需求是这中间的一个产出；技术架构就是技术通常程序员说的架构，各个系统怎么有机的结合的一起，怎么快速的运维和故障处理。
展开
8
CHaNniNG
2018-04-28
关于华仔的思考题，本人刚刚接触架构，之前作为开发人员理解的架构不是很深入，基本是按照各个技术组件的组合方式来理解的，架构做得好不好，主要看技术组件能否组合得好，并满足业务特性；今天听了华仔的讲解，发现我之前忽略的业务模块的组成这一方面而单单考虑技术点了，架构其实是可以从多个角度来进行阐述的。华仔的讲解让我对架构的概念有了更加清晰和全面的了解，谢谢华仔
8
felix
2018-04-28
之前理解的架构就包含2部分，逻辑架构和物理架构，现在知道了还有开发架构
7
wudy
2020-06-27
框架偏技术，就像作者所说的是一种开发规范，是一种开发思路，应用于系统或子系统中，使得开发人员能快速设计出程序编写的代码组织结构；而架构相对偏业务一点，是针对业务需求，分解整个系统，梳理出数据流转逻辑，有哪些子系统、子模块、组件组成，他们之间的相互关系是怎么样的，需要更多的考虑未来需求的变化，考虑系统的可扩展性，可靠性，容错性等。
作者回复: 总结挺好的
5
Tunan
2018-04-28
我理解的架构就是功能划分，最后让整个软件成为架子，模块是乐高积木。在遵循已定接口规范下能按照产品需求自由组合模块之间的IO以达到需求效果。
作者回复: 这种理解适合业务系统架构设计，对于一些高性能高可用的架构不是很合适，单纯的功能划分并不能够保证高性能高可用，只能保证功能完成。
5
理想
2018-04-28
我理解的架构，是通过不同分工合作和识别不同生命周期为了一个组织或特定的目的而形成的树状结构，这种结构有利于在有限的时间内使组织内的角色完成相关的工作，从而达到业务增长的目的。而作者的这个架构应该更多地理解为软件架构，但是局限在顶层是否合适，还要看后续的文章内容阐述。
4
海格
2018-04-28
老师您好，我是一名运维，我讲讲对运维架构理解吧，运维架构指，业务系统所用到的中间价，在运维视角合理的规划，实现可靠性，高性能的为业务系统提供支撑功能。还有一个就是把运维的日常工作柔和起来做一个运维平台，这个平台实现简单，高效的完成运维的日常工作听完老师今天的分享，我的理解就是把一个系统更加细化具体的分析出来，然后逐个实现，再整合，完成我们想让系统完成的功能。
4

新人学习立返 50% 购课币

去订阅《从0开始学架构》新人首单¥68

