架构设计知识体系总结
2023-12-18 08:57:43 0 举报AI智能生成
系统架构师知识体系重点内容总结
作者其他创作
大纲/内容
什么是架构和架构本质
架构定义
架构是系统的⾻架，⽀撑和链接各个部分，包括组件、连接件、
约束规范，以及指导这些内容设计与演化的原理
约束规范，以及指导这些内容设计与演化的原理
组件：类似应⽤服务，独⽴模块、数据库、nginx等等
连接件：分布式调⽤、进程间调⽤、调⽤使⽤http协议还是tcp协议、组件之间的交互关系
约束规范： 定规则做限制：例如设计原则、编码规范等等
架构本质
对系统进⾏有序化地重构以致符合当前业务的发展，并可以快速扩展
什么样的系统需要做架构设计？
1. 需求相对复杂
2. ⾮功能性需求在整个系统占据重要位置
3. 系统⽣命周期长,有扩展性需求
4.系统基于组件或者集成的需要
5.业务流程再造的需要
架构分类（五类）
业务架构（俯视架构）
包括业务规划，业务模块、业务流程，对整个系统的业务进⾏
拆分，对领域模型进⾏设计，把现实的业务转化成抽象对象
拆分，对领域模型进⾏设计，把现实的业务转化成抽象对象
应用架构（剖⾯架构，也叫逻辑架构图）
应⽤作为独⽴可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、
代码开发、部署和运维等各⽅⾯. 应⽤架构定义系统有哪些应⽤、以及应⽤之间如何分⼯和合作
代码开发、部署和运维等各⽅⾯. 应⽤架构定义系统有哪些应⽤、以及应⽤之间如何分⼯和合作
关键两点
1.职责划分: 明确应⽤（各个逻辑模块或者⼦系统）边界
1）逻辑分层
2）⼦系统、模块定义
3）关键类
1）逻辑分层
2）⼦系统、模块定义
3）关键类
2.职责之间的协作：
1）接⼝协议：应⽤对外输出的接⼝
2）协作关系：应⽤之间的调⽤关系
1）接⼝协议：应⽤对外输出的接⼝
2）协作关系：应⽤之间的调⽤关系
应用分层两种方式
⼀种是⽔平分（横向）：
按照功能处理顺序划分应⽤，⽐如把系统分
为web前端/中间服务/后台任务，这是⾯向业务深度的划分
按照功能处理顺序划分应⽤，⽐如把系统分
为web前端/中间服务/后台任务，这是⾯向业务深度的划分
另⼀种是垂直分（纵向）：
按照不同的业务类型划分应⽤，⽐如进销存系统可以划分
为三个独⽴的应⽤，这是⾯向业务⼴度的划分
按照不同的业务类型划分应⽤，⽐如进销存系统可以划分
为三个独⽴的应⽤，这是⾯向业务⼴度的划分
代码架构（开发架构）
⼦系统代码架构主要为开发⼈员提供切实可⾏的指导，
如果代码架构设计不⾜，就会造成影响全局的架构设计
如果代码架构设计不⾜，就会造成影响全局的架构设计
主要定义
⼀、代码单元:
1、配置设计
2、框架、类库
1、配置设计
2、框架、类库
⼆、代码单元组织：
1、编码规范，编码的惯例
2、项⽬模块划分
3、顶层⽂件结构设计，⽐如mvc设计
4、依赖关系
1、编码规范，编码的惯例
2、项⽬模块划分
3、顶层⽂件结构设计，⽐如mvc设计
4、依赖关系
技术架构（系统架构）
确定组成应⽤系统的实际运⾏组件（lvs，nginx，tomcat，php-fpm等）
这些运⾏组件之间的关系，以及部署到硬件的策略
这些运⾏组件之间的关系，以及部署到硬件的策略
技术架构主要考虑系统的⾮功能性特征，对系统的⾼可⽤、⾼性能、扩展、安全、伸缩性、简洁等做系统级的把握
部署架构（物理架构图）
包括架构部署了⼏个节点，节点之间的关系，服务器的⾼可⽤，⽹路接⼝和协议等，决定了应⽤如何运⾏，运⾏的性能，可维护
性，可扩展性，是所有架构的基础
性，可扩展性，是所有架构的基础
衡量架构的合理性
稳定性
⾼可⽤：要尽可能的提⾼软件的可⽤性，我想每个操作⼈都不愿意看到⾃⼰的⼯作⽆法正常进⾏，
⿊盒⽩盒测试、单元测试、⾃动化测试、故障注⼊测试、提⾼测试覆盖率等⽅式来⼀步⼀步推进
⿊盒⽩盒测试、单元测试、⾃动化测试、故障注⼊测试、提⾼测试覆盖率等⽅式来⼀步⼀步推进
高效
⽂档化：不管是整体还是部分的整个⽣命周期内都必须做好⽂档化，变动的来源包括但不限于BUG，需求
可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地⽅抽象。⽅便功能更改、新增和运⽤技术的迭代，并且⽀持在适时对架构
做出重构
做出重构
⾼复⽤：为了避免重复劳动，为了降低成本，我们希望能够重⽤之前的代码、之前的设计。这点对于架构环境的依赖是最⼤的
安全
组织的运作过程中产⽣的数据都是具有商业价值的，保证数据的安全也是刻不容缓的⼀部分。加密、https等为普遍⼿段
常见架构误区
误区1：架构专门由架构师来做，业务开发⼈员⽆需关注：架构的再好，最终还是需要代码来落地，并且组织越⼤这个落地的难度越⼤。
不单单是系统架构，每个解决⽅案每个项⽬也由⾃⼰的架构，如分层、设计模式等。如果每⼀块砖⽡不够坚固，那么整个系统还是会由崩塌
的风险。所谓“千⾥之堤，溃于蚁⽳”。
不单单是系统架构，每个解决⽅案每个项⽬也由⾃⼰的架构，如分层、设计模式等。如果每⼀块砖⽡不够坚固，那么整个系统还是会由崩塌
的风险。所谓“千⾥之堤，溃于蚁⽳”。
误区2：架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深⼊到第⼀线怎么
知道“地”在哪？怎么才能落的稳稳当当。
知道“地”在哪？怎么才能落的稳稳当当。
误区3：不做出完美的架构设计不开⼯：世上没有最好架构，只有最合适的架构。我们需要的不是⼀下⼦造出⼀辆汽车，
最小MVP法则：从单轮车 -->⾃⾏车 --> 摩托车，最后再到汽车
最小MVP法则：从单轮车 -->⾃⾏车 --> 摩托车，最后再到汽车
架构书籍推荐
1. 《⼤型⽹站技术架构：核⼼原理与案例分析》
2. 《亿级流量⽹站架构核⼼技术》
3. 《架构即未来》
4. 《分布式服务架构：原理、设计与实战》
5. 《聊聊架构》
6. 《软件架构师的12项修炼》
0 条评论
下一页
