架构是什么意思？

架构设计是技术人员成长和晋升过程中必须掌握的技能，虽然非常常见，但深究一下“架构”到底指什么，有多少人能够准确回答呢？

本文选自 《从零开始学架构：照着做，你也能成为架构师》

对于技术人员来说，“架构”是一个再常见不过的词了：我们会给新员工介绍整个系统的架构，参加架构设计评审，学习业界开源系统（例如，MySQL、Hadoop）的架构，研究大公司的架构实现（例如，微信架构、淘宝架构）……虽然如此常见，但如果深究一下“架构”到底指什么，大部分人不一定能够准确地回答。例如：

• 架构和框架是什么关系？有什么区别？
• Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪个架构呢？
• 微信有架构，微信的登录系统也有架构，微信的支付系统也有架构，当我们谈微信架构时，到底在谈什么架构？

要想准确地回答以上问题，关键在于梳理几个有关系而又相似的概念，包括系统、子系统、模块、组件、框架和架构。

系统与子系统

系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。

提炼*基百科定义的关键内容。

（1）关联： 系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台PC放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。

（2）规则： 系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴，将动力输出到车轮上，从而驱动汽车前进。

（3）能力： 系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。

子系统的定义其实和系统的定义是一样的，只是观察的角度有差异，一个系统可能是另外一个更大系统的子系统。

子系统也是由一群有关联的个体所组成的系统，多半是更大系统中的一部分。

按照这个定义，系统和子系统比较容易理解。我们以微信为例（以下内容仅仅是举例，微信不一定这么设计）：

（1）微信本身是一个系统，包含聊天、登录、支付、朋友圈等子系统。

（2）朋友圈这个系统又包括动态、评论、点赞等子系统。

（3）评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。

（4）评论审核子系统不再包含业务意义上的子系统，而是包括各个模块或组件，这些模块或组件本身也是另外一个维度上的系统。例如，MySQL、Redis等是存储系统，但不是业务子系统。

以下是网上公开的微信朋友圈的架构示意图。

模块与组件

模块和组件两个概念在实际工作中很容易混淆，我们经常能够听到类似如下的说法：

（1）MySQL模块主要负责存储数据，而Elasticsearch模块主要负责数据搜索。

（2）我们有安全加密组件、有审核组件。

（3）App的下载模块使用了第三方的组件。

造成这种现象的主要原因是两者的定义并不好理解，也不能很好地进行区分。我们来看看*基百科中两者的定义。

【模块】

软件模块（Module）是一套一致且互相有紧密关联的软件组织，它包含程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。

模块的接口表达了由该模块提供的功能和调用它时所需的元素。

模块是可能分开被编写的单位，这使得它们可再用，并允许开发人员同时协作、编写及研究不同的模块。

【组件】

软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易地被用于组装应用程序。

相信大部分人看完这两个定义还是一头雾水，看完也不知道到底两者有什么区别。造成这种现象的根本原因是模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。 从逻辑的角度来拆分后得到的单元就是“模块”，从物理的角度来拆分系统得到的单元就是“组件”；划分模块的主要目的是职责分离，划分组件的主要目的是单元复用。 “组件”的英文单词component对应中文的“零件”一词，“零件”更容易理解一些，“零件”是一个物理的概念，并且具备“*且可替换”的特点。

下面以一个最简单的网站系统为例，假设我们要做一个学生信息管理系统，这个系统从逻辑的角度来拆分，可以分为“登录注册模块”“个人信息模块”“个人成绩模块”；从物理的角度来拆分，可以拆分为Nginx、Web服务器、MySQL。

框架与架构

框架是和架构比较相似的概念，且两者有较强的关联关系，所以在实际工作中，很多时候这两个概念并不是区分得很清楚。

参考*基百科，框架的定义如下：

软件框架（Software Framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

提炼*基百科定义的关键部分。

