jinhy学架构<1>

开篇问题：（一定要带着目的去学习）

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

背景

最近订阅了一个专栏，用来讲架构的，我挺有兴趣的，因为感觉自己没有系统的梳理过这方面的知识，能够听听阿里P9的员工谈谈是应该会有所收益。

他会讲这么一系列，我也会跟着一起总结一系列吧，假如有人感兴趣的话可以看看，有问题大家可以讨论讨论，那么也没必要订阅他的文章了哈哈。

需要强调一点的是，如果我们是冠读书以学习的话，一定要有目的，比如我想跟完这个系列后对架构设计能有一套自己初步的模式。这样的话我认为能充分不浪费我花费的时间。不过假如说，我看这个不是为了学习啥的，就是想开阔下视野稍微了解一下，那希望大家读的轻松，我也尽量避免晦涩的语言。

基础概念

我们了解学习某一事物的时候我们往往都是先从某些专有名词开始的，比如说我们学英语，就包含说的什么音标、词汇、语法和句型等等。我们学架构的话，那架构中一些概念也是要懂得。它们是被业界公认的一些已经被抽象好了的东西（如果能理解为什么这么抽象就更好了），我们学会并理解了才能够跟别人交流嘛。

系统和子系统

维基百科是这么定义系统：

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

提炼一下里面关键的内容：

• 关联：组成系统的一群个体之间要有关联。
• 规则：系统内个体的运作依据规则，而非杂乱无章。规则规定分工和协作方式等。
• 能力：系统能力和个体能力有本质的差别。系统能力一般不是个体能力简单的加和（排除某种可能因量变而产生量变的情况，但是目前还没有遇到过这种场景），而是个体组合而生成的新能力。

我们再看一下子系统的定义：

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

从而看出，系统和子系统仅仅是观察角度的差异。

比如微信本身就是一个系统，然后包含聊天、登录、支付和朋友圈等子系统。朋友圈这个系统又包括动态、评论等等子系统。

模块和组件

其实工作中的大多数时候我们并没有特别的去区分这俩个概念，依旧先看维基百科是怎么介绍这两个概念的。

首先是模块：

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

然后是组件：

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

可能大家即使看完了维基上的定义还是很迷茫。也可能大家抓住了定义中的某些关键字，如与语言无关。

我们接下来看看李运华是怎么说的：

模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。

从逻辑的角度来拆分系统后，得到的单元就是模块，划分的主要目的是职责分离。

从物理的角度来拆分系统后，得到的单元就是组件，划分的主要目的是单元复用。

举例说明：假设我们要做一个学生信息管理系统。这个系统才能够逻辑的角度来拆分，可以分为“登录注册模块”、“个人信息模块”和“个人成绩模块”等；从物理的角度来拆分，可以拆为Nginx、应用服务器（李运华说的是Web服务器，我觉得说为应用服务器更好）、MySQL等。

框架和架构

按照惯例先上维基上的定义。

先介绍框架：

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

提炼一下关键部分：

• 框架是组件规范：例如，MVC就是一种最常见的开发规范，类似的还有MVP、MVVM、J2EE等框架。
• 框架提供基础功能的产品：例如，SpringMVC是MVC的开发框架，除了满足MVC的规范，Spring提供了很多基础功能来帮助我们事先功能，包括注解、Spring Security、Spring JPA等很多基础功能。

再说明一下架构：

软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。

从定义上看，我们会发现框架关注的是规范，架构关注的是结构。

然而架构中的“基础结构”概念并没有明确的说是从什么角度来分解。采用不同的角度或者维度，我们可以将系统划分为不同的结构。还是以之前的“学生管理系统”为例。

从业务逻辑的角度分解的话，其架构是：

业务逻辑架构图

从物理部署的角度分解的话，其架构是：

物理部署架构图

从开发规范的角度分解，其架构是：

开发规范架构图

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

重新定义架构

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

这个定义看似简单，担保函的信息很丰富，基本上把系统、子系统、模块、组件、架构等概念都串起来了。

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

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

最后，维基百科中定义架构用到了“基础机构”这个说法，这里改为“顶层结构”，可以更好地区分系统和子系统，避免将系统架构和子系统架构混淆在一起导致架构层次混乱。

ps.一千个人有一千个哈姆雷特，所以我并不觉得李运华这是重新定义了架构这个概念，可以说是以自己的方式重新诠释了一下这个概念，而且相对维基的定义更加的具化，我觉得挺好。

小结

这里就谈谈我的收获吧，首先概念肯定是相对以前能更清晰了。

还有就是有些东西可能你冥冥中已经知道了，但是说不出口，当有人替你说出来后便得到印证，就会很舒服。比如你之前设计的那些服务那些模块到底算是干了些什么？

这算是一个小地基吧。

精选评论

• 架构是顶层设计；框架是面向编程或配置的半成品；组件是从技术维度上的复用；模块是从业务维度上职责的划分；系统是相互协同可运行的实体。
• 搬砖的：“头，我们要造什么？”；（做什么系统？）
  工程师：“龙之梦商城”；（XXX系统，比如微博系统）
  搬砖的：“图纸画出来了嘛？”；（架构是怎么设计的？）
  工程师：“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”；（相当于微博系统中的各个子系统，比如评论子系统、动态子系统、消息子系统）
  搬砖的：“头，说人话”；
  工程师：“一楼有卖衣服、化妆品的，二楼有唱歌、看电影的，三楼有吃的”；（【模块】按照逻辑区分，比如存储数据模块、搜索模块、消息推送模块）
  搬砖的：“有没有很知名的店啊？”；
  工程师：“有的，一楼有香奈儿、优衣库...、二楼有好乐迪、万达影院....、三楼有海底捞、避风塘.....”；（【组件】按照物理区分，存储数据模块对应Mysql、搜索模块对应ElasticSearch、 消息推送模块对应Kafka）
  搬砖的：“对了，头，商城大门有啥需要叮嘱的施工规范不？或有啥简化施工工艺的新技术嘛？”；（有框架的可以用吗？）
  工程师猛吸了一口烟，把烟头扔在地上，用皮鞋左右撵了两下，缓缓从嘴里崩出四个字。 “老样子吧”。（Spring全家桶甩起来）

推销自己

欢迎大家访问我的博客~

更欢迎大家加入我的公总号~

寻星之路