第05期：如何设计产品架构

1 关于产品架构

1.1 定义

架构这个词往往代表了骨架和脉络，是抽象模型。产品架构就是产品的骨架和模型。假设人体是一个产品，那么人这个产品最粗粒度的架构就有头、四肢、躯干，通过骨骼支撑起来。在这个架构之上附着了肌肉、器官和皮肤等，构成了整个人体。在日常工作中，我们常常会听到好几个架构，业务架构、信息架构和技术架构，这些和产品架构是什么关系呢？我的理解是这样的：

• 业务架构往往是为了达到业务目标(通常是商业目标)所搭建的业务体系和商业模式，比如著名的亚马逊飞轮效应和Google搜索的印钞机模式。业务架构包括且不仅限于产品，产品架构是为了更好的支撑业务架构而构建的。
• 信息架构主要是产品在结构层的一部分，通常是在交互设计阶段考虑的产品给用户呈现的产品全貌，让用户可以清晰快速的找到功能的方法。有些说法会把产品架构和信息架构当成一回事，在一些2C产品里，从信息架构里就能看出产品架构，如新闻资讯类的app。但实际上信息架构只是产品架构的一种表现形式，并不能完全代表产品架构。
• 技术架构是产品架构的实现，并还覆盖有其他范畴，是个独立的大话题。在一些偏向技术型的产品里，产品架构和技术架构很接近，比如云计算产品，其用户本身就是程序员，所以云计算产品的产品架构和技术架构就非常接近了。
• 实际案例

接下来，以实际工作中的系统为例，讲解三者之间的关系，以便加深大家对业务、产品、信息架构的理解。业务背景：一家物流平台公司，面向物流市场中大客户及中小客户销售物流服务产品，为客户提供物流配送及仓储行业解决方案。因此，需要与客户签约，并进行合同单据管理，以作为合同物流凭证。

1. 业务架构

通过“场景、角色、流程”梳理业务流程。从中发现大客户与中小客户合同签约流程不同，大客户流程更复杂、更长，而中小客户流程相对简化和标准。（实际业务流程很复杂，此处是作者有意简化内容，实际还会制作业务角色流程图）。

2. 产品架构

通过业务流程分析，我们发现大客户与中小客户签约流程虽然不同，但依然存在共性的地方。如：都有合同模板，只是模板不同；都需要审批，只是运营审批和自动审批区别；都需要线上化签约；都需要线上化管理合同信息等等。因此，经过分类聚合后，我们将合同系统的功能模块设计为“合同模板管理、合同审批模块、电子签模块、合同信息管理模块等”。

3. 信息架构

交互层面设计主要考虑客户签约便捷性以及客户技术能力。因此，针对不同客户，合同系统提供多种形式交互端。如：商家端、APP、API、短信等交互形式签约。产品架构本身也有三个层次：

• 独立可交付客户价值的业务产品。
• 单一产品内的模块化。
• 单一个模块的抽象设计，也就是功能设计的架构。

整体的关系见下图：

1.2 内容

当罗列产品架构包含哪些内容时候，其实可以对照把竞品分析方法搬出来，他们的结构和分析方法是一样。这里推荐一本书《用户体验要求》，主要是针对用户体验步骤将产品架构进行拆解分为五个层面：

• 战略层：需要明确的长期和短期产品目标以及用户需求。
• 范围层：将产品目标和用户需求拆分成功能需求、并针对需求进行分析。
• 结构层：针对页面和页面之间的关系做连接，拆分复杂架构并变得简单化。
• 框架层：通过页面进行布局，比如：重要的信息展示在显眼位置，这里主要是产品和UI设计师有更多的沟通和串联。
• 表现层：通过设计展示给用户视觉传达的，比如：通过形状大小、字体大小、颜色深浅等因素来影响用户感知，已达到产品设计这功能目的。有些产品架构是比较复杂的，一般针对To B用的业务管理系统、电商网站的管理系统等。

虽然说里面的内容很庞大复杂，但是应该从主线去拆分，比如：电商管理系统，商家管理后台主线是前端用户生成订单后的操作步骤——沟通反馈，物流信息的处理和售后等，同时完善自己店铺的信息。针对于To C产品整体的产品架构越简单越好，不需要教育成本，虽然说看到的有些产品功能很庞大，但是整体的架构分类还是非常清晰的（比如：微信和QQ）。

1.3 为什么要设计产品架构

产品架构是对业务本质的抽象，只有找到了业务本质并且抽象成了业务模型，我们才会明白目标客户的业务到底是怎么流转和运营的，也才能明白我们产品侧重点是什么，什么样的解决方案才能去满足客户的核心诉求，同时也是产品进行需求判断的核心基础。而基于对业务理解抽象之后而产出的产品架构是指导产品演进的路标，我们通过产品架构的抽象，看明白了客户业务是什么，长什么样，才能明白我们产品现在的样子到产品最终的样子到底存在多少偏差，才明白我们如何迭代成产品最终的样子。产品架构同时是整个产品的骨架，是整个产品最终能够落地的依据。好的产品架构能够带来哪些价值呢？借鉴云计算产品的说法，本文这里也提出一个三高的说法：

