当产品经理升职后，一般都会要求负责系统架构的设计。之前没有接触过这种，如何快速处理？本文写给已负责或即将独立负责系统，为系统架构设计苦恼的产品人&曾经的自己：

系统架构系列目录：

• 三大系统架构设计-业务系统篇（上一篇）
• 三大系统架构设计-工具&服务系统篇（本篇）

一、困惑

我所在的大部门内部是乐于分享的，此前能听到很多产品对自己负责的业务&系统进行分享，有幸看过了很多系统架构图，有意思的是，不同产品经理负责分享时的系统架构图都不太一样，举2个明显差异化的例子：

催收系统架构图如下

认证中心架构图如下

可以看到上述2个系统架构图有明显差异：

1. 前者按照业务主线横向拆分阶段，模块化来体现系统架构；
2. 后者按照关联业务&业务应用&服务组件纵向分层，模块化来体现系统架构；

从2021年到现在，期间有过几次困惑：系统架构图是非标的吗，为什么每个人的系统架构图都，各有千秋呢？随着主导各类系统从0到1或系统重构的项目经历不断丰富，对于系统架构的理解才有了自己的答案；

在互联网中，公司商业模式的主营业务流往往需要多个系统支撑串联，而支撑业务的系统都有自己的侧重，不同侧重类型的系统，其架构表达形式自然有差异；

从众多系统全盘看，系统可以分为3类，每一类都有各自的特点；

一、系统分类&特点

名词解释：

核心能力：指系统中提供可直接使用的功能；以各类系统的核心能力举例

• 决策引擎：策略配置&信息决策；
• 订单中心：创单&订单流转&订单查询；
• 呼叫中心：软电话点呼&预测试外呼&语音机器人；

名词拆解：

在此补充2个新的名词，本质上是对系统核心能力的拆解细分；

• 基础能力：代表了系统最基础的原子级别的功能，作为应用能力的核心组成部分，或是应用能力的前置条件；
• 应用能力：代表了系统对基础能力包装后可直接对外提供服务的功能；

在笔者所接触的风控业务系统中，基本没有区分应用能力和基础能力，而工具&服务系统则重点对基础能力和应用能力进行区分；其差异化的原因下文会详细说明。

二、系统架构设计思路

系统架构是产品经理梳理出来，面向人员（其他相关产品经理、开发人员、测试人员），让其能够清晰的明白系统的定位和能力以及系统边界（其与上下游外部系统的关系）；

通过明确系统架构的价值，反向推断一个系统架构图中应当具备的元素和内容，这样系统架构需要做什么，就很明确了：

1. 系统定位和能力→定位的本质是核心能力的概述，能力的本质是功能点的具象化；
2. 系统边界→系统与上下游外部系统的关联关系；

而系统功能点的来源，是将线下的执行事件，转化到线上系统进行支持体现；系统关联关系，则可以明确系统内部能力的同时，按照上下游外部业务接入方进行划分。

因此要想无遗漏的梳理功能点，同时明确系统内外部关联关系的前提，需要对调用系统能力的多条业务线，在实际调用的相关业务环节进行全盘梳理；

为此，我将整个系统架构设计分5步：

明定位（敲定基础能力）→抽线盘点定标准（梳理多条业务线流程各阶段执行事件，定义对接标准）→抽象（提炼功能点）→分层（服务拆分）→划分边界（区分上层调用方&依赖的下游系统能力）。

0、为何要先明确定位

系统定位是什么？本质上定位是核心能力的极简体现，它约束了后续的迭代方向。

没有明确定位的系统，在系统迭代过程中没有方向，往往会越做越乱，变成一个大而全甚至与外部系统耦合的功能集合体，比如系统会做一些定制化功能，违背通用特性。

举个有趣的实际案例：

几年前我负责贷后催收系统时主导一个催收先还款后返现的需求中，就曾任性的要求支付系统的产品经理，在提供的退款接口中，需要对催收请求的返现金额按照一定逻辑进行拆分后在进行对应订单进行原路退款，最后被对方直接了当的拒绝了，拒绝理由清晰明了：支付系统的定位就是提供通用的支付应用能力，返现金额拆分属于仅催收特定场景，属于不通用的定制化业务逻辑，其不该由服务系统承接。

这就是清晰的系统定位，为产品经理在需求对接和设计过程中带来的判断依据。我现在想起来还记忆深刻。

