严选品牌视角下的2B架构实践

本文从严选品牌的视角分享2B系统架构设计上的一些挑战和实践，希望在2B领域的一些架构思考和方法论能够引起更多的探讨和共鸣。本文内容涉及供应链、物流、商品、客售等相关系统的一些案例。

1. 写在前面

从17年入职严选以来，我的大部分时间和经历都聚焦在供应链、物流、客服售后、商品研发等后端业务链路，踩过很多坑也有一些自己的思考，所以想写一篇文章总结一下自己在2B链路下一些所见所思所感所得。

后文我将从严选的业务和系统特点、2B系统的通用特点两方面引出我们系统建设所面临的核心挑战以及我们基于此的应对之策。

2. 严选2B系统的特点和挑战

“以终为始”这个词特别好，代表着一种价值导向的价值观，对于技术团队、对于架构师同样如此，而我们的“终”在哪里，我想一定是业务。

2.1 严选业务特点

严选15年成立，经过多年的发展和淬炼，目前已经在品牌加全渠道的战略下越走越坚定。品牌和全渠道两大核心战略必然让我们的业务打法和淘宝、京东这样的平台电商有很大差异，对于2B链路，以我个人的理解大概有这么三个核心的特点（核心以2B关注的为主）：

• 品牌模式决定严选不可能像传统电商大规模自建仓储物流等业务基础设施 ；
• 爆品驱动背景下核心品类的业务运作精细化要求不同于电商更注重大盘最优的运作方式；
• 从供应商到用户横跨供给、履约、销售的完整生意链路运作的多样性大于单纯围绕售卖场的流量运营；

这三点决定我们的产品系统在向外集成、行业差异化、复杂链路支撑性上面临巨大挑战。

2.2 2B系统通用特点和挑战

在说严选2B产品之前，我想先站在更宽泛的视角说一说我对2B业务和系统架构的一些粗浅理解。

我们通常在聊一个产品系统设计的时候，最关心的三个要素一般是用户（角色）、场景、功能这三个要素，下面也会结合这三个维度聊聊我对2B架构一些通用特点的理解：

• 用户和角色不同：2C的终端用户相对固定，2B用户呈现出用户类型多，用户角色更多的特点，使得对于围绕用户的系统交互、权限、规则等呈现出更多样、更精细的诉求。
  通常2C产品，我们很少讨论用户角色，因为通常我们的身份就是终端用户，而对于2B，一个公司组织下的不同部门、不同个人使用产品系统处理工作的职责都不尽相同，一个组织一个部门就是一个大的角色，一个部门下又有很多小的角色，比如：供应链团队下有计划、采购、品控、仓储等等大的职能，品控职能下还有QA、SQE、QC、合规等等小的职能角色，再细化甚至还有不少的小角色，同一个人甚至又分饰不同角色，这么多的角色配合才完成了整个严选从供应商到用户的端到端的流程协作，这么一个复杂的流程势必在多角色的交互、协同，功能和和数据的权限控制上都有着差异化的协作和管理诉求；
  所以：
• 如何支持不同用户、不同角色在不同场景下差异化的管理和权限诉求；
• 如何更好地完成多角色间的系统联动体验；
• 如何更好地满足不同角色特定行业特定场景下的精细化诉求；
都是我们不得不面对的问题。
• 业务场景和功能：呈现出长链路、长周期、业务模式多样的特点，整体业务的组织、流程和规则复杂度高，使得对于系统的全生命周期监管、一致性的协同体验、架构层面的流程、规则、领域抽象有较高要求。
  举个商城的例子，在2C的环节我们直接能够看到商品、购买商品、产生交易、收到快递就完成了一个简单地商业交易行为，但是与之对应的是一条从供应商到用户手上横跨商品研发、生产、物流、仓储、配送的复杂生产履约链路。
  这个过程涉及到计划下单、生产排期、预约入库、到货履约、仓库存储、物流下单、拣货、打包、出库、配送等等数十个大节点，光是一个拣货又有这波次、拣选、分拨等等很多细分的业务操作环节；流程长、业务场景多：
