五、架构设计技巧——架构设计步骤与应用

一、架构设计步骤概览

1.系统设计的目的

很多人在做系统设计时，是搞不清为什么要做一个新系统的设计，或者为什么要做一个系统的重构/演进的设计，如果搞不清楚这个目的，后面的系统设计上是很容易形成偏差的，导致本来是为了解决一个问题，要去做新的系统或重构/升级旧的系统，但最后完全脱离了初心。一个大架构师是需要给很多人讲解系统设计的，只有理解并讲清了系统设计的目的，团队才能更好的去实现。

当需要做系统设计时，就意味着需要建设一套新系统，或者对原有的系统进行比较大的架构的改造升级，这一定是基于什么原因才要去做的。之所以要分析好系统建设的目的，一方面是为了避免出发点有问题，系统建设的目的应该是充分反映出解决业务层面临的挑战，或者系统用户层面面临的问题的，而不是出于个人诉求，另一方面是为了确保在后续的系统设计中能保证目的的达成。

做系统设计前，一定要先对于系统建设的目的分析清楚，确保系统建设有价值和有意义，同时确保后面的整个系统设计是能让目的达成的。

2.系统设计的目标

围绕目的，能不能形成一些可衡量的目标，从而确保最终系统实现和最初的目的不要出现太大的偏差，相信很多人都经历过最终的系统实现和系统设计偏差极大的现象，主要的原因基本都是没有制定衡量系统设计的目标。

在分析清楚了系统建设的目的后，到了目标这个环节，最重要的是要把前面的目的的描述，转换为可衡量的目标的描述，之所以要形成可衡量的目标，最重要的原因是为了确保最后实现的系统是达成了系统建设的目的的，相信很多人都碰到过设计出来的系统和最后落地的系统很不一致的现象，通常这都是缺乏了可衡量的目标造成的。

做容器化，建设这套系统的目的是为了应对预计会越来越大的机器成本，目标相应的制定为支撑相同的业务量，机器下降一半。做异地多活，建设这套系统的目的是为了能够让业务具备更强的抵御灾害的能力，尽管后面发现因为有了异地多活，有了更多的好处，但那些确实在系统设计之初是完全没放在建设目的里的，后面能做到纯属巧合，例如因为有了异地多活使得后面的弹性借助云资源成为了现实，因为有了异地多活，基础设施技术的演进可以更加快速，在设计之初根据目的相应制定的目标为业务能够部署在中国多个地点（地点间距离>1千公里），多个地点部署的业务都处于承接流量的状态，且流量从A点切换到B点能在30s内完成。

有了清晰的可衡量的系统建设的目标，意味着：

• 确保了系统设计过程中可以非常针对性的围绕目标来做，避免偏题；
• 更重要也是最容易遗漏的一点，是可以做一个用来跟踪系统建设效果的系统。只有有了跟踪系统建设目标是否达标的系统，才能真正确保系统建设完毕后和初心保持了一致，否则很多系统建设的时候是一个目的，最后做完了是另外的状况，所以这个跟踪效果的体系是一定要在系统建设的时候同步就做好的。

3.围绕目标的核心设计

这步最重要的就是通过设计如何去实现上面的目标，这个环节中技术的专业、视野、全面的考虑、权衡取舍的主观原则、解题的思路，这是形成最后的核心设计的关键。在核心设计的这个阶段中，会产生一些新的衡量设计最后实现情况的目标，这些也都要增加到系统设计中，确保最后的实现和设计的偏差度是可视的。

如果要达成系统设计的可衡量的目标，到底面临了一些什么核心问题，只有明白了面临什么核心问题，才能更加明确的进行系统设计来解决这些问题。从可衡量的目标映射到技术层面要去解决的核心问题，是很需要技术功底的，对于工程类型的项目、产品而言，工程经验在这个时候也会特别重要。

4.围绕核心设计形成的设计原则

有了核心设计后，可以真正的形成一些设计原则，确保后面的子系统/模块的详细设计中能够遵循，并在详细设计中体现出来，这样才能让整个大的系统设计的一致性。

5.各子系统/模块的详细设计

二、技术方案设计注意事项

1.什么是一个好的技术方案

事前

