谢志强(无界)

商详中台的由来

商详，顾名思义，就是商品详情页，商品详情是海拍客各商场业务购物主流程必不可少的一环。每次新业务搭建一个新商城，都会需要搭建一个新的商品详情页面。商品详情页作为用户了解商品（基本信息、价格、图片等）及相关信息（促销、优惠、服务、评价、店铺信息、商品推荐）的主要页面，通过这些信息来确定加购或者下单，最终引导成交。为了能够引导用户更多成交，各个业务都希望在商详添加业务价值信息在商详情露出，业务需求改动比较频繁；作为下单的核心链路，商品详情页需要保证高可用，确保不会中断用户下单。在稳定和高效的双重压力下下，急需对目前的商详的业务和技术实现进行体系化的梳理，然后做思考架构的演进方向。

商详中台背景

商品详情页现状

每一次的要求都是越快越好，再加上没有对现有的模式做长期的规划。目前已经支持了6种业务的商品详情。分别部署在多个业务系统中。
详情的展示方式，只做到了从上向下的组件的布局，没有规划和规范，组件样式不统一，体验不一致

sku选择页面现状

sku的选择页面，也是展示模块很类似但又不完全相同的，存在和详情同样的问题，样式不统一，体验不一致
sku的选择逻辑、反选逻辑、默认展示逻辑这种通用的逻辑，是都要有规范，而不是现在各自需求去做，导致每一次sku开发，这里都是非常复杂而耗时的。

商详当前问题

综上所述：商详一直不是一个不断沉淀的模式。每次都是通过搭建一个新商详支持新业务，无法做到越做越快。
对于业务：

**客户：**多端样式不统一，使用成本高，体验差
业务：详情基本一致，新业务没法快速上线，新需求支持慢，验证有效的功能无法快速复制在其他的商详情。
**产品：不知道目前有多少个商品详情，**底层业务升级改动对商详的影响评估成本高，是否有影响都需要和技术沟通，效率低。

对于技术：

**可用性：**各业务流量聚合入口，业务不可用导致详情可用性无法保障，任何一个组件不可用影响这个详情稳定
**可维护性：**底层升级，每个详情都需要评估跟着升级；维护成本高
**不定性因素：**没有一个好的架构支撑，代码维护犯错成本低，可测性也比较低
**团队疲态：**疲于奔命，无沉淀，成就感差

如何落地？

思考点一：架构升级和业务需求之间优先级如何权衡

对于商详这类需求比较多的场景，没法做到1-2个月不支持业务需求，用独立的一段时间来支持架构升级。
方案一：前、后端、测试单独分一波人来支持架构升级 ➡️ 人员吃紧，没法分出一部分人来支持
方案二：做长期规划，每周投入20%的时间来一次架构迁移 ➡️ 周期长，新需求需要开放俩次，落地的成本太高
方案三（推荐）：技术提前介入，产出技术方案与成本分析，基于价值数据、成本数据、需求影响数据和pd沟通在接下来的那个需求一起支持，同时拉上产品和交互一起对现有产品做通用化沉淀。原业务支持的前端、后端、测试都是公用的，能能够节省一定的成本

架构优化协同流程：

思考点二：先边缘（简单）还是先核心（复杂）

** 先边缘后核心**：上线影响面低，能快速沉淀中台，不会引起大的故障；后续迁移核心场景，改动成本比较大同时可能会出现一些架构遗漏的点；当前边缘场景业务很难有大的改动。
先核心后边缘（本次选择）：上线影响面广，可能会引起大故障；支持核心功能架构可以考虑更全面，后续支持边缘场景改动成本低。
决策背后的原因：核心场景（app商详）刚好有大的需求点需要支持；app版本灰度有一周的时间，这段时间对于个别异常场景能够有时间进行bugfix；通过复杂场景提前搭建相对完善的架构，后续简单场景可以快速迁移。

架构设计

我们想要做一个咋样的中台

对于业务