• 任何一个环节出现问题都会影响最终的流程成功；
• 任何环节的协同中断都会导致最终流程效率；
• 任何业务的变化都可能影响到全链路的产品系统功能，最终影响研发效率。
所以如何更好的监控全链路异常和时效、如何更高效和顺滑地支撑各业务角色的全链路协同、如何更好地在架构维度做好抽象设计以保证研发效率和架构的可维护性都是2B系统面临的通用性挑战。
• 应用架构方面：不同于2C聚焦单个用户的数据生产、加工、处理，2B系统有着大量全局性的数据处理、决策、分析场景，批量性的数据操作使得架构层面面临脉冲式的稳定性压力。
  2C场景，我们最经常提的挑战戏称为 “三高”（高并发、高性能、高可用），比如 淘宝2020年大促的接单峰值有30w+的TPS，拆解到下游库存、商品这样的链路还会继续放大，这样的情况下随便一个慢sql、网络抖动都可能会引起系统异常甚至是雪崩，最终影响大批量用户体验 ，所以系统如何更容错、更隔离、性能更丝滑是核心的挑战；
  而对于2B场景，我们系统的峰值TPS别说“万”级别，想有个千级别、百级别甚至都是极少数的场景，所以同样的系统问题在2B场景上的用户影响要小得多，但是2B链路通常涉及管理、分析、数据处理的场景，比如仓储的拣货要根据大量的物流订单生成整体效率最优的拣选单，这种场景通常单次操作就涉及到上万级数据的分析处理，数据处理的准确性、实效性都会影响最终的拣货路径和作业效率，同时会造成大量的机器成本开销， 比如长时间的生成不了拣货任务可能会造成整个仓库的作业停滞，影响仓库生产，这对于2B来说都是非常致命的问题。
  所以，对于2B如何处理好批量性的重型操作是整个应用架构在稳定性上的一个核心挑战。

3. 严选在2B架构的一些解法

在上一段，讨论了严选B端的业务和系统通用特点对于严选在2B体系的系统架构建设带来的一些要求和挑战，本段会挑选其中一些比较有代表的点讨论一我们的一些解法：

3.1 物流体系通过3PL服务商集成结合自研数据中枢平衡成本和履约能力（向外集成）

前文提到严选作为新消费品牌，核心价值在于品牌力的打造而不是比拼极致的物流效能，这也是目前大多数品牌和中腰部平台的必然选择。

而对于3PL模式的物流系统，我认为最重要的三件事：

• 做好整个物流的调度分配；
• 最大化服务商信息流和严选信息流的一致程度；
• 对于履约过程中异常的快速响应。

为此，在架构上我们做了几件事比较重要的事情：

3.1.1 通过云端一体化的架构提供面向仓内生产环境的面单服务能力

通过仓内本地端插件+云端兜底的架构方式提供低延迟的面单服务能力，同时云端负责逻辑兜底和整个的面单规则、模板、上行下发的管理收口，实现一套逻辑“云”“端”共享。

通过这种模式，提供了和仓储服务商在满足生产作业要求下的系统集成解决方案。

当然，我们云+端的架构不仅服务于面单场景，还有收货、退签等等本地化生产要求比较高的场景。

3.1.2 通过决策中枢IPC的建设整个物流的调度分配

对于3PL集成型的架构，执行链路一般交给3PL物流服务商来完成，但最关键的是整个物流决策调度的管理逻辑一定要自研，因为这是整个的履约成本、时效、用户体验的关键抓手；我们通过：

• 抽象履约决策过程的关键因素（订单结构、库存情况、仓租、服务商质量等），将整个决策因子规则化，形成面向业务闭环的策略配置中心；
• 通过沙盘仿真的方式提供策略配置调整的模拟环境，让业务决策更有信心。

3.1.3 通过纵贯线+异常中心 从异常监控、触发、协同、处理抽象和沉淀整个异常处理标准形成技术组件

对于外部协同一个特别重要的问题是业务运作的异常监控以及后续协同，并且对于整个的3PL履约链路，这是通用诉求；

为此，我们通过构建业务流程生命周期监控的数据基建 “纵贯线”（下文会有进一步解读） ，业务协同基建协同中心，形成基于数据监控到问题协同的线上化基础能力；

这其中关键点我认为有三：

• 业务视角而不不是技术视角的监控能力：基于纵贯线，我们的核心是围绕业务单据串联起来的业务链路，这是天然的业务视角；
• 作为基建跨场景的复用率和研发效率；
• 作为数据产品能够面向场景要求满足不同实时性诉求。

3.2 基于模型、流程、规则抽象以应对复杂度

任何系统基本都是都能抽象成模型、流程和规则三要素，而由于业务和流程复杂度的要求，2B的系统需要做的更加极致；

3.2.1 找到关键模型

