架构设计知识体系总结

组件：类似应⽤服务，独⽴模块、数据库、nginx等等

连接件：分布式调⽤、进程间调⽤、调⽤使⽤http协议还是tcp协议、组件之间的交互关系

约束规范： 定规则做限制：例如设计原则、编码规范等等

架构是系统的⾻架，⽀撑和链接各个部分，包括组件、连接件、约束规范，以及指导这些内容设计与演化的原理

架构定义

类似建筑设计规划，城市总体规划等，其实就是架构，只是应⽤的场景不同。

对系统进⾏有序化地重构以致符合当前业务的发展，并可以快速扩展

架构本质

1. 需求相对复杂

2. ⾮功能性需求在整个系统占据重要位置

4.系统基于组件或者集成的需要

5.业务流程再造的需要

什么样的系统需要做架构设计？

什么是架构和架构本质

包括业务规划，业务模块、业务流程，对整个系统的业务进⾏拆分，对领域模型进⾏设计，把现实的业务转化成抽象对象

业务架构（俯视架构）

1.职责划分: 明确应⽤（各个逻辑模块或者⼦系统）边界1）逻辑分层2）⼦系统、模块定义3）关键类

2.职责之间的协作：1）接⼝协议：应⽤对外输出的接⼝2）协作关系：应⽤之间的调⽤关系

关键两点

⼀种是⽔平分（横向）：按照功能处理顺序划分应⽤，⽐如把系统分为web前端/中间服务/后台任务，这是⾯向业务深度的划分

另⼀种是垂直分（纵向）：按照不同的业务类型划分应⽤，⽐如进销存系统可以划分为三个独⽴的应⽤，这是⾯向业务⼴度的划分

应用分层两种方式

应⽤作为独⽴可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各⽅⾯. 应⽤架构定义系统有哪些应⽤、以及应⽤之间如何分⼯和合作

应用架构（剖⾯架构，也叫逻辑架构图）

⼀、代码单元:1、配置设计2、框架、类库

⼆、代码单元组织：1、编码规范，编码的惯例2、项⽬模块划分3、顶层⽂件结构设计，⽐如mvc设计4、依赖关系

主要定义

⼦系统代码架构主要为开发⼈员提供切实可⾏的指导，如果代码架构设计不⾜，就会造成影响全局的架构设计

代码架构（开发架构）

技术架构主要考虑系统的⾮功能性特征，对系统的⾼可⽤、⾼性能、扩展、安全、伸缩性、简洁等做系统级的把握

确定组成应⽤系统的实际运⾏组件（lvs，nginx，tomcat，php-fpm等）这些运⾏组件之间的关系，以及部署到硬件的策略

技术架构（系统架构）

包括架构部署了⼏个节点，节点之间的关系，服务器的⾼可⽤，⽹路接⼝和协议等，决定了应⽤如何运⾏，运⾏的性能，可维护性，可扩展性，是所有架构的基础

部署架构（物理架构图）

架构分类（五类）

⾼可⽤：要尽可能的提⾼软件的可⽤性，我想每个操作⼈都不愿意看到⾃⼰的⼯作⽆法正常进⾏，⿊盒⽩盒测试、单元测试、⾃动化测试、故障注⼊测试、提⾼测试覆盖率等⽅式来⼀步⼀步推进

稳定性

⽂档化：不管是整体还是部分的整个⽣命周期内都必须做好⽂档化，变动的来源包括但不限于BUG，需求

可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地⽅抽象。⽅便功能更改、新增和运⽤技术的迭代，并且⽀持在适时对架构做出重构

 ⾼复⽤：为了避免重复劳动，为了降低成本，我们希望能够重⽤之前的代码、之前的设计。这点对于架构环境的依赖是最⼤的

高效

组织的运作过程中产⽣的数据都是具有商业价值的，保证数据的安全也是刻不容缓的⼀部分。加密、https等为普遍⼿段

安全

衡量架构的合理性

误区1：架构专门由架构师来做，业务开发⼈员⽆需关注：架构的再好，最终还是需要代码来落地，并且组织越⼤这个落地的难度越⼤。不单单是系统架构，每个解决⽅案每个项⽬也由⾃⼰的架构，如分层、设计模式等。如果每⼀块砖⽡不够坚固，那么整个系统还是会由崩塌的风险。所谓“千⾥之堤，溃于蚁⽳”。

误区2：架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深⼊到第⼀线怎么知道“地”在哪？怎么才能落的稳稳当当。

误区3：不做出完美的架构设计不开⼯：世上没有最好架构，只有最合适的架构。我们需要的不是⼀下⼦造出⼀辆汽车，最小MVP法则：从单轮车 -->⾃⾏车 --> 摩托车，最后再到汽车

常见架构误区

1. 《⼤型⽹站技术架构：核⼼原理与案例分析》

2. 《亿级流量⽹站架构核⼼技术》

3. 《架构即未来》

4. 《分布式服务架构：原理、设计与实战》

5. 《聊聊架构》

6. 《软件架构师的12项修炼》

架构书籍推荐

架构设计知识体系

书籍推荐：