（1）框架是组件规范。例如，MVC就是一种最常见的开发规范，类似的还有MVP、MVVM、J2EE等框架。

（2）框架提供基础功能的产品。例如，Spring MVC是MVC的开发框架，除了满足MVC的规范，Spring提供了很多基础功能来帮助我们实现功能，包括注解（@Controller等）、Spring Security、Spring JPA等很多基础功能。

参考*基百科，架构的定义如下（请搜索英文关键字Software Architecture，中文的词条解释很粗浅）。

Software architecture refers to the fundamental structures of a software system, the discipline of creating such structures, and the documentation of these structures.

简单翻译一下：软件架构是指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。

单纯从定义的角度来看，框架和架构的区别还是比较明显的，框架关注的是“规范”，架构关注的是“结构”。框架的英文是Framework，架构的英文是Architecture。Spring MVC的英文文档标题就是“Web MVC Framework”。

虽然如此，在实际工作中我们却经常碰到一些似是而非的说法。例如，“我们的系统是MVC架构”，“我们需要将Android App重构为MVP架构”，“我们的系统基于SSH框架开发”，“我们是SSH的架构”，“XX系统是基于Spring MVC框架开发，标准的MVC架构”……究竟什么说法是对的，什么说法是错的呢？

其实这些说法都是对的，造成这种现象的根本原因隐藏于架构的定义中，关键就是“基础结构”这个概念并没有明确说是从什么角度来分解的。从不同的角度或维度，可以将系统划分为不同的结构，其实我们在“模块与组件”中的样例已经暗含了这点，继续以学生管理系统为例。

从业务逻辑的角度分解，“学生管理系统”的架构如下图所示。

从物理部署的角度分解，“学生管理系统”的架构如下图所示。

从开发规范的角度分解，“学生管理系统”可以采用标准的MVC框架来开发，因此架构又变成了MVC架构，如下图所示。

以上这些“架构”，都是“学生管理系统”正确的架构，只是从不同的角度来分解而已，这也是IBM的RUP将软件架构视图分为著名的“4+1视图”的原因。

重新定义架构

我们参考*基百科的定义，将架构重新定义为：软件架构指软件系统的顶层结构！

这个定义很简单，但包含的信息很丰富，基本上把系统、子系统、模块、组件、架构等概念都串起来了，详细阐述如下。

首先，“系统由一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等，架构需要明确系统包含哪些“个体”。

其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。

第三，*基百科的架构定义中用到了“基础结构”这个说法，我们改为“顶层结构”，可以更好地区分系统和子系统，避免将系统架构和子系统架构混淆导致架构层次混乱。

---

本文选自 《从零开始学架构：照着做，你也能成为架构师》 ，作者李运华，电子工业出版社9月出版。

什么是架构

软件架构：从方**的角度。

在项目中遇到问题时再具体解决，属于实用主义思维的做法。

高并发、高可用和由此带来的数据一致性问题：“显性问题”

靠前，利用分布式系统的特性不断地分拆，把大系统拆小，各个击破，降低风险；

第二，小步快跑，快速迭代。

隐性问题

系统的可重用性、可扩展性、可维护性等。

一个系统由于设计问题导致研发人力的投入和时间成本的增加，往往无法显性地衡量。

“隐性问题”比“显性问题”的影响更大，因为它会让技术拖累业务，当有新需求的时候，系统无法跟随业务快速变化。

对于一个系统来说，可能既面临高并发、高可用的技术问题，又面临复杂的业务问题，所以如何处理两者的关系，打通技术和业务的任督二脉。

架构是一种综合能力，而不是某一方面的技能。

一个全面的解决方案、方**、成体系的设计思维。

什么是架构

架构是针对所有重要问题做出的重要决策。

五花八门的架构师职业

架构师职业分类

借业务架构和技术架构的融合，来建立一种系统化的思维方式和学习方法。

这种系统化的思维方法既可以帮助开发人员形成系统化的方**。