• 高可用。在多业务产品组成的产品矩阵中，每个产品可独立交付价值，也可组合成不同的解决方案。
• 高可靠。在单一产品内，基于解耦化和模块化的设计，对模块类逻辑的调整，其复杂逻辑所造成的影响往往控制在模块内，模块之间依然还是通过定义好的输入输出进行交互。
• 高可扩展。在单一产品内，基于模块化定义好的规则，不需要事无巨细的了解整个产品的所有细节逻辑就可以快速扩展产品功能。

由此可见，好的产品架构是相对稳定的，在业务方向本身不发生重大变化的情况下，是可以事半功倍的支持业务发展的。

2 如何设计产品架构

2.1 方法

产品架构的设计，总的来讲只需要五步，我总结了五句口诀，希望可以帮助大家进行记忆：一理场景画流程，二列页面和模块，三把功能来聚类，四五纵横法上阵，一张好图胜千言。

1. 一理场景画流程

根据实际业务逻辑，基于用户、角色、场景，梳理核心的业务流程，并先将业务流程图简单绘制出来。目前各大厂商对互联网产品经理的要求里往往非常注重同理心和用户体验，这是一个具象化的过程，在一个具体的场景里以用户的视角来体验和设计产品。而做产品架构则有了不同的要求，产品经理需要基于用户场景找出一类需求，并且还需要考虑到背后的需求，衍生的需求。对于这些需求进行抽象和建模，找出一些通用型的解放方案去满足他们的需求。并且，由于B端产品的价值流和功能逻辑相对于C端产品往往要复杂很多，对于B端产品经理而言，产品架构的要求往往更高。

2. 列页面和模块

基于第一步梳理出来的核心业务流程，根据目标用户的使用路径等，列出每个流程涉及的页面、功能模块或处理机制等。这一步的关键，是要想清楚每个业务节点可能会面临什么样的问题，我们要设计什么样的页面、功能或者处理机制，才能够支撑起这些业务问题的有效解决。用户在一个较复杂产品里进行操作，其需求被满足的整个的流程会涉及到很多功能，其中这些功能可以进行分类，同一类功能组合成一个模块。因此一个复杂产品内部可以划分出多个模块，每个模块负责业务流中相似的一类功能。以淘宝为例，商家在淘宝上开店并发布商品，用户到淘宝上搜索到商品，下单购买。这一套业务流程里在淘宝这个超级app里，除了人机交互的那层壳以外，产品被划分成了以下模块。其中每个模块虽不能单独满足用户想要的商品购买的完整体验，但可以专注的解决购买过程中一类问题。而当这些模块抽象到能够服务淘宝以外其他的产品时，这就是中台了。

3. 三把功能来聚类

审视一下业务流程图中每个节点下所有的页面、功能或处理机制，将类似的能力以模块化的形式组成一张简单的矩阵图。这一步先不用关注架构的分层，简单聚类罗列矩阵即可。

4. 四五纵横法上阵

第四步和第五步是最终形成一张有效的产品架构图的关键，分别是从横向和纵向的角度对产品的功能框架进行梳理。四是将明显是同一范围或同一组的产品功能放在一个横向层级中，得到一个基础的产品框架；五是在基础产品框架的基础上，自下而上处理不同架构层级的关系，明确不同产品或系统之间的边界逻辑。

2.2 案例

为了帮助大家进一步理解如何设计产品架构，这里以一款理财产品的支付流程为例，我们来绘制一下产品架构图。

（1）梳理业务流程

从用户使用的角度来看，用户购买理财产品并执行支付的核心流程包括以下四个环节，核心业务流程如图2.1所示：用户在理财平台选择产品，点击购买后启动支付流程理财平台根据用户选择的支付方式来发起支付请求用户在支付二次确认页面选择立即支付，输入支付密码，执行支付操作理财平台获取支付机构返回的支付结果并展示给用户图2.1 核心业务流程

（2）罗列功能模块

基于上面梳理的业务流程，下一步要考虑流程中每个节点对应的场景都需要解决什么问题，进而思考应该设置那些页面、功能模块或处理机制来支撑问题的解决。图2.2 罗列功能模块

（3）形成功能矩阵

通过第二步对核心业务流程中的每个业务节点对应的功能模块进行罗列，我们就可以进行下一步了，将功能类似的模块放在一起，形成功能矩阵，为后续的纵横法分层做铺垫。图2.3 形成功能矩阵

（4）构建基本框架（横向分层）

下面将明显是同一范围或同一组的产品功能放在一个横向层级中，得到一个基础的产品框架。图2.4 横向框架

（5）明确架构分层（纵向分层)

这一步，在基础产品框架的基础上，自下而上处理不同架构层级的关系，明确不同产品或系统之间的边界逻辑。图2.5 纵向分层产品架构图是对一个产品体系架构的高度抽象，是产品同事最应该反复揣摩反复优化、也最应该能够熟练绘制的图形。而一项简单的工作想要做顺做好，是需要掌握一定的套路或者说心法的。产品架构图的绘制心法并不复杂，关键在于实际工作中的运用，再遇到要画产品架构图的时候，请默念一遍心法口诀，相信你会不再犯难：一理场景画流程，二列页面和模块，三把功能来聚类，四五纵横法上阵，一张好图胜千言。

2.3 标准