• 明确的目标：整个技术方案要达成什么目的
• 低沟通成本：产品测试能从技术方案上获取足够的输入，不需要反复找你确认
• 技术选型思考：为什么要这么做？和业内方案相比有什么好处和坏处，如何权衡的

事中

• 少调整：尽可能少的技术方案需要调整， 否则无法完成开发任务

事后

• 少补丁：尽可能少的 bug 或者遗漏

• 可扩展 & 可复用：相对简单的改动就能支持新增需求，类似场景可复用不需要重复开发

  一篇好的技术方案可以贯穿整个研发的生命周期，并且能起到很好的指导意义，就如同写小说之前作者必须出一个大纲的逻辑是一致的。

2.如何写好一篇好的技术方案

**(1)**清晰的目标

一份技术文档需要有一个清晰的目标（业务需求建议自己总结而不是 Copy from PRD，技术自发的那肯定得自己总结），那目标怎么来的呢？是从需求里转化过来的。那么，如何将对应的需求转化为一个清晰的目标？我认为最重要的是要尽量定义一个可衡量的标准。需求的种类一般来说就两种，分别是：

• 产品类需求——业务方 or 产品方发起提给技术，包括但不限于以下几种：

• • 页面交互：能提升多少的运营操作效率，多少 PV、UV 这种可量化的数字？
  • 业务 SOP 调整：带来的业务价值是什么？是能降多少本还是提升多少时效？
  • 数据订正：订正能解决什么问题？防止多少钱未结算？又或者是防止多少客诉？

• 技术类需求——技术自发提出，包括但不限于以下几种：

• • 性能优化：优化多少？20%、30% 还是 50%？
  • 数据隔离：隔离的范围是什么，涉及多少张表，多少数据？可以减少当前的什么问题？减少多少？
  • 各种小工具：没有小工具之前是什么样？有之后是什么样？可以带来什么好处？
  • 研发效能提升：提升多少？有没有可以量化的指标？而不是为了做而做。

  在众多的需求当中还有一些是我们要去辨别的伪需求——不是用户真正想要的需求，如用户想要将一个飞机改造成火箭，但是产品可能提过来的仅仅是把飞机的两个翅膀砍掉，那么砍掉翅膀就能变成火箭了吗？明显不能，所以这种需求一定要注意鉴别。

**
**

(2)大纲图

• 图不用很细（比如加工比较复杂我们可以简单写**加工），但是要能看到全貌，具体的每个模块如果需要展开的，那么在对应的详细设计中体现即可，在这里我们关注的是整体；
• 接口如有归属不同的应用要标明；
• 数据存储介质不同要标明；
• 数据流转的箭头要清晰明确；
• 数据加工计算的输入和输出要体现，同时要体现加工的运行环境（比如到底是 odps 计算还是内存计算，内存计算的话是在那个应用）。

(3)模型设计

讲到数据模型设计，E-R 图是必不可少的，E-R 图应该包含以下信息：

• **每个领域对象，如果要持久化，都有表来存储。**我们设计完 ER 图的时候，应该根据这条原则做一番检查，避免漏掉一些表。在大型项目中，漏掉表是很常见的事情，应尽量避免。
• **领域对象之间的关系，如果要持久化，都要在表结构中体现。**这种体现，可能是 code 字段，可能是外键，可能是中间表。我们设计完 ER 图的时候，也应该根据这条原则做一番检查，避免漏掉一些关系。在大型项目中，漏掉关系更是司空见惯，应尽量避免。
• **清晰定义的表名。设计 ER 图的时候，就要设计出清晰定义的表名。**清晰定义的表名，可以帮助大家理解 ER 图，可以帮助大家映射回领域对象及其关系。在后续的设计和实施中，将沿用这个表名。
• **清晰定义的字段名、字段类型、字段长度和枚举值。**很多同学容易忽略这点，他们往往清晰定义了表名，却没有重视表的字段。认真去做的时候，会发现，这里面有很多工作。例如，字段名是否合适，用什么类型好，字段长度多少合适，是否有枚举值等等，都需要一一斟酌。如果这点做好了，在实施的时候，可以避免很多麻烦，甚至避免返工。

**
**

(4)对外依赖提前确认

**技术方案 1：**需要依赖缓存、分布式调度中间件、消费外部的消息，但是没有把对应的中间件使用方式、数据格式贴出来。

