Nestjs框架: Nestjs 复杂企业应用场景架构设计分析

概述

• 我们要理解架构设计是什么、怎样做架构设计及其套路，还有为什么要学做架构设计
• 架构设计是一个过程，系统会被划分为很多小部分，我们称这些小部分为组件或模块
• 确定它们如何交互协作以完成业务目标，这就是软件的架构设计
• 架构并非软件，而是关于软件设计的策略，是对整体结构和组件的抽象描述
• 最终目的是解决软件系统复杂度可能带来的问题

举例

• 以写前端页面为例，最初可能一个 HTML 文件、一个 JS 文件和一个 CSS 样式文件就能完成页面，甚至有时只用一个文件
• 但随着页面增多、交互和需求变复杂，就需要 CLI 工具和框架来实现复杂需求，这些工具和框架解决了复杂度问题
• 同样，系统架构设计也是为了解决复杂度问题。比如单体应用最初可能用一台服务器从数据库读数据，但业务量增加后，一台服务器的物理硬件资源有限，如网络带宽、系统 IO、磁盘转速、数据读取速度、CPU 处理性能等
• 这时就需要用多台设备处理，如分开数据库，用单独的外部服务器、数据库服务器等，这就是架构设计的目的，即使用最小成本满足构建和维护系统的需求，解决未来可能遇到的问题

架构设计可能会遇到五大坑点

1 ） 需求未明确

• 技术人员常关注功能性需求，而非功能性需求可能被忽视。

2 ) 过度设计

• 设计架构图或方案时，会有很多细致内容，还可能造成资源浪费
• 架构设计应使用最小资源满足业务功能需求，可以有冗余设计，但不能过度

3 ) 追求大公司的方案

• 很多团队前期参考竞品时会直接照搬大公司的架构方案
• 但大公司的方案是适合其自身的，自己的产品和业务与大公司不同
• 不能完全照搬，可参考后做减法

4 ) 技术方案走极端

• 采用新技术后期维护成本高；有些团队追求新技术，却忽略现有技术优势、适用性、团队协作和业务理解能力等因素。
• 选择新技术时应考虑近期和远期优势、对业务的影响、战略产生的技术债务等，还要考虑前期成本投入和效益产出

5 ) 实践拖延

• 理论源于实践，架构设计的理论需要在实践中验证和调整，形成适合自己业务和团队的架构。落地架构要制定短中长期规划，梳理上下游业务计划，确定团队配置和招聘计划，因为大型系统项目可能需要相应技术人员支撑
• 架构设计需要有深入专业的知识，了解架构设计的套路、相关技术和工具，知道在什么场景使用，以及它们能解决什么问题，这些都要通过实践获取

架构设计有以下分类

1 ) 系统架构

• 包含系统总体结构、软件组件、硬件组件、网络、数据存储等，是最完善的

2 ) 软件架构

• 也叫应用架构，指设计软件的高层结构
• 包括主要组件及组件间的交互设计，如使用的设计模式、MVC、微服务架构等

3 ) 数据架构

• 与数据的存储、处理、访问和保护相关，涉及数据库设计、架构流程图和数据管理策略

4 ) 网络架构

• 设计系统中的通信架构，确定网络设备、协议、路由策略等

5 ) 安全架构：

保护系统和数据，涉及安全策略、加密、身份验证、授权等技术

架构设计的常见模式

1 ) 层次架构模式

• 常见的是三层架构，包括表示层（用户界面）、业务逻辑层（具体功能实现）、数据访问层（与基础设施及网络存储组合）
• 还有 n 层架构，是在三层架构基础上的拓展，复杂企业级应用可能包含用户界面、应用业务层、数据访问层、数据库等

2 ) 数据流行的架构模式

• 关注数据的流动和变化，数据从用户侧开始，经过网关、业务系统、用户服务、内容服务、支付服务等，最终经过数据库返回到前端用户，每个阶段都有关键的中间件或过滤器

3 ) 模块型的架构模式

• 强调将系统分解为可独立开发的模式，如微服务架构，每个程序是一组小的独立服务，服务间通过轻量级通信机制（如消息遍历）交互，服务可扩展

4 ) 事件驱动型的架构模式

• 常见的是发布订阅模式和观察者模式，观察者模式是发布订阅模式的变体
• 一个对象维护一系列依赖于它的对象，状态变化时通知所有观察者，如 Vue 中的响应式系统

5 ) 分布式系统的架构模式

• 包括主从架构模式（主服务器执行读写操作，从服务器执行读操作
• 主服务器挂掉后从服务器可写）、分布式数据模式（数据分布在多个节点，每个节点负责一部分数据）、服务定位模式

6 ) 用户界面的统计模式

• 如 MVC、MVVM 等，是前端熟悉的设计模式

架构设计的工具分类如下

1 ) UML 工具

• 代表统一建模语言，涉及很多图，有代表性的是 Visio 及一些在线工具

2 ) 建模工具

• 与 UML 工具有交集，如 ProcessOn、Draw.io 等，里面有 UML 设计模板

3 ) 系统架构的设计工具

• 如一些在线工具，国内阿里云架构设计软件可将产品图标具象化拖拽到系统中设计架构图

4 ) 数据库设计相关的工具

• 如 Navicat Designer

5 ) 需求管理工具

• 用于需求和缺陷控制、团队提效，如 GitHub、Jira 等

6 ) 原型设计相关的工具

• 如 Axure、墨刀、蓝湖等，广泛应用且支持团队协作

7 ) 举例

• 如何绘制系统架构图，通常使用 ProcessOn 和 Draw.io 两个工具
• 它们模板丰富，可选择对应图表绘制
• 以 ProcessOn 为例，选择 UML 图后，左侧有很多图形，可点选更多图形加载对应模型来表达想法，通过连线和箭头表示模块和组件间的关联关系
• Draw.io 现在叫 diagrams.net，可在左侧选择素材图标，若安装客户端版本，在本地加载模型绘制架构图会更快
• 绘制的架构图可采用层次型架构模式，从上到下依次为用户及各端和对应的业务、使用的技术方案和组件库方案、接口服务和数据存储
• 小项目部分也可使用层次架构模式，从具体业务到业务组件、业务和技术方案，再到与服务端的交互及服务端模块

架构设计验证通常从以下角度进行

1 ）架构评审

• 有专门评审委员会和评审办法，常见方法有模拟和原型，可查看架构是否有效，能否满足性能、可用性和其他功能性需求
• 还可对架构设计的完整性和一致性做检查，如检查组件和服务职责是否明确、接口和依赖关系是否定义清晰、需求是否都被考虑和解决
• 常用工件有 ADR（架构决策记录，侧重于架构设计决策记录，包括动机、选项、结果等）和 RAID（识别和管理架构设计和实施过程中的风险、假设、问题和依赖关系）

2 ）测试手段

• 通过单元测试、集成测试等断定功能性和非功能性指标是否达到需求
• 架构设计的整个流程和环节都与业务需求相关，技术需求也与业务需求关联
• 最终目的是通过抽象的组件和图表体现各模块和组件间的关联关系，为技术落地提供参考