如何验证一个产品架构是不是好的产品架构呢？下面几个评判标准供参考：

• 主次分明：好的架构有很清晰的结构，底层逻辑、核心逻辑和非核心逻辑有很好的定位，不是混在一起的。
• 逻辑通畅：好的架构要支持业务流程连贯，除了一些必要的强校验外，应极少出现分支和卡顿。对于那些影响主流程通畅的子流程，应该剥离出去。
• 边界清晰：不同业务模块之间相互独立，保证模块内高内聚，模块间低耦合。
• 扩展性好：好的架构一定是面向未来的，在保证主体结构稳定的前提下，能够兼容更多业务场景以较小的成本接入。
• 持续迭代：好的架构不是一成不变的，而是可以随着业务的迭代节奏不断进化的，时刻保持与业务的同步性。
• 服务抽象化，尽量通用：抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。将业务能力转化成对应的业务实体就是抽象的过程，即对相同或相似的业务能力提取出共性的特征，抽象出可以提供给不同前台的公共服务，尽量做到服务通用，个性化需求由不同的前台实现。
• 渐进性建设。渐进性的建设原则是从降低风险和实施难度这个角度出发，推荐小步快跑的方式逐步推进，而不是轰轰烈烈地推翻重来，试错的成本更低。

做系统设计时，业务理解固然很重要，但架构设计也同样不可或缺，业务理解帮我们贴合业务创造价值，架构设计帮我们分清主次走得更远。当我们从功能实现转为梳理产品架构的时候，就是产品能力跃迁的时候了，一起加油吧。

3 举例1、一文读懂电商产品架构

看完本文，你将对以下问题有所了解：

1. 一个完整的电商业务是怎样的？
2. 电商业务背后都有哪些系统支撑？
3. 电商各系统模块是如何串联的？
4. 如何设计电商系统的产品架构？

大部分刚接触电商领域的产品经理，或多或少会体会到电商系统的模块多、流程长、逻辑复杂。电商系统中，除了前端APP和网站看得见摸得着外，更多的是看不见的底层逻辑和后端系统。对于大部分同学而言，要找到同类后端系统的竞品进行研究借鉴是一件比较麻烦的事儿，因此长期以来便形成了一种电商产品的门槛比其他行业的产品门槛要更高的错觉。虽然电商产品比较复杂，但是它有一个很重要的特征，那就是电商产品属于典型的业务驱动型产品。业务驱动型产品，其所有功能都服务于一个实体业务。因此想要弄清楚电商产品有哪些功能模块，可以从电商的业务入手，先了解一个完整的电商业务有哪些环节，基于每个环节再分析需要哪些功能来支撑，将所有功能穷举完以后，再按照一定的逻辑进行归纳总结即可窥探电商产品的全貌了本文将从电商的业务流程到电商的系统流程再到电商的系统架构这三个部分展开，分别通过三张图来深入浅出展示电商的世界。

3.1 电商核心业务-采销仓配

电商发展至今，出现了各种各样的叫法，有平台电商、自营电商、B2B、B2C、生鲜电商、社交电商、兴趣电商等等。不论电商的形式如何多样，其本质都是买卖双方围绕商品交易履约的过程。在开始探讨之前，我们先圈定一下探讨的方向，本文主要以自营电商为探讨方向。因为与之相对的平台型电商的核心其实是流量生意，系统的责任更多的是将海量的商品和消费者做匹配，平台以此向商家收取交易佣金和广告费。而自营电商除了需要具备平台电商的能力之外，由于自采自销的业务模式还涉及采购、仓储、履约等实体环节，其系统模块更多更长更复杂，基本上能覆盖平台型电商的核心系统模块，因此以自营电商为主要探讨方向可以了解的更为全面。而其他诸如B2B、B2C、生鲜电商等只是领域或表现形式不同，不属于同一个维度。那么一个完整的自营电商业务是怎么样的？将一件商品交付给消费者需要经历哪些环节呢。（图片过大无法正常显示，请用电脑放大查看）通过以上业务场景图可以看出，一件商品卖给消费者需要经历的环节非常多，包括线下实体环节和线上系统环节，按照线下实体环节进一步抽象后，可以将自营电商业务划分为以下4个部分，分别是。

5. 从供应商处采购产品
6. 采购产品入仓存储管理
7. 商品上架到电商平台销售
8. 根据销售订单进行履约配送

用业务流程图表示如下。了解完业务流程后，基于业务流程再来梳理这些业务环节背后所需的系统就比较容易了。电商业务中所有的系统、功能都是基于以上业务流程所产生和演化的。

3.2 电商·系统全流程

基于上面的业务梳理结果，我们将业务流程和所需系统或功能结合起来，看看每个业务环节都有哪些系统或功能，同时，我们将整个系统流程按采销仓配的业务边界进行划分，再结合C端购买流程，就能得到一张完整的大型电商系统流程图，如下。（图片过大无法正常显示，请用电脑放大查看）上图就是一个较为复杂的电商业务在系统中的流转逻辑（参考京东），从供应商/卖家入驻平台到采购商品到收货入库到上架销售再到配送履约，通过这张图就可以比较清晰的看出每个业务环节所对应的系统或功能大概有哪些了。为了便于初学者理解，有必要对流程图中的的部分节点进行解释说明（可结合流程图图对比阅读）。

