没有合适的资源?快使用搜索试试~ 我知道了~
一文详谈架构设计.docx
0 下载量 185 浏览量
2023-05-05
03:03:25
上传
评论
收藏 2.29MB DOCX 举报
温馨提示
试读
21页
一文详谈架构设计.docx
资源推荐
资源详情
资源评论
一文详谈架构设计
在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的
理解。在不同的书籍上, 不同的作者, 对于架构的定义也不统一, 角度
不同, 定义不同。此君说的架构和彼君理解的架构未必是一回事。因此
我们在讨论架构之前,我们先讨论架构的概念定义, 因为概念是人认识
这个世界的基础和用来沟通的手段,如果对架构概念理解不一样,那
沟通起来自然不顺畅,本文根据相关资料进行总结。
一、架构是什么
Linux 有架构,MySQL 有架构,JVM 也有架构,使用 Java 开发、MySQL 存储、
跑在 Linux 上的业务系统也有架构,应该关注哪一个?想要清楚以上问题需要
梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构。
一)、系统与子系统
系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元
件不能独立完成的工作能力的群体,关键词:
关联:系统是由一群有关联的个体组成的,没有关联的个体堆在一起不能
成为一个系统。例如,把一个发动机和一台 PC 放在一起不能称之为一个
系统,把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
规则:系统内的个体需要按照指定的规则运作,而不是单个个个体各自为
政。规则规定了系统内个体分工和协作的方式。例如,汽车发动机负责产
生动力,然后通过变速器和传动轴, 将动力输出到车轮上,从而驱动汽车前
进。
能力:系统能力与个体能力有本质的差别,系统能力不是是个体能力之和,
而是产生了新的能力。例如,汽车能够载重前进,而发动机、变速器、传
动轴、车轮本身都不具备这样的能力。
子系统:也是由一群关联的个体组成的系统,多半是在更大的系统中的一
部分。
二)、模块与组件
都是系统的组成部分,从不同角度拆分系统而已。模块是逻辑单元,组件
是物理单元。
模块就是从逻辑上将系统分解, 即分而治之, 将复杂问题简单化。模块
的粒度可大可小, 可以是系统,几个子系统、某个服务,函数, 类,方
法、 功能块等等。划分模块的主要目的是职责分离。
组件可以包括应用服务、数据库、网络、物理机、还可以包括 MQ、容器、
Nginx 等技术组件。划分组件的主要目的的是单元复用。"组件"的英文单词
Component,对应中文的"零件"一词,"零件"更容易理解一些。"零件"是一
个物理的概念, 并且具备"独立且可替换"的特点。现在越来越多的 UI 设计
使用组件化化和模块化。
三)、框架与架构
框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规
范, 也指为了实现某个软件组件规范时,提供规范所要求之基础功能的软件
产品。
框架是组件实现的规范,例如:MVC、MVP、MVVM 等,是提供基础功能
的产品,例如开源框架:Ruby on Rails、Spring、Laravel、Django 等,这
是 可 以 拿 来 直 接 使 用 或 者 在 此 基 础 上 二 次 开 发 。 再 例 如 ,SpringMVC 是
MVC 的开发框架,除了满足 MVC 的规范,Spring 提供了很多基础功能来
帮助我们实现功能,包括注解(@Controller 等)、Spring Security、SpringJPA
等很多基础功能。
框架是规范,架构是结构:框架和架构的区别还是比较明显的,框架关注
的是"规范", 架构关注的是"结构":
� 框 架 的 英 文 是 Framework , 例 如 , SpringMVC 是 "Web MVC
Framework";
� 架构的英文是 Architecture,例如,Linux 操作系统的架构。
在 TOGAF9 是这么定义:一个系统基本的构件(子系统, 模块, 组件),体现
在它的各个构件、构件间的相互关系、构件与环境间的关系,以及对系统
设计和演进进行治理的原则中。两种含义:
� 一个系统的形式化描述,或指导系统实现的构件级的详细计划;
� 一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时
间演进的过程进行治理的一些原则和指导策略。
架构从字面意思上,是源于古代的建筑术语。把架构拆分成两个字“架”和
“构”。“架”就是“加”和“木”的结合,把木头加起来、连接起来就是架。“构”就
是结构的意思。所以,“架构”就是把“木“按照一定的结构连接起来。
对应到软件架构,“木”代表构件(要素),“结构”代表架构的产物:
木就是系统中的要素,我们将他们称之为架构构件(要素)。架构要素可以是
子系统、模块、应用服务、组件。
结构,是架构的产物。不同的软件系统会有不同的结构,这些结构是为解
决不同场景而设计的。连接,通过定义架构元素之间的接口和交互关系、
集成机制,实现架构元素之间的连接。连接可以是分布式调用、进程间调
用、组件之间的交互关系等。
总结一下架构的组成 = 要素 + 结构 + 连接,将系统要素按照特定结构进
行连接交互。我在这重新定义架构(见仁见智,自己独立思考):软件架构指
软件系统顶层结构设计。架构是经过系统性地思考, 权衡利弊之后在现有资
源约 束下 的最 合理决策, 最 终明 确的 系统 骨架 : 包括子系统, 模块, 组件 .
以及他们之间协作关系, 约束规范, 指导原则. 并由它来指导系统各方面的
设计和指导团队中的每个人思想层面上的一致。
涉及四方面:
1、系统性思考的合理决策:比如技术选型、解决实施方案(包括执行目标
计划)、成本评估、性价比评估等等。
2、结构:明确的系统骨架(结构):明确系统有哪些构件组成。
3、连接:系统协作关系:各个组成部分如何协作来实现业务请求。
4、规范:约束规范和指导原则:保证系统有序,高效、稳定运行,包括规
范、原则、流程等内容。
二、架构设计目的
如果没有架构设计,说明你的系统不够复杂。随着业务的增长,系统由单
体应用渐进演化为分布式和微服务化。系统整体的复杂性越来越高,技术
团队可能从一个团队变成多个专业化团队。假如没有架构设计,系统定会
是一个无序失控的状态,带来的问题:
1、应用服务的边界不是很清晰:到底该怎么拆分没有一个明确的原则,研
发人员为了所谓微服务化而拆分,而不是从当前业务考虑。导致系统无序
的状态,开发效率低。
我们系统出现过类似的情况:一个简单项目拆分成 8 个子服务,问他为什
么这么拆分,说微服务化是为了应对以后扩展方便。结果这个项目从 2017
年到现在都没有再修改过,接手人宁愿新开发一个项目也不愿重构。
2、应用服务层次不清晰,系统耦合严重:导致服务依赖出现网状依赖结构,
牵一发动全身,后续修改和扩展困难。
3、系统应用服务跟踪问题:由于微服务化后,系统逻辑复杂,服务出现问
题 后 , 你 很 难 快 速 的 定 位 问 题 和 修 复 。 这 是 我 们 踩 过 不 少 坑 , 我 们 使 用
dubbo 服务化,系统一旦出现问题,一推人手忙脚乱。
4、系统服务监控问题:由于研发人员基本没有服务监控意识,都是出现问
题后再想办法如何添加服务监控接口。
5、技术体系失控问题:不同的开发团队使用不同的技术栈或者组件,造成
公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术,拿应用项
目来试验新技术。
架构设计的目的是为了解决系统复杂性带来的问题,其本质就是对系统进
行有序化地重构以致符合当前业务的发展,并可以快速扩展。从上面架构
的定义,也知道架构设计的作用涉及四方面:
1、系统性思考的合理决策。
2、明确的系统骨架。
3、系统协作关系。
4、约束规范和指导原则。
架构的本质是管理和解决系统的复杂性,提高效率。管理复杂性:对系统
进行有序化重构,不断减少系统的“熵”,使系统不断进化,改善软件质量为
目的的内在结构性变化;提高效率:对系统进行有序化重构,以符合当前
业务的发展,并可以快速扩展。
无论是何种变化,架构师通过理解业务,全局把控,权衡业务需求和技术
实现,选择合适技术,解决关键问题、指导研发落地实施,促进业务发展,
提高效率。那什么样的系统要考虑做架构设计? 技术不会平白无故的出和
自驱动发展起来,而架构的发展和需求是基于业务的驱动:
� 需求相对复杂
� 非功能性需求在整个系统占据重要位置
� 系统生命周期长,有扩展性需求
� 系统基于组件或者集成的需要
� 业务流程再造的需要
�
剩余20页未读,继续阅读
资源评论
jane9872
- 粉丝: 93
- 资源: 7752
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功