架构的分类

把软件系统自底往上分层。

靠前层：基础架构

基础架构指云平台、操作系统、网络、存储、数据库和编译器等。

第二层：中间件与大数据平台

（1）中间件架构。例如分布式服务中间件、消息中间件、数据库中间件、缓存中间件、监控系统、工作流引擎和规则引擎等。

（2）大数据架构。例如开源的Hadoop生态体系，Hive、Spark、Storm、Flink等。

第三层：业务系统架构

（1）通用软件系统。例如最常用的办公软件、浏览器、播放器等。

（2）离线业务系统。例如各种基于大数据的BI分析、数据挖掘、报表与可视化等。

（3）大型在线业务系统。例如搜索、推荐、即时通信、电商、游戏、广告、企业ERP 或CRM等。

· 对于第三层的划分并不是绝对的，通用性软件和业务软件的界限不是泾渭分明的。

什么是架构？网络架构中都有什么？终于有人讲明白了

导读： 理解架构这个词的意思是十分重要的。它可能被过度使用，并且使用在各种环境中。如果缺少一致的理解，将会有交流失败的风险。那么架构这个词到底是什么意思呢？

作者：大卫·D.克拉克（David D. Clark）

来源：华章科技

01 什么是架构？

架构是一个过程、一个结果和一门学科。

• 作为一个过程 ，它涉及将组件与设计元素结合，以此来形成一个有目的的实体。
• 作为一个结果 ，它描述了由其形式所定义的一系列实体。对于我们熟知的“哥特式大教堂”这种架构形式，它的特点是一系列公认的设计元素与方法，目的可能是构建一个礼拜场所，但“哥特式大教堂”实际上意味着更多。
• 最后， 作为一门学科 ，架构就是架构师接受训练要掌握的本领。计算机科学领域从设计物理实物的学科中借用了这个术语，例如建筑物和城市，其中包含广受认可的培训与认证过程。

架构的三个方面都适用于“真实的建筑”与计算机科学。

1. 作为一个过程

我的定义有两个重要的方面：将组件整合在一起并应用于某个目的。

• 将组件整合在一起： 这是计算机科学家在考虑模块、接口、依赖、分层、抽象以及组件复用等问题时所做的工作。这些都是设计模式，计算机科学家接受了相关的训练，在思量设计挑战时需要考虑这些设计模式。
• 应用于某个目的： 设计过程必须按照工件的预期目的来塑造，例如，是一所医院而不是一座监狱，是一个低功率处理器而不是超级计算机，是汽车中将刹车踏板挂在刹车上的网络而不是因特网。作为架构的一部分，设计师必须解决系统不能做什么（或者做得很好）与将要做什么。在计算机科学中，系统设计存在着一种危险，这是众所周知的，它被称为第二系统综合征，即首先构建一个或许把一些事做得很好的系统，然后再提出一个试图把所有事情都做得很好的替代方案的趋势。

2. 作为一个结果

在建筑设计实践中，设计通常会产生一份结果。也有一些例外，例如排房，其中一个设计会建造很多次，但大多数建筑物都只有一座。在描述结果时，架构这个术语通常意味着一类设计，以其最显著的特征为代表（例如飞拱）。这个术语适用于这个抽象类，尽管架构师必须在建筑团队接管之前将建筑描述到非常精细的程度。

当计算机科学家重新使用架构这个术语时，他们稍微重新定义了一下。关于因特网，有很多不同的网络都是基于同样的设计：我们称之为“因特网”的公共全球网络，属于企业、军队等的私有网络，以及金融网络等特殊用途的网络。

在这种环境下， 架构一词仅描述所构建的部分内容 ，给定示例的大部分设计过程都发生在之后的环节中，可能由不同的组来描述。

3. 作为一门学科