9. 入驻&采购流程

入驻：包括供应商入驻和卖家入驻，入驻动作主要包含选择入驻企业类型、基于类型提交相应材料（营业执照、资质等），签订合同，经过平台审核通过后，再开通企业账户钱包。开店：对于卖家而言，入驻成功后即可创建店铺，创建店铺主要是根据营业执照的经营范围选择主营类目、填写店铺基本信息、缴纳质保金等。采购供应商入驻后，自营采销在采购系统中下采购订单，订单通过EDI或者线下的方式推送给供应商。供应商发货。供应商收到采购订单后，根据采购单中的信息（商品、收货仓库等）发货，发货后即产生采购在途库存。库存。无论是在途库存，还是实物入库后产生的实物库存，以及前端的可售库存等，均由库存中心控制。

10. 销售流程

发布商品。即创建商品sku，包括填写商品参数，商品详情介绍等信息，POP卖家会直接设置价格，自营因品类而异，创建商品时会调用主数据，即spu。定价。发布商品时会通过定价系统制定销售价格，销售价格与采购价、库存成本价、促销价等一系列价格组成复杂的价格模型，并一起记录在价格中心，形成完善的价格体系。上架。发品并定价完成后，可通过上下架功能控制商品上架销售。促销。即通过营销工具做促销活动，包括单品类、总价类、优惠券等，所有的促销规则均通过营销中心控制，包括活动准入规则、不同活动之间的叠加互斥规则、促销命中规则、优惠计算、促销风控等。活动页搭建。促销商品有时候会在特定的活动专题页面集中展示（满减专区、特价专区等），通过CMS系统可以随时随地的通过拖拽组件的方式搭建一个任意样式的专题页面，而不用临时开发。

11. 黄金流程

指在用户视角下购买商品时所经历的页面，包括搜索—列表—商品详情页—购物车—提单页，很多公司内部也叫交易主流程或交易动线；黄金流程是价格和促销的主要体现环节，因此在在黄金流程中，对于价格和促销的设计尤为重要，包括优惠价格的高亮突出，促销标识的设计，购物车的凑单分组等，对转化有直接的影响。生成订单：生成订单在后端是一个非常复杂的过程，包括校验库存、价格、库存、用户信息、促销信息等，订单由订单中心负责创建生成。预占库存：生成订单的同时，会与库存中心交互预占库存。收银台：订单生成和支付是两个独立的环节，常见的支付方式有【在线支付】和【货到付款】，部分业务（B2B）会设置【对公转账】支付方式，后面两种支付方式以线下的形式完成。对于在线支付的订单，则可以将多种支付方式聚合到收银台页面，包括自由支付、网银支付和三方支付（微信支付、支付宝支付、京东支付等）。支付对账。对于先款后货订单，各类支付方式均设有支付额度限制，对公转账的方式也无法保证用户一定按照订单实收支付，因此存在实际支付金额不一定等于订单应收金额，所以需要经过对账系统完成对账。

12. 订单寻源履约中心

介于交易流程和仓储流程之间的系统——将电商系统生成的数以万计的订单，按时下发给最适合的库房进行生产，就是订单寻源履约系统的职责。订单寻源履约中心由多个子系统或服务组成，包括拆分系统、分摊计算服务、转移系统、履约控制中心等。订单拆分：对账成功后，订单会进入到寻源履约中心的第一个系统——拆分系统。拆分的场景主要有：生产维度（仓库不同、商家不同、配送方式不同···）、业务类型维度（实物订单、虚拟订单、生鲜订单···）等，该系统的职责是按照不同的规则将父订单拆分成多个子订单进行生产。拆分时会调用分摊计算服务计算每个新子订单的金额。订单转移。订单拆分完成之后会流转到转移流程，订单拆分完成之后会生成不同类型的订单，经过转移之后，不同的订单要执行不同的生产时机、不同的生产地点、不同的生产流程。针对虚拟订单，不用经由库房实际生产，直接由转移给订单中心或者虚拟业务对应的系统进行处理。针对厂商直发订单和POP订单，因为这类订单都是由三方卖家发货或者工厂直接发货，转移系统会与对应的业务系统交互，生成供应商采购单或下传订单给POP对应的系统。针对自营的订单，由于订单商品所属的仓库不同、配送时效不同、商品的类型不同（如生鲜如要走冷链库房生产）、用户指定送达时间等原因，转移系统会控制订单生产的时机（如一周后送达订单则需要控制不要立刻下传库房）、生产的流程，生产的仓库。履约控制：履约控制系统负责控制订单生产的流程，将订单推送至对应的库房，并回传生产节点（拣货、复核、打包出库···）给前台系统；针对取消逆向订单，根据订单流转的不同节点做对应的控制：如订单未流转到仓库，则负责暂停订单下传，订单未出库则负责通知仓库终止生产、订单未派件则通知配送系统终止派件等。订单下传。订单经过拆分、转移、履约控制后，按时下传到对应的库房进行生产。以上就是电商全流程的介绍，全流程中的每个流程节点都是一个独立的、庞大的系统，本文只是介绍各个系统之间的流转关系和基本职责，详细的功能设计将在后续的系列文章中展开。

3.3 大型电商产品架构