**技术方案 2：**需要依赖缓存、分布式调度中间件、消费外部的消息，将缓存接入的方法 & 对应的缓存 key-value 设计写清楚，将分布式调度中间件接入所需要准备的依赖项梳理好，将外销消息对应的 topic 和数据格式列清楚。

两个方案对比好坏其实很明显。如果一开始我们在技术方案里面将外部依赖确定好，那么我们在开发的时候就一马平川，反之如果外部依赖都不确定的情况下就进入到开发，那么返工的概率将大大增加，从而降低我们的工作效率。

那么，对外的依赖有哪些以及我们应该要确认什么信息呢？下面列举了一些常见的依赖情况：

• **外部 hsf 依赖：**需要确认对应 hsf 接口的类、方法、version，以及二方包（也可使用泛化调用）；
• **外部消息依赖：**需要确认消息的 topic、数据格式；
• **分布式调度、缓存等中间件：**当前应用是否接入过该中间件，未接入需要去到官网确认接入文档，接入的话需要确认是否可以复用接入逻辑。

**
**

(5)内部前后模块依赖 & 层次结构

模块依赖层次从高到低分为：

• 领域依赖（如交易依赖商品）
• 应用依赖（如 cntcp 应用依赖 cngfc 应用）
• 接口依赖（如滚存看板查询接口依赖于锁接口 & 渠道集接口）

我们举接口依赖的例子来看：一共三个接口分别是滚存看板查询接口、锁接口、渠道集接口，滚存看板查询接口依赖于锁接口和渠道集接口。

技术方案 1 目录层次：滚存看板查询接口、锁接口、渠道集接口；

技术方案 2 目录层次：锁接口、渠道集接口、滚存看板查询接口。

很明显，技术方案 2 是更加合理的，A 依赖于 B 那么 B 应该先做。

我们在写技术方案的时候，要考虑什么应该在前什么应该在后，而不是想一步写一步。要有一个清晰、有序的结构，不然别人看起来就会是杂乱无章的。

**
**

3.技术方案内容

(1)具体的接口定义

这里总结对接口定义有几点要求：

• 完整的类和方法名
• 入参字段如果系统中已有，那便沿用；如果没有，那么英文的描述需要准确（可同产品业务商榷）
• 出参字段要求同入参

(2)详细的时序图

(3)技****术选型分析

(4)安全生产

• 监控
• 对账
• 灰度方案
• 数据隔离
• 兼容性评估
• 发布流程

三、架构实践

1.业务架构与产品架构设计实践

一种好的产品架构图，应该具备以下特点：

• 清晰的模块功能边界
• 功能经过抽象，做到标准化、互相独立
• 上下游产品功能边界清晰，架构分层明确合理，具备迭代优化的能力

(1)列出问题域

问题域，是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能需要解决的问题放入产品框架的范围，能够帮助你的产品架构拥有更高的可拓展性，在后续具备迭代和优化空间。

​

• 找到收到的需求中，跟产品形态、产品目标相关的语句，去列出“xx 的流程会是什么样”、“xx 该如何达成”之类的问题，直到如果这些问题解决，能够实现核心需求的方向和业务目标。
• 去逐次寻找这些问题需求被解决的过程中，是否有其他要先解决掉的问题、或者其他跟业务相关的问题能够被解决。
• 按照层级去罗列所有的问题，并附上自己的初步回答，从而形成一个初步的、自己的产品能够解决的“问题域”。

**
**

(2)确定产品方向

在经过问题域的罗列后，能够得到一个模糊的产品方向和功能范围。问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充、拓展和翻译成一个能够在商业模式和用户体验能够形成闭环的产品需求。

• 产品用户：需要明确产品定位的用户，解决核心用户的核心需求。
• 核心目标：思考清楚自己产品的核心目标是什么。如果以一个 KPI 指标衡量产品的价值，那这个 KPI 应该是什么。
• 依赖系统：自己的系统需要与哪些外部系统存在交互和关联关系，我们的系统在这个大的生态下，是什么定位。

​

**
**

**(3)**绘制业务流程

这一步需要根据产品需求和问题域，按照业务域的流程进行绘制。

​

**
**

(4)业务功能矩阵