“真正的”建筑师——那些设计楼房的人——去学校里学习这一行业。作为外行，了解他们的培养方式对于我们也是有教育意义的。架构（相对于结构工程）不是建立在基础科学与工程原理之上的设计学科。建筑师通常不关心结构工程等问题，并将这些留给别人。

当然，技术考虑可能需要尽早进入设计过程，因为建筑师要处理诸如能源效率或抗震等问题，但是建筑师主要是在设计过程中训练出来的。他们学的不是工程而是建筑。他们通过案例研究来学习，需要观察大量的建筑物，看它们有多适合（或不适合），看它们是否满足用户的需求，在视觉上是否有吸引力，如何处理设计权衡，等等。

在计算机科学中，我们往往希望设计能基于强大的工程基础、具有限制性的理论以及优先的设计选项等，但（至少在过去）系统架构的大部分业务都更类似于建筑师的业务（例如，从以前的设计中学习，问问什么运转良好、什么效果不佳，问问这个设计是否与目标相符合）。

我们在理论和实践方面对计算机科学家进行训练，但往往不赞成研究以前的设计，我们认为它们“不科学”或“未基于基本原理”。

我个人对试图使架构更加严谨而感到兴奋，但是不应该用“凭直觉”设计这样的短语来反对我们今天所做的事情。我们的学科是一门设计学科，就像建筑架构一样， 我们应该努力超越它，而不是摒弃它。

因此，如果因特网的架构不是完整的规范，而只是该规范的一部分，那么架构中包含哪些内容呢？我们可以说说不包括什么。看看基于因特网技术的所有不同网络的例子，或者全球因特网的不同区域，试着发现它们的不同之处。我们看到它们在性能、弹性、对移动性的容忍、对安全性的关注等方面存在差异。

这个级别的设计决策构建在核心架构之上，但是没有被核心架构指定。那么，我们应该在这个核心架构中看到什么呢？

02 网络架构的要素

我确定了可以 决定某个特定问题是否上升到架构级别的几个标准： 对于系统的正常工作，是否需要就该问题达成一致；就该问题达成一致是否方便；该问题是否定义了系统的基本模块性或功能依赖；或者该问题随着时间的推移是稳定的这一点是否重要。

1. 对于系统的正常工作，我们必须一致同意的问题

例如，因特网架构是基于包的使用，以及假设包头总是具有相同的格式（不同的设计可能允许在不同的区域使用不同的格式，在这种情况下，架构可能会选择描述为所需的转换提供什么样的架构支持）。

另一个例子是，当我们靠前次设计因特网时，认为设计依赖于单一的全球地址空间。现在很显然这种假设是不必要的，不需要就地址的统一含义达成全球一致。网络地址转换设备或“NAT箱”，允许因特网边缘的区域使用私有地址空间，并仅在数据包向外传输到公共因特网时才将这些地址转换为全局路由地址。

有趣的是，一旦因特网设计师意识到他们可以使用具有不同地址空间的区域来构建网络，就不需要急于扩展架构来对不相交地址空间是如何互连的提供任何支持或指导。

2. 便于达成一致的问题

我们没有要求应用使用域名系统（DNS），但由于基本上所有应用设计人员都使用它，因此它已经强制成为因特网的一部分，尽管DNS不是最初设计的一部分。类似地，尽管通信应用没有必要使用TCP，但是许多应用都依赖于它，以至于它也成为因特网的强制组成部分。

3. 系统的基本模块性

计算机科学使用模块这个词来描述系统的子组件：一个模块有一个特定的接口，通过这个接口可以连接到系统的其他部分，而接口下面的模块内部结构是隐藏的，不能从模块外部访问。

模块的设计人员通常会保持接口规范不变，因为其他模块可能依赖于该接口，但是可以自由更改模块的内部结构，因为这些是模块的私有结构。因特网协议（IP）的规范定义了三个模块接口。它定义了两层接口： 服务接口 （在其上构建更高级别的服务）和IP层下的技术接口。它还（隐式地和部分地）定义了 AS接口 ：因特网中不同AS之间的接口。