我们通过电商业务流程得到了系统流程，有了系统流程就得到了电商系统的基本功能模块，我们基于上面梳理出来的基础功能模块，再从系统全局的角度进行扩展和做更细粒度的拆分，将最终拆分出的功能模块按照架构图的逻辑进行组织，就得到了一下产品架构图。（图片过大无法正常显示，请用电脑放大查看）这张架构图的组织逻辑比较简单（可结合架构图对比查看）。从上到下分别是：用户端系统>运营系统>履约系统>生产系统>基础平台>BI系。用户端系统：主要负责用户选购商品的需求，核心系统包括注册/登录、黄金流程和个人中心等；用户端系统属于前台系统，在产品设计上更注重用户体验、数据分析等。运营系统：主要承载了内部运营的能力，核心系统包括用户管理、商品管理、价格管理以及营销管理等。交易履约系统：交易履约系统是一个中枢系统，向上承载订单交易，向下控制生产履约，核心系统有订单中心和寻源履约中心，属于电商系统中比较黑盒的部分，界面较少，更多的是底层逻辑。供应链与生产系统：供应链系统即进销存系统，在很多企业中统称ERP，主要负责商品的采购、库存的管理等、仓储管理（WMS）以及运输管理（TMS）。基础平台：基础平台是业务系统之外的系统，主要包括员工账号管理、主数据、财务系统、商家管理系统、以及服务市场和开放平台等。BI系统：平行于电商的其他系统，采集各个系统产生的数据，加工处理后反哺其他系统，提供各类数据分析能力。如果将电商系统比作一个大型超市。

• 用户端系统就是可以看见的超市本身，首页就是超市的入口，搜索就是导购牌，列表就是货架，购物车就是购物车，提单就是出口收银台，用户端系统负责承载消费者的选购下单需求；
• 运营系统就是超市的营销导购人员，负责引导消费者购物、负责制定商品价格、发布促销活动，CMS系统就是超市的DM单、易拉宝，运营系统向上支撑各渠道、各终端的销售需求，向下对接订单系统和交易履约系统；
• 交易履约系统就是超市的调度员，对消费者的订单负责，当超市缺货时，及时从附近仓库调货，或者向工厂订货，保证消费者的订单能按时履约；
• 供应链与生产系统就是超市的幕后工作者，包括采购员、库管、配送员等。

小结

• 一个完整的自营电商业务有4个核心板块：采购、销售、仓储、配送；
• 基于电商产品均服务实体业务的特性，根据业务流程可以梳理出每个环节对应所需的系统或功能，将这些功能按照业务流程串联起来就能得到完整的系统流程图；
• 将系统功能拆分成尽可能细的粒度，再按照一定的组织逻辑就能得到最终的架构图。

就像前文说的，上述的每一个模块都是一个独立的、庞大的系统，在一个成熟的电商公司中，每一个系统往往都有一个或多个产品经理专门负责这个系统的设计、迭代和优化。本文主要介绍了电商系统的基础的功能模块以及每个模块的职责，通过三张大图展示了电商的全景，这三张图是对电商业务以及系统的归纳总结。本文并非具体的设计方案，只是让初学者对电商有一个初步的认识，至于更为具体的设计思路以及方案，将在后续的文章中展开。电商发展至今已经成为一个相对成熟的领域，很多系统和功能都能在网上找到对应的设计方案，可能只是行业、业务体量或者方向上有所差别。建议初学者在设计电商的核心系统时，不要凭借主观感觉盲目设计，应深入调研已有的成熟方案，避免踩坑。

4 举例2、详解B2C电商支付中心的产品架构

说到底，支付中心的原子能力就是收、退、打，其他所有的一切，几乎都是围绕这几个基础能力搭建出来的应用产品。支付中心对内的上游主要是业务订单系统（本文主要描述经典场景），订单会传入支付结算所需要的核心信息，支付中心接收后转化为系统内的收退打相关指令，并进行信息的回执；支付中心对外是跟三方支付公司/银行系统进行互动，支付中心将平台的收退打指令转为三方真实资金的收退打指令，三方产生信息回执；而支付中心内部，主要包含收单系统与清结算系统。前者主要负责收款，后者主要负责退款与打款。一图一文，以下这张图片就是本篇文章描述的核心：简单描述此图的结构：最上边的订单系统，就是触发指令给支付中心的上游，一般就是公司的各个业务订单系统；橙色背景区域内，就是支付中心的内部系统模块组成；左侧的模块，是三方支付机构内部的大概逻辑（不再引入银行，主要为了描述支付中心对外的资金信息交互）；粗的线条，表示比较大的系统模块或实体之间的交互逻辑；细的线条，表示系统模块内的指令与模块之间的交互逻辑；箭头指向只是表明大逻辑上有关联或顺序，但仅限于宏观层面，不开展到非常细节的产品设计层次；接下来，我们从【收单】【清结算】【账户】【对账】【交易安全】5个部分来展开：

• 收单系统

收单系统的主要职责就是收款，对业务要保证下单支付转化率，对系统要保证安全稳定、精准无误；

1. 订单调用支付中心：

上游创建订单后，会发起付款请求，比较常见的就是：