所以“工具系统”&“服务系统”在未确定系统定位之前，不要想系统架构设计，先明确一个清晰的系统定位，才能保证系统规划设计不会跑偏。

1、明确定位→敲定基础能力

明确系统定位：除了约束后续的迭代方向，最重要的是敲定核心能力的地基-基础能力，即系统最基本的原子能力，它是核心应用能力的组成部分或前置条件。

分别以笔者主导0~1建设的呼叫中心，参与重构设计的订单中心举例：

工具系统-呼叫中心：

• 定位：围绕外呼相关场景，提供呼入呼出的通用应用能力
• 基础能力：通过硬件实现浏览器&线路的通话信令的转化&传输；

外呼中心相对比较特殊，需要由特定的硬件去实现基础能力的支撑，所以相对常规系统多了一个硬件层体现信息流；由于软交互机在通讯领域是一个很复杂且相对成熟的硬件，这里就不做展开说明。在整个系统架构设计之前，首要了解的就是呼叫中心最底层能提供什么样的基础能力。否则，上层应用的建设就是没有支撑的空谈。

服务系统-订单中心

• 定位：提供订单全生命周期的管理能力；
• 基础能力：收单创单、订单流转&更新、订单查询；

敲定基础能力的重点在于：上层应用能力的建设无法脱离底层基础能力。因此明确定位后，就需要产品经理将定位转化为具象的底层基础能力，这是为什么定位能约束系统后续迭代方向，实际产生约束作用的，还是具体的基础能力。

2、抽线→盘点→定标准

抽线：是指抽出本系统服务外部业务线的局部环节（流程）；

盘点：是指抽线后的流程中，按照阶段性拆分，找到多条业务都有哪些事件需要支持，最终基于事件挖掘出对用系统需要提供的功能点；

定标准：定义外部接入层对接标准。

其中工具类系统&服务类系统在这一步存在明显差异：

1. 工具类系统，针对于特定场景，外部的业务系统将工具拿来即用，不存在流程or业务路径依赖；例如呼叫中心的呼叫面板、合同系统的电子签等等工具可拿来即用。
2. 服务类系统，针对于某个环节进行全周期服务，内部是存在信息流闭环的，正如订单中心，用户中心，分别管理了订单、用户账号的全生命周期，提供的能力也是整个环节流程中的一系列链路支持，且服务存在链路依赖关系。比如闭单的前提肯定是已经创单过了。

工具系统：先盘点→再定对接标准

在工具类系统架构设计步骤中，抽线盘点可以简化为对外部涉及工具的应用场景进行重点挖掘即可确定清楚功能点。

当然除了功能点以外，还需要针对工具对接流程也是需要制定一套标准：

服务系统：先抽线→再盘点

在服务类系统架构设计步骤中，则需要先抽线：完成环节内部流程梳理。再盘点：通过各条业务线的各阶段性事件来找出对应功能点；以订单中心举例

3、抽象

抽象：是指从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。

抽象的价值在于避免系统中出现很多同质化的功能，这样系统就越轻量，系统建设的总人力投入成本越少；

举例：

• A前置条件，执行M事件，假设开发“A条件”需投入1人日，开发执行事件需投入1人日；
• B前置条件，执行M事件，假设“B条件”需投入1人日，开发执行事件需投入1人日；

这2个事件最终实现为2个功能点，总计投入4人日;

当我们将A&B前置抽象为一类条件，将这2类事件合并为1个事件：（A或B前置条件）执行M事件，其中开发执行M事件仅需投入1人日，总计投入3人日，即可完成1人日的人力节省。

投入的对比可以直观的体现出抽象精炼功能点的重要性，那么具体应该怎么抽象呢？

当工具类&服务类系统经过抽线盘点后，通过比对各业务线是否需要相同的功能点，若功能在系统服务流程或场景中，被2+业务线应用且功能不会导致系统与业务耦合，就可以考虑将功能统一纳入到工具&服务系统范围实现；

例如：订单中心的闭单的后置动作：恢复优惠券&恢复额度

常规上来看，订单中心只需要关注订单状态，数据变更，至于被闭单后请求优惠券恢复，请求已被扣减的额度恢复，理应由业务线自己发起请求执行闭单后的动作。

但由于闭单后3条业务线都存在恢复优惠券、恢复额度的逻辑，此时这2项后置动作可以统一做成闭单组件，由订单中心闭单后，对外触发，这样一来就避免多个外部接入系统重复造轮子。