a、【体验统一】确定商详展示标准规范，确保多业务、多端商详，都是统一交互+UI
本次产品和UI输出的组件，将按照标准规范落地。比如顶部页眉区域、详情图区域、标题区域等等。后续新业务都会按照这套标准往上套。换个颜色可以换，但是结构要调整，就需要大家一起去讨论一下有没有必要了
b、【业务高效】通过配置化、个性化开发，快速搭建新业务详情页面
本次产品和UI输出的组件，除过必选的组件外，其它的组件都要支持按照楼层，行维度，组件维度做可以支持添加组件、删除组件

对于技术

a、高内聚
业务内聚：商品业务从mall、mall2c剥离，沉淀详情独立应用detail
接口内聚：商详页的功能内聚到商详页和sku选择这俩个接口支持所有的业务场景、
b、高性能
商详做为各个业务数据的聚合，底层依赖非常的多的外部服务，针对性能这块需要有长期的架构支持，而不是越做越慢。
c、高可用
作为下单的核心链路，高级别故障的可能出现的模块，针对高可用需要有快速识别别和快速恢复机制，同时系统能够做一些异常的自动熔断

目标架构拆解

业务支持高效

组件化

组件化 -业务分析

通过对目前海拍客自有业务及对外部大厂的商品详情分析，整体商品详情都是通过一个一个的组件叠加起来最后的商品详情页面，不同业务相同组件的交互、样式基本一致，可以通过对每个组件做通用化，然后不同业务件可以通过搭积木的方式快速的搭建新业务的商品详情页面，同时每个组件可以快速的在各个业务的商品详情页面上投放，通过配置化的方式提升业务支持的效率。

组件化 -俩层架构
组件化对应系统的架构，按照俩层来架构来设计
**组件层：**核心是负责根据组件依赖的外部服务进行数据查询和组件自身模型数据的封装
**骨架层：**通过各个业务场景，路由出该场景商品详情页需要的组件，然后通过串|并行的方式执行各个组件，获取各个组件的数据，然后组装成商详渲染的最终数据。

组件化 - 组件设计

商品详情页大部分的组件都是通用的组件，整体的样式都是一致的，后端的代码都是一份的，但是也有一些组件，各个业务间差别比较大，这类的需要做好架构支撑，确保业务的个性化能够快速支持，且对其他的业务影响降到最低，比如按钮模块：

参考struts mvc模式搭建模块渲染引擎，不同业务个性化的功能通过各自个性化的 View 和 Controller 来支持。

系统高性能

并行执行组件

商详做为各个业务数据的聚合，底层依赖非常的多的外部服务，按照串行执行的方式，会导致整体商详的性能比较低，预计在300ms+，而且随着业务的快速发展，接口耗时会越来越长，用户体验比较差，商详需要支持并行执行的框架，通过并行执行降低系统RT，提升性能。商详各个模块件存在依赖关系，比如按钮依赖价格模块，各个模块的并行需要按照依赖顺序去执行，针对有依赖的场景，需要沉淀基于特定顺序的并行执行组件

APP商详页面包含如下组件，如果没有依赖关系，那就非常简单，每个组件单独线程并行执行即可。

2.但是真实情况下，组件间是有依赖关系的，不能直接丢线程池，需要按照指定的顺序执行

3.组件执行顺序编排算法

基于om.google.common.graph.MutableGraph 支持

系统高可用

**1.串并行切换：**并行执行组件，核心是用空间换时间，但是流量暴涨可能自身应用或者会导致下游应用cpu吃紧，支持并行和串行手动切换
2.组件超时熔断：当模块因为依赖的外部服务抖动，处理RT非常高，会导致商详情接口超时，影响商详可用性，针对此场景，骨架支持组件超时自动剔除，从而确保商详页能够正常渲染，不阻断用户下单核心流程
3.组件动态插拔：当模块依赖的外部服务不可用，可以在骨架配置页面剔除异常组件，待外部服务恢复可用后在添加对应的组件
4.外部服务降级：组件依赖多个外部服务，但是其中一个外部服务异常，这块影响部分数据的展示（比如价格模块的销量数据），针对此场景可以通过外部服务降级（按照mock数据返回）来对非核心的功能进行降级。
5.日常稳定性保障：

商详中台-2020版本 -V1

基于组件化的方式商详搭建商详页渲染引擎

商详中台-2021版本 -V2

搭建各业务商详情配置化功能落地，新业务商详可以通过配置化，存量的商详场迁移到中台服务。

商详中台