2. 普通支付（原子层：父订单：支付单=1：1，子订单逻辑订单体系内处理）
3. 合单支付（原子层，订单：支付单=N：N，支付中心还有一个父支付单与N支付单进行同步）
4. 补差支付（原子层，订单：支付单=N：N，支付中心根据N个原始支付单合并一个总支付单与订单进行同步）

我们就拿比较经典的普通支付来说明，订单创建后，获取到业务、用户和商品相关信息，然后创建支付单实体，支付单包含了支付收单所必须的上游信息。

5. 支付单与收银台

支付单创建之后，上游订单维持“待支付”状态，用户可以在限定时间内发起支付行为，即吊起收银台。这里注意，收银台本质上就是收款通道的整体逻辑控制，不同终端、不同业务可选择支付通道的不同，例如：微信内是不可能用竞品支付方式的、有的业务坏账率高无法使用分期产品、信用卡手续费谁承担、哪个收款通道默认选中/展示排序等等。这些本质上就是结合业务不同情况，为支付转化率和交易安全作保障。收银台支付通道也分以下几种常见类型：

6. 当前主流电商基本都是三方支付，如微信、支付宝、京东支付，也有部分银行支付，还有花呗、白条等消费分期通道
7. 另外，部分平台也提供平台账户余额支付，即钱包业务
8. 还有一些会把不同支付通道进行组合，如分期与非分期支付组合，方便额度不够或想减少消费分期额的用户。
9. 收银台调用三方支付系统

当用户选择某种特定支付通道之后，收银台就会用sdk或内嵌M页吊起支付通道，用户放弃某个通道之后，大部分场景可以更换其他支付通道继续支付。在三方支付的体系内，在使用余额或绑卡支付成功后，真实资金会从用户在三方的用户账户余额转往平台在三方的商户账户余额（有账期的暂不展开）；同时，三方告诉平台的支付中心用户已完成付款，平台的支付单可以变更已付款状态，并回执给订单变更订单状态。

• 清结算系统

清结算系统分为清分系统、结算系统组成。

1. 清分系统

清分系统职责：处理上游业务单的分账请求，并转换成为标准的清分记录，进而在业务结算时机调用结算系统产生结算记录；一条清分记录，会被拆分为N条结算记录。清分记录可以理解为业务一笔订单的完整分账信息，可能包含很多目标账户，结算的时机也可能不同，经过清分系统之后，会转化为一条条格式化的结算原始记录，主要是出资账户和单个目标账户、结算金额、结算时间等核心信息；

2. 结算系统

结算系统职责：将清分系统产生的结算记录，按照账期产生结算单，进而按照商户系统合同打款信息进行转账打款操作（包含欠款扣款逻辑）；结算系统，将待结算的结算记录按照结算周期和结算对象，分别进行合并运算，生成结算单（如果是负值结算单可能涉及到滚动生成结算单）。结算记录：结算单=N：1。结算单如果是正值，则生成打款单/提现单，然后将钱款进行打出，也有可能是多批次打出。结算单：打款单=1：N；商户会按照结算单与自己在平台经营的订单信息进行对账，看是否有误差，以及关注结算单的打款进度。

3. 账户系统

账户基础原子能力有：充、提、冻、转（支付、转账、扣罚）。支付单、结算单/提现单、冻结/解冻、转账等都会产生账户流水。账户分类一般分为3大类：平台类账户、用户类账户、映射账户。

4. 平台类账户根据不同财务用途会划分很多种，例如代收代付、预收、应收、成本、资金等等。
5. 用户类账户，体现在用户端就是余额钱包的场景，可以充值、提现、冻结等操作。
6. 映射类账户，主要用来映射平台在三方的资金情况，便于平台实时了解平台的各渠道资金情况，便于调拨等用途；
7. 对账系统

标准的对账系统，大概分为以下4种对账：账证：业务层-账务层，即业务订单与支付中心账务进行对账；账账：账务层-会计层，总账与总账、明细账、日记账、明细账之间相互核对的过程；账实：内部-外部，即支付中心与三方及银行进行对账；账表：会计报表-会计科目，跟本系统层面关联较弱。

8. 支付安全

支付中心的天职就是为平台交易安全提供保证。不仅要关注交易的双方角色，还要核心关注钱款的流向，尤其是收、打这2个节点。第一方面，支付中心包保证合规、合法。首先支付中心设计要满足监管部门的要求，同时还要结合业务上游和支付中心联动，积极反诈骗、洗钱、信用卡套现等违规违法行为。第二方面，要做到系统健壮。从系统设计、系统实施、系统运营，都需要非常严谨，兜底也要建立完备的预警机制、熔断机制，为公司业务上游提供安全可信赖的支付服务。本文聚焦在支付中心的框架内，比较宏观介绍了部分系统的定义和职责，另外有些模块也都还在探索摸索阶段，并非标准答案。支付中心系统底层设计比较固定，最关键是能够结合企业自己的业务做好对应的架构设计和运行支撑。跟着业务变化而迭代系统，这样才能做出一个有灵魂的支付中心。

5 举例3、京东零售营销选品平台架构设计