服务接口是因特网的尽力而为包级的传送模型：如果端节点发送一个数据包，并在数据包中使用有效的目的地IP地址，就目前的网络能力而言，因特网的路由器将把数据包转发到由该IP地址定义的目的接口。服务接口隐藏了如何使用特定技术在因特网内提供通信路径的所有细节。

因此，这个服务接口定义了网络和端节点之间的抽象接口。该接口的技术细节依赖于用于连接到端节点的特定网络技术，并根据技术的具体情况而有所不同， 因此这些细节不属于架构规范的一部分。

4. 功能依赖

架构的一个方面是明确设计的功能依赖。我将用因特网来说明这意味着什么。

因特网的基本操作很简单。路由器在后台计算路由表，这样它们就知道到因特网所有部分的路由。当收到数据包时，它们会查找最佳的路由，并将数据包发送到该路由上。虽然在因特网内有很多东西在运行，但在内核上，它所做的就是这个。因特网的正常运行必然取决于路由器的正常运行。

但是因特网还需要什么来提供服务呢？ 事实上，因特网的早期设计师试图限制使用的服务或要运行的组件的数量，以确保数据包流动。早期的设计目标如下：“如果有两台计算机挂到网络上，并且每台计算机都知道另一台计算机的地址，那么它们应该能够通信。不应当再需要其他任何东西”。

这种设计偏好可以表示为“最少功能依赖”的目标。一些互联网设计建议具有更多的功能依赖——它们依赖于更多的服务来启动和运行，从而使基本通信成功。在出错时，它们正在用（或许）更弱的弹性来换取功能。

5. 系统中被视为持久不变的方面

在像因特网这样的系统中，我们知道很多东西将会改变。事实上，变化、升级和替换系统某些方面的能力，是成功长寿的关键。

但是在某种程度上，有些方面看起来像是持久不变的，将它们指定为设计的一部分可以提供稳定的点，系统的其他部分可以围绕这些点向前演化。

03 总结：关于架构的思考

对于我所说的架构这个词，我已经有了一个基本的概念。在我看来， 一个关键的原则是架构的极简性。 在计算机科学的背景下， 系统的架构不应该试图描述系统的每个方面。

这种架构的概念似乎与建筑物的架构有所不同。当楼房建筑师把设计图交给建造者时，规范就会完整到细节——不仅仅是形状和结构，还有电源插座的位置。

但是我不认为大部分决策是架构性的。就像我之前说的，建筑物的架构和像因特网这样的人工制品的架构之间的区别之一是，有很多网络是使用相同的因特网技术构建的，而不仅仅是一个。如果可以在不同的环境中使用因特网技术，则会有明显的好处：商业产品更便宜，也可能更成熟，几乎所有计算机系统都有相关的软件，等等。

然而，对于安全性、弹性以及其他方面，这些网络可能没有完全相同的要求，所以架构的力量不在于定义了如何构建网络（就像建筑规划描述如何建造楼房一样），而 在于允许这些需求得到满足，或许在不同的环境中以不同的方式来满足这些需求。

改述一下爱因斯坦的话，我认为架构应该尽可能小，但不要过小。有人可能会说，正如我所描述的，因特网架构最基本的方面是其偏好极简性。考虑到这一观点，给定架构所要解决的需求，我们认为的网络系统架构的范围，应该只包括那些属于我在这里列出的框架内的那些方面。

关于作者：大卫·D. 克拉克（David D. Clark） ，麻省理工学院（MIT）计算机科学与人工智能实验室高级研究科学家。20世纪80年代曾担任因特网架构组主席，长期主持因特网的设计工作，以及未来互联网技术的研究工作。

本文摘编自《互联网的设计和演化》，经出版方授权发布。

以上就是架构是什么意思？的详细内容，希望通过阅读小编的文章之后能够有所收获！