通过对业务流程进行分析，根据功能职责，进行垂直分解，识别出业务功能和业务服务，将他们归类到相应的流程节点中去。将业务流程和业务功能点组合成一张业务功能矩阵。这张矩阵图是业务架构中为后续的数据架构、产品架构、技术架构作为重要的输入。

​

(5)功能架构分层

产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。以业务架构的业务功能矩阵图作为输入，将流程图转换成按节点进行分层，节点的功能点存放在同一层中。

​

在此基础上将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。

​

**
**

(6)明确功能边界

一个具备前后台关系的产品架构图至少分三层：用户感知层（在何种场景下通过何种方式触达用户）、功能模块层（通过哪些功能模块实现产品的核心功能、和哪些外部平台功能有信息交互）、数据层（产品的数据从哪里来、产品的数据沉淀到哪里去）。

在上一步进行简单分层后，我们已经得到一个初步框架，但是难免会有分层不明确的问题。此时需要按照两种维度来处理架构图的层级：不同信息层级的边界、同一层级内模块和模块的边界。

①处理不同信息层级的边界

架构图的层级表达其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。其中用户感知层和数据层通常化简为以（用户端的功能表达往往逻辑简单、数据来源问题则不是自己产品的核心功能），而功能模块则需要按照自己产品的逻辑去将功能模块层内的主要模块变成新的层级。

②处理同一层级内子模块的边界

各层次之间虽有相关，但同一层次内的子模块之间一定是相互独立、界限分明的。将解决不同问题的功能拆分成两个子模块，做到一个问题只在同一层解决，避免牵一发而动全身的情况出现。

(7)明确系统间边界

产品边界对于开发设计系统架构、业务间的合作模式都非常重要。在架构图中用不同颜色标识清楚，各个部分所属系统的边界。通常属于自己团队的部分用亮色标识。像外部系统，如数据层的用暗色标识。

(8)加入信息流

产品架构图在表达产品的核心功能外，也应该体现信息流动的路径。当前层级数据的交互形成产品功能，产品功能又产生新的数据，从而推动下一层级的功能运转起来。

如果当前产品的主要使用角色只有一个，则只需要用箭头表明模块间信息流动的方式即可。如果当前产品涉及的角色比较多，则需要用不用颜色的线条将他们和各个模块之间的信息交互关系表示出来。

2.数据架构

数据架构重要的输出是 ER 图。ER 图中包含了实体（数据对象）、关系和属性 3 种基本成分，ER 图可以用来建立数据模型。如何准确的建立产品的数据模型，需要分解出业务需要什么样的数据。数据域的分解过程是站在业务架构的基础上，对业务域进行模型分析的过程。

最终一种好的 ER 图需要具备以下原则：

• 同一实体在同一个 ER 图中只能出现一次
• 先设计局部 ER 图，再把每一个局部 ER 图综合起来，生成总体的 ER 图。

采用四色原型法进行业务模型的抽象，四色模型，顾名思义是通过四种不同颜色代表四种不同的原型。

• Moment-Interval Archetype 时标性原型，表示事物在某个时刻或某一段时间内发生的。使用红色表示，简写为 MI.
• Part-Place-Thing Archetype 参与方 - 地点 - 物品原型，表示参与扮演不同角色的人或事物。使用绿色表示。简写为 PPT。
• Role Archetype 角色原型，角色是一种参与方式，它由人或组织机构、地点或物品来承担。使用黄色表示。简写为 Role。
• Description Archetype 描述原型，表示资料类型的资源，它可以被其它原型反复使用，并为其它原型提供行为。使用蓝色表示。简写为 DESC。

(1)关键流程

在进行业务建模前，首先需要梳理出业务的流程，这一步在业务架构分解环节中已经完成。按照四色建模法的原则，将业务流程图进行一点改造。在原来的流程图上，将流程涉及的事务和角色添加进来。

(2)领域模型骨干

从业务流中，可以清晰的定义出 Moment-Interval Archetype （时标性原型），流程中的每个节点符合 MI 的定义，即事物在某个时间段内发生。在 MI 的定义过程中，一种方法是通过名词 + 动词进行定义。那么，风控的 MI 即为：数据采集、规则 & 模型设置、风险识别、告警通知、风险处置、风险分析（MI 使用红色表示）。