随着互联网业的发展和用户购物习惯的转变，电商在零售市场中的占比逐年增加，市场的扩大也带来了各个电商平台中商品的数量在近十年里快速上涨，以京东零售为例，现在全站的商品规模已经达到数十亿级。如此大的商品量，在带来了更丰富的商品的同时，也给日常电商的运营工作增加了更大的难度。其中很核心的难点之一就是，如何从这些海量的商品中找出优质的、符合运营诉求的商品。基于这样的痛点，各大零售平台都在近几年推出了各自的选品工具或者平台，本人所在团队有幸参与到了京东零售营销端的选品平台从零到一的规划、设计、落地，并在2022年618大促活动中覆盖了50%的促销活动楼层商品的选品职责。本文将分享从2021年Q3到2022年618这一年时间里平台开发过程中团队所积累的一些相关的技术经验，希望对业内同学有所帮助。

5.1 选品核心能力拆解

从上一节的背景中，我们可以看出一个选品系统最核心的功能是能帮助运营从较大规模的数据中选出目标数据，这是我们进行系统设计最核心的关键点。所以这里设计的关键问题就可以转化为如何能实现从较大规模的数据中选出目标数据。关键问题清晰之后，我们其实可以看出，这是一个数据检索服务。当我们把问题转化成实现一个数据检索服务的时候，很多设计思路就清晰了起来。检索服务对于每个人来说都不是一个陌生的功能，我们在日常工作设计甚至生活中都经常接触这样的功能，比如日常工作中筛选excel表格中的数据，或者我们日常在百度、谷歌上使用的搜索功能，其实都是数据的检索服务。基于此，我们把各种检索服务进行横向对比分析，可以得到我们认为如果要设计一个选品系统最重要的三大核心要素：数据、筛选和排序。为了让大家更容易理解这三个核心要素，我们基于三要素把日常经常接触的工具进行横向比较，如下表：

5.2 京东零售选品业务情况

乔布斯曾经在一次发布会上回答了一位工程师质疑他是否懂技术的问题，他回答大意是：我们应该为了一个好产品去找到适合它的技术，而不是为了推广技术而去设计一个产品。同样的，为了更合理的设计好我们的选品平台，我们也需要在前期深入的去了解业务的具体使用场景和相关的技术情况。经过我们对业务的调研，大体总结出几个核心的业务使用情况：

1. 不同的选品业务会使用不同的数据，数据范围从百万到亿级不等，使用到的指标也不一样。
2. 京东零售业务比较复杂，平台需要支持的业务会比较多。
3. 数据选品需要实时得到结果，结果包括数据的列表和数据的一些分布。

针对上述的业务使用信息，我们可以得到系统需要满足：

4. 支持较大数据量的实时查询。
5. 选品数据多样性高，需要针对不同业务进行灵活调整。
6. 需要同时支持OLTP和OLAP查询。

5.3 选品领域模型设计

针对上一节的业务使用诉求，我们首先设计了一套选品平台的领域模型，主要包含输入和输出两大部分，输入域包含我们选品的核心三要素：数据、筛选和排序；输出域偏向业务功能的使用诉求，主要包含视图能力和数据输出能力。模型设计如下图：

5.4 选品系统架构

确定了选品平台的领域能力模型后，我们继续进行系统架构的设计拆解，由于我们平台的定位是服务整个京东零售营销的选品场景，业务场景较多且区别较大，于是在系统设计上如何通过一套底层能力支撑多变的前台使用是我们在设计平台架构的时候重点需要思考的问题。下面介绍一下团队针对选品从前端到服务端各个环节的系统架构。

（1）前端

前端是最直接面向用户的一层服务，这里需要先考虑到合适的用户体验，经过一段时间的打磨，最终我们选品操作工作台的交互功能设计了三大核心工作区域：筛选规则配置区、排序配置规则区和展示区（商品列表和商品分布），如下图：在技术实现方面，为了保证我们整个前端工作区域的适配性和多样性，我们把工作台各个区域的渲染都通过配置化的方式实现，整个配置化组件底层协议基于Json schema，渲染基于京东零售的水滴组件（已开源，水滴表单组件 https://github.com/JDFED/drip-form，水滴表格组件 https://github.com/JDFED/drip-table）。这一套设计保证了我们**可以通过配置快速搭建各个基于同一底层的不同的前端选品样式，具备优秀的灵活性和可适配性**。架构图如下：

（2）服务端

服务端方面，首先是应用层设计，这里最重要的是联动配置化的前端协议来实现后台的服务。考虑到选品本质是上把前端用户交互翻译成数据Query的过程，所以这里对于服务端的应用层最核心的就是两部分功能：协议字典、Query解析引擎。其中协议字典主要作用在于和前段的配置协议进行映射翻译，翻译成一些逻辑语言，比如大于、小于、等于等。Query解析引擎作用是把逻辑性语言通过动态Query的方式生成Query语句。如下图：在应用层之外，选品服务端的数据层也是非常重要的部分，在存储介质方面，考虑到选品用户需要检索商品以及查看商品分布，技术选型上我们首选ClickHouse。ClickHouse在OLAP查询方面以及数据写入、数据查询性能方面都有很好的表现。另外，选品数据处理涉及大数据海量数据的前置处理，这里我们主要使用离线大数据计算的方式进行处理（HIVE SQL或者Spark）。在离线数据处理方面，我们主要进行了标准化设计，沉淀了一套通用的数据脚本，把所有数据处理过程都抽象成一套标准的数据处理流程（1. 底池初始化，2. 指标添加，3. 离线导数，4. 数据清理），这样可以保证各个环节可以用通用的数据处理脚本，不同业务处理数据只需要传入不同的配置参数即可。如下图：最后，在应用层和数据层之外，我们也设计了质量监控体系，包括服务链路监控、定时巡检、降级限流、异常数据处理等，来保证整个选品系统的健壮性和内部流程的可观测性。最后是整个的架构图，如下：通过这一套系统架构，我们实现了选品平台的统一底层、灵活配置化的前端，一键部署多端适配的系统特性。