对于模型，我们基于业务建模的方式从原先烟囱式的系统模式逐步演进到领域驱动的中台化架构模式，这其中最关键的事情便是如何找到业务链路中那些影响业务的关键模型，好的模型抽象和建立等于成功了一半。

举个例子：我们原来的采购系统，光一个采购单上能承载上百个业务字段，到最后几乎大部分围绕采购的业务变化和新的诉求都会影响到采购单这个业务模型，以至于随便的一次变动就可能影已经运行多年的稳定业务，一次发布就可能影响上下游的多个服务，甚至都找不到一个同学能够说得清采购单每个字段的含义。

后面我们将采购单模型抽象成了面向审批的采购申请、面向执行过程的采购执行单将整个计划下单审批的过程和采购履约执行的过程分离解耦，很大程度上降低了采购领域模型的复杂度。

3.2.1 沉淀流程和规则

对于流程和规则，我们抽象出可复用的部分借助自研或开源的规则和流程引擎设施沉淀成业务流程的可复用基建。

比如我们对于2B很重要的流程生命周期的监控，我们抽象出单据 + 链路的模式，通过产品配置化的方式就可以对某个单据的生命周期的时效、异常等进行监控，比如 一个采购到货的链路，我们能够明确快速的知道采购单的履约情况，有没有什么卡点、采购金额是否有什么异常、哪些单子超时了等等；

下图为纵贯线的产品交互：

（图中数据非真实数据）  

再比如我们的数据权限，b端有很多场景，比如商品开发的同组同权的数据查看权限、采购审批权限等等，都不是简单的基于“功能”隔离能够完成，需要更细颗粒度的 数据+权限的维度，比如食品开发的同学只能看食品BU的商品数据，采购组长只能看自己小组同学审批的采购单；

这时一般有两种做法：

• 按照业务场景定制数据规则，比如商品可以根据对应商品开发同学过滤同组权限。
• 抽象出权限规则，通过数据+数据规则+数据权限的方式，权限绑定到数据规则，数据规则决定数据范围，这样做的好处是可以把相对频繁多变的数据权限和主数据的管理解耦，提供更灵活的数据权限配置能力。

两种方案没有绝对的好坏之分，根据实际的场景合理选择数据权限的架构方式是更重要的事情。

3.3 基于品类、行业、爆品的架构演进 以应对精细化和多样性诉求

严选本质上做的是品牌的生意，不同于平台型企业整个的产品技术体系建设都是以通用规则和流程支撑为主，我们更需要深耕在关键品类、行业、爆品上，让系统下钻的更深，更好的去满足行业特点和诉求，才能帮助严选在品牌上更具竞争力；

• 比如服配行业因为同一个SPU下的SKU宽度太大，考虑到资源和成本，我们通常的补货、备货都是只考虑到单款单色，很难基于SKU维度进行补货，所以我们为服配行业定制了基于色款（SKC）的补货模式；
• 比如我们在商品外包装设计平台 ，因为餐厨行业的供应商没有二次定制包装设计稿的能力，而后我们有调研发现这种场景的占比并不低，所以我们提供了基于外部供应商模板进行导入设计的系统能力。

TIPS：对于品牌属性的2B系统，我们团队觉得千行千面才是最终方向。

3.4 2B架构的可靠性实践

这里简单地对2B和2C在可靠性上的要求做了一些对比： 

基于此，对于2B我们一般有几种主流的解法：

• 全面异步化：从产品体验到架构内部协作，整个2B的场景应该基本都能够异步化。
• 事务任务化：以Event-driven的方式驱动事件解耦。
• 批量调度化：借助异步化和事件化的处理单元，将原先多个业务任务转化成一次批量处理，提升处理效率和系统资源利用率。

这一点，举一个我比较有感觉的例子，我们的履约决策中心会接受大量的物流订单，这时如果一单一单处理对于仓内的分拣效率、履约的成本控制都不是最优解，而通过续单将一段时间的订单统一调度一次，既能优化效率成本，也能减少机器开销，实际场景收益非常大。

4. 写在最后

上述更多的讨论了一些品牌背景下2B架构的特点和实践，不过更多还是从空间的维度再看一些架构的挑战和解法，其实还有一个非常重要的维度是时间，比如线上化的路径应该怎么布局，先解决哪些场景、哪些先做自动化、基建类的系统什么时候建设，这需要通盘考虑组织、业务和系统现状，后面有机会在其一篇文章聊聊时间维度的架构思考。

本文由作者授权严选技术团队发布