4、分层

分层：是指将系统内部服务拆分不同层级（可理解为不同区域的服务）

通常来说工具类/服务类系统可以拆分为2层：

• 基础服务层覆盖系统最底层的基础能力，它几乎不直接对外提供服务（不绝对，需要根据单一或多业务形态进行适配）。
• 通用应用层通过组合&调度基础能力，来对外提供应用能力。

最终实现应用与基础拆分的解耦合方案，这样后续上层业务线有变化，通用应用层针对调整即可，基础服务层无需变动。

不同类系统分层的差异性

在我接触的所有系统中，无论是业务系统、工具系统还是服务系统，底层服务都是进行了分层，只不过分层的考虑维度不同，差异性在于系统服务范围不同：

1. 业务系统服务单条业务线的全链路流程，核心功能都是针对业务团队定制化做出来，基本做出来就是1个独立的功能供单方业务应用；在这种系统内大量以定制化服务为主的，按照基础能力、应用能力拆分显然是不合适的。
2. 工具系统服务多条业务线的某些具体场景，而服务系统服务多条业务线的局部环节，它俩都必须具备通用性，这时系统为了快速响应上层接入系统的需求，同时保持底层服务纯粹，不因外界变化而频繁调整，所以将基础能力拆分出来放在底层隔离，而新增一个中间层作为通用应用层，为上层接入系统提供调度或组合，支撑外部接入系统应用。

以催收&呼叫中心&订单中心，对比业务系统 & 工具系统 & 服务系统 的分层维度侧重：

1）业务类-催收系统-底层技术服务主要分为2套：服务分层侧重于性能稳定，保障系统易用性。

• 一套work服务：主要应对核心的定时任务，包括主流程的进件数据组装功能、以及批量数据结果例如减免/划扣/短信等数据的拉取；
• 一套web服务，主要针对页面操作，列表数据查询；这样以保证高频查询不占用核心定时任务的性能资源；

2）工具类-呼叫中心-底层技术服务分为2套：服务分层侧重于解耦，保障快速响应业务变化的同时避免高耦合导致后期复杂的维护成本；详见下方图例

• 一套基础服务-软交换：主要提供线路连接、呼出&呼入&通话记录&媒体记录这些最基础的服务；
• 一套通用应用服务：主要提供的点呼&团队预测试外呼&智能语音机器人&号码池路由，这种外部可以直接调用的应用功能；

3）服务类-订单中心-底层技术服务分2套，分层侧重同上呼叫中心，详见下方图例

工具类–呼叫中心分层图例如下

服务类-订单中心分层图例如下

5、划分边界

划分边界：是指将工具&服务系统的上下游关联关系体现；

当系统完成服务分层后，通过接入层体现上游接入业务线或调用系统，通过外部依赖层链接下游提供能力支持的系统即可完成系统关联关系的表达。

最终呼叫中心的完整系统架构表达如下：

三、总结

系统分类特点上

工具系统与服务系统虽然都具备通用性，但两者在细分服务类型上存在差异

1. 工具系统聚焦具体场景服务，无论这个场景是属于N条业务线还是1条业务线，它不关心。系统对外提供工具化能力，拿来即用。
2. 服务系统聚焦业务流程中的局部环节，系统内部能形成一条服务链路，对外提供通常是一系列能力支持。

系统架构设计思路上

工具系统和服务系统设计区别在于是否需要盘点业务流程，其他思路一致

1）先明确系统定位：通过定位敲定系统基础能力

2）抽线→盘点→定标准：

• 工具类系统：直接盘点未来接入业务线的应用场景，再通过定义对接标准，完成全部功能点的挖掘；
• 服务类系统：先梳理内部服务流程链路，阶段化对服务的多业务线进行事件挖掘，找出功能点；

3）抽象：比对接入业务线的功能点，若功能在系统服务流程或场景中，被2+业务线应用且功能不会导致系统与业务耦合，就可以考虑将功能统一纳入系统实现为公用组件。

4）分层：不同维度进行服务分层，通常以基础服务、通用应用拆分，保证低耦合度的同时可以快速响应多方业务变化。

5）划分边界：链接上游接入层，下游外部依赖层。

拓展阅读：

• 相关阅读：3大系统架构设计-业务系统篇
• 风控系列1.信贷法催业务模式与系统架构
• 风控系列2.信贷电催业务模式与系统架构
• 风控系列3. 关于互联网金融风控的思考