5.5 选品数据索引架构

除了上一章节介绍的平台工程架构以外，数据也是选品平台极其核心的部分，这里数据包含数据的生产传输和数据的检索查询。考虑到数据的量级（亿级），传统的单点数据库支持不太适用，我们选择的方向是分布式数据库或者数据引擎，考虑到这里对于查询有明确的聚合查询场景（查看分布等OLAP性质查询），我们综合下来选择了现在社区比较活跃并且成熟度也较高的ClickHouse所谓数据索引引擎。在索引结构设计上，我们也可以从查询由近到远的视角拆解来看。首先第一部分是离查询最近的索引，这里索引最核心的指标是提供尽量快的查询性能，考虑到一个选品查询的过程本质上是条件查询的过程，所以这里我们设计上针对不同的选品垂直业务场景，把商品主键和业务指标合并成一个宽表的形式，这样查询可以直接命中单表结构，不需要额外的实时关联数据操作（比如多表join），在性能上是最优的。结构如下：这里的结构是比较简单明了的，但是我们也要认识到底层的数据结构其实是很多样的，所以如何能保证把多样性的底层数据可以标准化的处理成我们需要的结构是整个数据处理流程中最重要的设计点。针对这块设计，按照数据的实时性要求，我们可以拆分成两大类数据处理流程：离线数据（实时性要求不高，可以容忍小时级或者天级数据延迟）和实时数据（实时性要求高，基本需要准实时）处理流程。首先看离线数据处理流程，这里的设计思路比较明确，只需要通过离线数据处理脚本把多样的底层数据处理成需要的格式。这里最大的挑战在于当数据量很大的时候如何可以较快的导入到索引库里，这里主要通过一些脚本的优化，比如通过自定义Hash函数把数据进行分区，再各个分区数据直连索引库分片的方式进行数据写入。接着看实时数据处理流程，对于分布式大数据量，实时数据处理流程的复杂度是高于离线数据处理流程的。实时数据处理的难点主要在于大量数据如何按照我们的标准格式快速接入到查询索引里。为了达成这个系统设计目标，我们参考了业内很多的分布式数据库设计思路，把实时数据处理流程分成两阶段，写入阶段和合并数据阶段。其中写入阶段目标是把数据能够较快的落库，考虑最核心的是性能，所以我们采用的方案主要是按照原数据流格式直接不做复杂逻辑处理就进行直接入库，整个数据的格式比较灵活。合并数据阶段目标是把数据处理成目标格式，所以这里的服务处理可以做一定的定制处理，来把多样格式的数据处理成统一的目标格式。通过这样一套底层索引的架构设计，我们通过宽表的查询索引表结构保证了选品实时查询的效率，通过实时和离线双路流程保证了数据的同步传输效率。下图为整体架构图：

5.6 结语

京东零售选品平台初版上线于2021年Q3，整个平台的架构设计，包含了系统工程和数据处理两大方面的研发知识体系，对于团队和我个人是一个挑战和机遇。通过这次平台的落地过程，团队完成了很多成绩也踩过很多坑，相对于完成的成绩，我们更感谢这些出现过的问题和踩过的坑，因为团队正是从这一个一个的困难问题中得到了历练，不管从技术深度还是广度上都提升了很多。最后，提业内的一句名言：“软件开发没有银弹”，我们分享的平台架构设计是基于京东零售营销体系的业务使用场景的，这也是我为什么在前三章节用比较多的篇幅来介绍业务，这套架构是否适用于其他场景需要各位读者自行分析体会，当然我们设计中肯定依然有很多不足，我们团队内部也在持续的迭代优化系统，这里也欢迎各位读者可以留言来提供宝贵的意见。参考文献：

7. 产品经理|如何学习产品架构能力https://www.woshipm.com/pd/5794522.html
8. 在失败中，聊一下产品架构设计https://www.woshipm.com/pd/5747673.html
9. 产品架构设计9字心法https://www.woshipm.com/pd/5787210.html
10. 产品架构图绘制心法https://www.woshipm.com/pd/5390178.html
11. 纵横梳理术https://www.woshipm.com/pd/5369604.html
12. 一文读懂电商产品架构https://www.woshipm.com/pd/5319981.html
13. 说说电商小程序用户增长的产品架构https://www.woshipm.com/operate/4979147.html
14. 详解B2C电商支付中心的产品架构https://www.woshipm.com/pd/3484003.html
15. 京东零售营销选品平台架构设计https://mp.weixin.qq.com/s/kYbnoMMx2uFbU2PyDxIDGw
16. 关于产品架构设计方法与核心设计原则，你需要知道这些https://www.woshipm.com/pd/4253088.html