对于技术人员来说，“架构”是一个再常见不过的词了。我们会对新员工培训整个系统的架构，参加架构设计评审，学习业界开源系统（例如，MySQL、Hadoop）的架构，研究大公司的架构实现（例如，微信架构、淘宝架构）……虽然“架构”这个词常见，但如果深究一下“架构”到底指什么，大部分人也许并不一定能够准确地回答。例如：
架构和框架是什么关系？有什么区别？
Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪个架构呢？
微信有架构，微信的登录系统也有架构，微信的支付系统也有架构，当我们谈微信架构时，到底是在谈什么架构？
要想准确地回答这几个问题，关键在于梳理几个有关系而又相似的概念，包括：系统与子系统、模块与组件、框架与架构。
系统与子系统
我们先来看维基百科定义的“系统”。
系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。
我来提炼一下里面的关键内容：
关联：系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台 PC 放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
规则：系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴，将动力输出到车轮上，从而驱动汽车前进。
能力：系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。
我们再来看子系统的定义。
子系统也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。
其实子系统的定义和系统定义是一样的，只是观察的角度有差异，一个系统可能是另外一个更大系统的子系统。
按照这个定义，系统和子系统比较容易理解。我们以微信为例来做一个分析。
微信本身是一个系统，包含聊天、登录、支付、朋友圈等子系统。
朋友圈这个系统又包括动态、评论、点赞等子系统。
评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。
评论审核子系统不再包含业务意义上的子系统，而是包括各个模块或者组件，这些模块或者组件本身也是另外一个维度上的系统。例如，MySQL、Redis 等是存储系统，但不是业务子系统。
模块与组件
模块和组件两个概念在实际工作中很容易混淆，我们经常能够听到类似这样的说法：
MySQL 模块主要负责存储数据，而 ElasticSearch 模块主要负责数据搜索。
我们有安全加密组件、有审核组件。
App 的下载模块使用了第三方的组件。
造成这种现象的主要原因是，模块与组件的定义并不好理解，也不能很好地进行区分。我们来看看这两者在维基百科上的定义。
软件模块（Module）是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。
软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
可能你看完这两个定义后一头雾水，还是不知道这两者有什么区别。造成这种现象的根本原因是，模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。
从逻辑的角度来拆分系统后，得到的单元就是“模块”；从物理的角度来拆分系统后，得到的单元就是“组件”。划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。其实，“组件”的英文 component 也可翻译成中文的“零件”一词，“零件”更容易理解一些，“零件”是一个物理的概念，并且具备“独立且可替换”的特点。
我以一个最简单的网站系统来为例。假设我们要做一个学生信息管理系统，这个系统从逻辑的角度来拆分，可以分为“登录注册模块”“个人信息模块”“个人成绩模块”；从物理的角度来拆分，可以拆分为 Nginx、Web 服务器、MySQL。
框架与架构
框架是和架构比较相似的概念，且两者有较强的关联关系，所以在实际工作中，这两个概念有时我们容易分不清楚。参考维基百科上框架与架构的定义，我来解释两者的区别。
软件框架（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 视图”的原因。
重新定义架构
参考维基百科的定义，我将架构重新定义为：软件架构指软件系统的顶层结构。
这个定义看似很简单，但包含的信息很丰富，基本上把系统、子系统、模块、组件、架构等概念都串起来了，我来详细解释一下。
首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等；架构需要明确系统包含哪些“个体”。
其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。
第三，维基百科定义的架构用到了“基础结构”这个说法，我改为“顶层结构”，可以更好地区分系统和子系统，避免将系统架构和子系统架构混淆在一起导致架构层次混乱。
小结
今天我为你梳理了与架构有关的几个容易混淆的概念，包括系统与子系统、模块与组件、框架与架构，解释了架构的定义，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧。你原来理解的架构是如何定义的？对比我今天讲的架构定义，你觉得差异在哪里？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）
版权归极客邦科技所有，未经许可不得转载
精选留言
工程师：“龙之梦商城”；（XXX系统，比如微博系统）
搬砖的：“图纸画出来了嘛？”；（架构是怎么设计的？）
工程师：“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”；（相当于微博系统中的各个子系统，比如评论子系统、动态子系统、消息子系统）
搬砖的：“头，说人话”；
工程师：“一楼有卖衣服、化妆品的，二楼有唱歌、看电影的，三楼有吃的”；（【模块】按照逻辑区分，比如存储数据模块、搜索模块、消息推送模块）
搬砖的：“有没有很知名的店啊？”；
工程师：“有的，一楼有香奈儿、优衣库...、二楼有好乐迪、万达影院....、三楼有海底捞、避风塘.....”；（【组件】按照物理区分，存储数据模块对应Mysql、搜索模块对应ElasticSearch、 消息推送模块对应Kafka）
搬砖的：“对了，头，商城大门有啥需要叮嘱的施工规范不？或有啥简化施工工艺的新技术嘛？”；（有框架的可以用吗？）
工程师猛吸了一口烟，把烟头扔在地上，用皮鞋左右撵了两下，缓缓从嘴里崩出四个字。 “老样子吧”。（Spring全家桶甩起来）
所以架构首先继承了系统的属性：
0、系统整体有价值
1、由多个有关系的个体组成
2、涌现，整体大于个体之和，也就是文中说的“流”出来的新的价值
系统的架构从无到有由人来执行，所以也具备人思考和交流的属性：
0、思维带宽较小，不能同时考虑很多事情，需要把系统做分解（模块和组件）
1、线性思想和交流，多维关系要降级到二维关系（4+1视图等多种方法论）
2、人作为个体的个性化-也即多样性，架构没用统一标准，适合自己/团队/公司最重要。
模块与组件：模块是从逻辑角度去看待，而组件是从物理角度去看待
框架与架构：框架是规范也是约束，可以理解为封闭性的话题，定义好，让别人如何去使用，而架构是一种结构，是一种开放性的话题，如何去设计组织架构，如何让架构更具有拓展性，减少沟通错误成本
- 关于系统：
系统和子系统其实都是系统，只不过在本业务里边的分层不同，只有顶层为系统，其他都为子系统，就像目录树一样，看你目录最深有多少层，
- 模块向虚(逻辑)，组件向实(代码)。
- 框架向虚(规范)，架构向实(结构)。
学生管理是系统，学生管理的登录就是模块，这是为什么呢，模块和子系统啥区别?
模块是从职责划分的角度来观察，实现某个功能的职责，称之为模块。比如登陆模块。要实现的某个功能，我们一般称之为模块。
组件的本质是可以独立实现某项功能的零件。它的特点是独立，可替换
组件与模块的区别是，组件可能是为了实现模块而实现的。但是实现功能的模块不能称为组件。
从技术角度来说，系统架构也会描述系统的技术栈，技术选型，以及高层次的业务流程。
类比建筑行业里面的架构，如果没有好的架构支撑，就无法搭建稳固的建筑"产品"。而且架构将不可变的要素跟可变的要素进行了分离，使到建筑的例如外观，装饰，内部空间等的变化(短时内)成为可能。
所以回到软件产品(系统)，架构的引入，确实也起到了类似的作用。而且越通用的架构越低层，但是同时也未必产品构建效率和产品整体性能较佳，所以需要根据不同类型的产品进行架构设计。比如网页显示型产品(web)跟功能调用型(输出类似json等数据)的，就会有不同的架构设计。
1.如果是单体应用这种，拿MVC来说，不管是前端还是后台，我说是MVC风格，各种前后端框架比如spring mvc,angular是各种风格的实现。这个时候别人问我软件的架构是什么，我说就是单体应用架构，顶多再描述一下，系统是动静分离，还有用到了哪些组件，原来我对组件的定义就是ngix,mysql,tomcat这些。这一点和今天老师讲的差不多
2.如果是分布式系统这种复杂的软件系统，别人问及架构。我会比较多地描述系统该系统整理分为哪几块，对应老师今天说的子系统的定义，而没有像老师一样，从业务逻辑和物理视图，开发角度等不同的面去描述。如果问及具体的某一块，我会比较多地描述其上下游依赖关系，在高性能，高可用方面怎么做的。总结一下，感觉自己的定义比较含糊，除非写文档的时候才会做几张业务架构图，和中间件相关的技术架构图。老师给的定义很清楚，而工程上也确实需要这样的定义，真是学到了。特别是联想到RUP那句话，让我恍然大悟！
A framework is a pre-built general or special purpose architecture that's designed to be extended.
If an architecture is the design of a structure, a framework is the architecture of a foundation. Frameworks are specifically designed to be built on or extended.
模块算逻辑划分，国家的组成经济，政治，文化，国防，教育……。
组件算物理划分，三省六部等等。
框架算规范，三权分立，或者皇权天授，或者君主立宪，或者基本人权
构架算顶层设计 三省六部，三级议会，上下议院，等等
//框架是一组可重用，易扩展，经过良好的测试的软件组件。就如同组装汽车的流水线，我们不用理会汽车轮胎的生产过程，发动机的生产过程，xxx生产过程，只需要把各个生产出来的组件交给组装汽车的流水线（框架），那么就可以把汽车生产出来，说白了框架就是一个经过良好测试的生产机器;
主要从业务和技术两方面，业务是对业务模块进行划分，由多个业务模块有机组合成一个大的软件系统；技术方面主要是考虑系统的分层及组件依赖关系，是从技术的角度去把握如何能过支撑业务模块，最后是从系统部署和运行角度考虑物理结构；
现在理解的架构:
理解了系统，子系统，模块，组件，框架等架构中必然涉及到的一些概念和之间的区别，其实框架就是对上述这些东西的合理的组合，来满足业务需求，从而形成下来的一个逐渐演变的逻辑结构，文中提到的4+1视图能过很好的从不同角度观察系统架构，架构不再是一个概念，而是在不同视角有不同的展现形式，我们只有把每个视角都做到合理切满足业务需求，组合起来应该就是一个合理的整体架构。
个人愚见，望网友和老师指导，感谢老师分享
架构是部分组成整体的协作机制。
很模糊，总觉得是所有功能模块化，都是从业务角度上去说的，然后在想实现这些模块，需要什么语言，什么数据库，没有仔细理解过什么是架构（还比较年轻，没经历过这些设计吧😂）
今天的理解：
架构，系统顶层结构。模块化，是从业务角度来划分系统，而组件，则是可复用的单元（应该是类似中间件）。而我们要处理的就是一个新的业务，从模块上划分，它的结构是什么样的，哪个模块可以复用什么组件。
谢谢李老师，👍
逻辑架构：关注业务模块以及模块间的关键和其他系统间的交互
物理架构：系统的物理网络部署拓扑 关注系统的物理组件 例如 负载均衡 存储 消息通讯
开发架构: 关注系统开发使用框架
1）是文章中提到的物理部署架构，从用户端—ngix—web 站点—ngix—wcf—db整个流程模块所涉及到的架构设计；
2）是系统内部模块与其他系统交互的架构，有点类似文章中的业务架构和系统使用框架两块结合在一起产生的东西。
问题是，在脑海中描绘当前所负责系统的架构时，经常不知道以什么为边界，或者说以什么做最小颗粒度？
1.webserver怎么配置，如何去做负载，如何防刷；
2.持久划采用什么技术，怎么做主从，如何数据保证一致性；
3.缓存结构如何设计，如何部署；
4.通过代码利用以前的物理资源完成业务逻辑，把他们整个起来。
以上就是我以前理解的架构，
通过阅读本文，我觉得架构其实可以用多个角度来看待，它的包含可以根据角度不同而不同。
而还有个比较懵的疑问:感觉架构既可以包含系统，而每个系统又有自己的架构。二者也许不仅仅是包含与不包含那么简单。再去读一遍理解下。
另外老师文章中提到的架构关注的结构，而框架关注的是规范，仔细想来，的确如此，架构设计完成之后好比大厦的构造图，而框架好比使用架构某一部分需要遵守的规范
个人想法，多多交流😀😀
在软件生命周期中，需要从不同角度去解读系统，输出软件架构视图。4+1视图得好好掌握。
还有这里的评论也很精彩～
在工作中，常常把对架构的片面理解(自身的关注点)，当成了架构的全部，还为此与他人争论，有点盲人摸象的感觉。
文中提到了逻辑架构、开发架构、物理架构，在实际工作中，可以理解为4+1视图。要看清楚一个系统的架构，需要不同的视角，需要聚焦，这方面可以参考六顶思考帽。
#以前理解的架构师应该是框架师。😄
其次，我理解的框架是一种工具或者组件，以此来快速帮助我们来实现这个架构
架构其实也是不断地在变化和演进的。会随着业务阶段、层级的需求而不断地演化。
从本文中学到了，可以从多个角度来看系统就会得出不同的架构即顶层系统结构，比如4+1架构图。
那么有一个问题，一般在架构设计过程中，我们需要使用哪些视角的架构呢？
1:架构-这个词语不好理解，换成架构设计好理解一些，是软件开发之初对于使用什么技术，系统设计成什么样子，各个功能模块或子系统如何协助的一种规划
2:框架-是面向编程或配置的半成品，业务无关且必须的代码开发已经被其他牛逼的人或团队给做了，我们只需要按照框架的规则填充业务相关的代码就可以了
3:组件-是从技术维度上的复用，某些常用的功能无需二次开发，可直接复用已有的
4:模块-是从业务维度上职责的划分，不同的模块处理不同业务，分开来开发和使用，用于降低复杂度
5:系统-是相互协同可运行的实体，可大可小，复杂或简单都可以，也即是我们最终想要的东西，是软件组成的最核心的部分
架构设计，我觉得除了设计的方法论，技术的积累也是必须的，而且是前提，否则怎么对比孰优孰劣，该选择什么放弃什么，怎么清楚哪些技术能支持多久，还有成本、工期、实现的复杂度等问题也需要考虑一并考虑。
首先理解系统和子系统、模块和组件、框架和架构。
系统与子系统：
系统泛指由一群有关联的个体【点】组成，根据某种规则运作【线联系】，能完成个别元件不能单独完成的工作的群体。
子系统也是由一群有关联的个体所组成的系统，多半会是更大系统的一部分【个人觉得系统和子系统的关系是在一个高的层面还是在一个下面细的层面】。
模块与组件：
软件从逻辑的角度来拆分系统后，得到的单元是“模块“ - Module。
软件从物理的角度来拆分系统后，得到的单元是”组件“ - Component。
框架和架构：
框架 - Framework
架构 - Architecture
重新定义架构：软件架构指软件系统的顶层结构。
思考题：原来理解的架构是如何定义的？
为了完成一个具体的业务而在逻辑上拆分出系统、子系统和模块；在实现上选择适合的框架和组件并连通；在部署上规划出多机之间的关系。对架构的定义从角度和层面两个维度。
框架是已经存在的解决某类问题的规范
我找了些资料，说法各异，有说只是说法不同，有说模式解决了特定问题。但没有确切的区分。
我理解的是：架构模式类似设计模式，是解决特定问题的套路。架构风格只是限定了一些约束，并不解决特定问题。
就像书法，横平竖直是模式，宋体黑体是风格。
框架：一种软件开发的规范，带有系统开发的基础功能。
框架：一种软件开发的规范，带有系统开发的基础功能。
过程是特定约束下的一个个的决策，结果是最终交付。
所以我总结的架构是：特定约束下的决策结果。
而模块是按照功能逻辑拆分的不可单独运作的单元。
还有那个MVC的图，为什么View被两个箭头指着，View不应该指向Controller吗？求解
先是要明确在什么粒度（层面）讨论的，比如是要讨论一个公司的业务架构，还是要讨论一个订单系统。
明确好粒度后，架构讨论的就是系统相关主体（某一粒度/层面）之间的交互与依赖关系了。
老师的声音很好听。
架构侧重拓扑和信息流转
我考过了软考中系统架构师的考试，记得里面有逻辑视图 实现视图 部署视图 用例视图，但感觉缺乏学以致用。
谈一下我对架构和框架的理解：框架是为减少相似业务的重复开发，在遵守某一规范下，形成的具有基础功能的软件系统。基于此框架开发，只要遵守其规范，应该是更快，更稳定。框架实现时，本身需要事先架构好，里面有架构的约束，架构的东西。
我之前以为架构就是组件功能的清晰划分，之前的想法很简单
架构是如何把需要做的业务系统/中间件 等按一定的方式做出来,用合适的技术去做合适的事儿,满足一定的场景;
框架是一个模板,或者类似半成品,有助于我们更好的去实现系统/中间件等.但是框架其实不是必须品.比如mvc,如果我们不用spring mvc等开源框架,其实也可以用servlet.
比如从业务逻辑角度模块登录、朋友圈等，
从物理部署角度组件nginx-web服务器mysql等、
从开发规范角度MVC。
附加：
系统是由一群有关联的个体组成。
系统内的个体需要按照指定的规则运行，规定了个体分工和协作的方式。
系统能力与个能能力之和有本质区别。
框架是组件规范MVC，
是提供基础功能的产品 spring security、spring jpa。
之前在我的印象中，我对架构的认识一个容器，能承载业务的容器，选择架构时需要根据所需业务来进行选择。
个人理解业务架构更多聚焦业务功能；产品架构和应用架构比较像，对业务进行一定程度抽象，综合考虑可拓展、可复用等特性，划分系统边界、系统角色，梳理系统间关系、系统内关系；信息架构定义不太清晰；技术架构中关于系统和子系统划分、模块划分、概念定义是否需要与产品架构统一，这个比较困惑，各有利弊。
框架是规范的具体实现，不是唯一的。
子系统是对系统在业务角度上的分割，子系统具备系统也是一个系统。
模块和子系统的概念相似，个人认为更多的是语义上的区别，子系统的概念更大一些。对子系统的划分可以称之为模块。
组件和框架，都是从实现角度上看的不同程度的复用。框架是实现基本的功能(多少控制)，供人往里填业务。而组件可以直接拿来就用。
架构，对系统，子系统，模块划分。框架，组件的选择的描述
架构是系统的基础结构。各层面上，结构体现为顶级单元以及他们之间的关联关系。
• 逻辑层面上，最终用户看到的功能集，功能由哪些子系统、顶级模块等逻辑单元，以及关联关系组成。
• 开发层面上，程序员怎么实现，所看到的子系统、包图、框架、类库以及总体代码结构。
• 物理层面上，系统运维工程师要部署哪些组件、组件的拓扑结构，可部署单元有：Nginx/web server/db/cache/mq等等各种用途的单元。
• 运行层面上，是系统处理及通讯的动态过程，运行性能、并发、分布式情况。
多谢运华做的这个分享，提个意见：能否再把一些原理说的更易懂，再次提炼，可能对我们理解的知识又是一个升级！
架构，architecture 如何让组成部分按既定规则，要求工作，可以借助框架，当没有类似框架时，需要自力更生
架构：是命题作文；
架构是有效合理的整合子系统，如用户子系统，支付子系统等等，由于微信比较复杂是一个多机系统，一般的办公系统是单机系统用它的开发框架表示也可以；
子系统是各个模块和组件为了实现子系统的业务功能如登录功能就有登录组件，oauth2授权组件等
组件和模块都是子系统的功能单元
框架则是规范，标准。
模块：业务的逻辑拆分。模块也可以当组件来开发。
组件：物理的拆分，可插拔。
系统和子系统感觉有时候没有明确的界限，有可能一个系统也是另一个系统的子系统，但对于系统内内部各部分而言又算是一个系统，不知道是不是这样，还请多多指教
我猜华哥这里的“架构”应该是“框架”😝
老师提到了规范，我想规范就是那保证系统不畸形的良药，但是如何设计规范，希望能听到业务、技术等方面的建议。尤其是作为技术从业者，如何和产品、运营等角色协作好，既能满足需求，又能有所沉淀。
为什么是子系统而不是模块呢？两者的关系与区别？
1、逻辑视角上，都是逻辑单元，子系统是更高一级的逻辑单元，子系统是模块的集合，系统是子系统、模块的集合。
子系统内部各模块间比子系统外的模块有更高的内聚，这是划分子系统主要因素。
2、物理视图上，子系统是可部署组件，模块不是可部署组件。子系统、系统可以只包含一个模块。
我的理解如上，如有误感谢指正一下，谢谢！
我理解的框架就是就是一种标准或者规范，一种技术手段，相对更偏向业务系统层面。
架构是一种结构，定义系统整体结构，我理解就像要建一所学校，架构就是设计图纸。
从大的方向上感觉架构是包含框架的，但是从小了说框架里好像又包含架构…
现在理解的架构:软件系统的顶层结构，以囊括整个软件系统的角度看，架构需要描述系统的组成，包括所有的子系统以及组成系统的“个体”，还要定义“个体”之间的交互规则。
之前的理解：就是技术栈，忽略了整体结构这个概念。
现在的理解：架构其实是从整体来看一个系统，他的各个业务功能组成部分是定制的业务模块还是成熟的组件。
我感觉差异是：感觉之前理解的不具有系统性，属于‘野路子’，只是开发生涯中的积累，现在把概念系统性的补了一下。有种顺畅的感觉！
架构是为了解决某个或某种问题而编写的“图表”方案，该方案按照不同纬度(如：业务纬度，开发纬度，物理纬度)的需求展开设计，并保证由该方案完成的系统可稳定运行并可容易扩展。