在得到骨干之后，我们需要丰富这个模型，使它可以更好的描述业务概念。这里需要补充一些实体对象，通常实体对象包括：参与方、地点、物（party/place/thing）。

Part-Place-Thing Archetype（参与方 - 地点 - 物品原型）：业务对象、规则、模型、异常风险、通知、异常事件、分析报告（PPT 使用绿色表示）。

领域模型骨干图，如下：

(3)领域模型角色

在领域模型骨干的基础上，需要把参与的角色（role）带进来。Role 使用黄色表示。如下图：

(4) 领域模型描述

最后将模型的描述信息添加进来，模型的描述信息中涵盖模型的具体属性。这些描述信息对于后面数据库设计有很大的影响。

模型描述使用蓝色标注，如下图：

(5)提取 ER 图

领域模型构建完成之后，在此基础上，我们已经能够初步的掌握整个系统的数据模型。其中绿色的 Part-Place-Thing Archetype（参与方 - 地点 - 物品原型），可以用来表示 ER 图中的实体模型。红色的 Moment-Interval Archetype（时标性原型），可以用来表示 ER 图中的关系。对领域模型架构图进行提炼，得到如下图：

实体（Entity）和联系（RelationShip）存在一定的关联关系，一般存在 3 种约束性关系：一对一约束、一对多约束和多对多约束。将这些约束性关系表现在 ER 图中，用于展现实体与实体间具体的关联关系，最终输出 ER 图。（考虑保证 ER 的简洁性，这里并没有把模型的属性画进来）

​

3.技术架构

技术架构图是将系统的技术方案、技术选型通过视图的方式进行展现。技术架构图分为两类：一类，功能需求技术架构图（逻辑架构图），是描绘如何通过技术组件来实现系统产品功能的图。另一来，非功能需求技术架构图（物理架构图），是描绘如何通过物理部署的来实现系统运行的图。

(1)整体

(2)局部

在整体框架的基础上，对每一个局部的子系统进行详细的技术实现的表达。子系统的技术架构图中需要展示每个子系统使用的技术组件，比如（缓存技术、消息中间件、流程引擎、流式计算框架等等）。同时，这些技术组件是如何实现业务功能，需要清晰的展示技术实现逻辑。

下图是对风控系统中的实时引擎、离线引擎、准实时引擎三个子系统的进行的技术架构。在实时引擎中，主要使用 RuleEngine（规则引擎）作为技术特点，这里就重点列出 RuleEngine。准实时引擎使用 Blink 作为流计算的技术框架，并概要的展示了计算逻辑。

(3)整体

在完成每个子系统的技术实现后，最终进行一次整合，绘制一张总体的系统技术架构图。各子系统之间通过服务接口、数据库、缓存或消息中间等技术实现数据交互，以此将打通各个子系统，实现最终整个产品从数据、技术的串联。

4.物理架构

物理架构偏重于网络设计、集群设计、中间件设计、数据存储设计等基础软硬件的设计架构。非功能需求的技术架构图重点在于展示企业系统在物理上是如何部署。物理架构规定了组成系统的物理元素、物理元素之间的关系以及他们的部署策略。物理架构反映出软件系统动态运行时的组织情况。从物理架构图中，我们能够全局的得知整个系统是如何从流量访问、数据流转、数据存储到技术组件的运转。

零基础入门AI大模型

今天贴心为大家准备好了一系列AI大模型资源，包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

有需要的小伙伴，可以点击下方链接免费领取【保证100%免费】

点击领取 《AI大模型&人工智能&入门进阶学习资源包》

1.学习路线图

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

2.视频教程

网上虽然也有很多的学习资源，但基本上都残缺不全的，这是我自己整理的大模型视频教程，上面路线图的每一个知识点，我都有配套的视频讲解。

（都打包成一块的了，不能一一展开，总共300多集）

3.技术文档和电子书

这里主要整理了大模型相关PDF书籍、行业报告、文档，有几百本，都是目前行业最新的。

4.LLM面试题和面经合集

这里主要整理了行业目前最新的大模型面试题和各种大厂offer面经合集。

👉学会后的收获：👈

• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

5.免费获取

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码或者点击以下链接都可以免费领取【保证100%免费】

点击领取 《AI大模型&人工智能&入门进阶学习资源包》