背景
带货作为近年来一种新兴、高效的营销形式，在商业侧最早以耦合在必选和邀约广告的业务形态中存在，直到22年中开始作为明确的业务探索方向。从初步确定带货业务的基本定位，到短短的一年多时间，业务极速发展，无论是带货up数还是带货收益以及平台收益层面，均有较快的增长，到目前已形成初具规模的业务体量。期间对于技术侧而言，面对相当多的困难，特别是在几乎无任何基础无独立系统的历史状况下，如何构建高效稳定的平台体系去支撑带货业务的快速迭代和发展需求，存在极大的挑战。
现状与问题
业务场景
带货属于典型的人货场型业务，对于B站而言，其场景相对较多且交互复杂，包含视频、图文、直播等十几种公私域不同场景。要实现从内容到种草的转化，构建用户交易心智和构建良性带货电商生态的目标，早期的系统完全无法支持。
图片
问题分析
早期的带货核心服务，均耦合在最早的商业互选业务中，仅存在最基本的带货流程，业务产品的需求支持几乎也只能串行对接。面对几乎负向的现存系统，多涉及最基础的需求开发，对于相对复杂的项目支持，难度较大，很难有效支撑。究其核心原因，在于业务领域不清晰，采用面向需求开发的方式，抱着能用即可的态度与目标，导致系统耦合严重，极其混乱，缺乏整体的方案设计。
在该状态下，面对带货业务突然的强势增长，产研形成了相对较大的矛盾冲突，开发效率低，业务支撑难，交付质量差，是当时几代解决的问题。如何彻底解决这些风险与挑战？从研发视角来看，需要考虑四个维度的综合平衡：基础建设、平台能力、统一标准、成本效率。基于业务目标与研发现状，全面梳理所有涉及带货的服务与接口后，我们提出平台化的整体解决方案。由当前技术债重的业务系统快速向平台化演进，从0到1进行带货业务体系平台化的全面建设。
平台架构
带货业务核心涉及到货端、人端以及应用场景端， 整个平台体系化的建设需要充分兼容通用场景，支撑好业务构建和关键能力建设，最重要的是从业务本身出发，需要回答几个关键问题：业务场景是什么？平台解决谁的问题？平台能力如何聚合，边界如何清晰定义？在全面分析带货业务域及业务目标基础上，从最初的烟囱式交叉服务，设计了如图方向的平台体系化架构。
图片
在该平台架构全景中，其本质需要解决带货业务体系中的几大核心问题和关键业务构建及业务能力
- 货从哪里来？由商品中台体系支撑
- 货要怎么带？由带货平台能力来支持
- 货要怎么管？由运营平台能力支撑
- 货该怎么出？由带货引擎/广告引擎联合支撑
- 人货场如何联动？由标准带货链路（人端/货端/数据端/算法）整体解决
针对这些核心问题，从系统分层、模型领域分解、标准化交互协议等层面，进行了带货平台技术架构的全面设计，整体方案如下图。如何在早期技术债较重的状态下，一步步从0-1推进带货业务体系平台化的建设，将在下文中逐一介绍。
图片
平台建设
确立了体系化的建设目标后，我们不再从单一的用户视角或需求视角去思考，而是结合平台化视角去看整体的带货业务体系。在业务的快速推进过程中，如何快速落地整体方案的核心模块，快速转化为生产力，尤为重要。在建设过程中，需要支撑现有业务的迭代，我们采取业务技术双驱动的方式，对带货领域模型进行分解，将人端、货端、流量端的核心能力进行抽象聚合，确立建设和决策四大核心方向的路径，主要包括商品中台、平台能力、交互模型、平台化治理等，核心解决平台的业务交付效率和系统质量等问题。
商品中台
在带货业务体系中，商品域是货端的核心域，货品作为业务源头，其重要性不言而喻。早期系统几乎缺失了商品层概念，只是通过简单API方式去调用开环渠道淘宝以及公司内闭环渠道（会员购、工房等）的商品服务，和带货主体、带货行为全部耦合在一起，就开发本身而言，每新增一种商品类型或接入一种商品渠道，整个流程均需要改动，风险高开发周期长，完全无法满足业务的期望，如何解决通用的货端能力成为急需解决的问题。
从业务本身出发，我们决定从0-1搭建商品中台，构建带货体系的货品供应中台服务能力，全面解决货从哪来以及货到哪里去的问题。该中台和传统意义的商品中台差别很大，非传统的货架概念。就B站而言，绝大部分货品来源于头部电商生态，另一部分主要是B站内部的电商商品，带货场景的货端中台不需要关注商品供应链层面，更需要关注的是渠道的复杂性与多样性及公司级商品服务能力。
图片
这里面有几个难点需要解决：如何快速高效接入货品渠道？怎样抽象并构建商品域底层模型？商品库零故障迁移及一致性如何保障？
渠道方案
货品渠道的快速接入对于直播带货、视频带货及广告带货等场景相当重要，通过对接不同电商渠道联盟及企业内部渠道，提供带货货源商品池。而在早期的链路中，接入每个渠道（如京东、淘宝等）均需定制化接入个性化处理，对接成本高，维护相对难，规则较混乱，货品校验缺失，脏数据易混淆，逻辑无分层，极其影响业务稳定及效率。因此接入生态媒体（京东、淘宝等）和接入内部电商商品（会员购、工房等）的通用化解决方案尤为重要，直接决定了在业务需求进展中的推进效率。基于此，在商品渠道的接入过程，我们提出了动态配置的货品渠道接入方案，整体架构如下所示。
图片
该方案将不同的货品渠道抽象成不同的供给端，按照数据流方式进行校验、加工、标准化存储。在实际工程实践中如下图，建立渠道工厂（factory）通过渠道配置组件（channelConfig）建立不同渠道源的商品数据连接行为，再经过校验器（validater）、转换装饰器（convertor）标准化商品数据，按照设计的实体模型完成商品库的存储。
图片
模型及存储
商品实体模型该如何设计，直接关系到商品中台读写服务的基础能力。早期的读写均采用es作为存储，问题很多，读写混乱，无法对业务事务进行回滚，拓展性几乎为零，维护成本也相对较高。核心原因就在于商品库的读写模型几乎是无约束式的增删，缺乏领域模型，为解决此问题，进行了全面的改造，以商品核心表、商品拓展表、商品应用表、商品货架表为核心模型承载，构建了商品库底层基本领域模型如下。
图片
从简单的商品属性线性关系存储方式到领域化的升级，最大的问题就是商品库的存储，一方面需要考虑存量异构，另一方面需要考虑数据一致性问题。首先，对于es的存量数据，进行底层模型的重构，写入mysql业务模型表，考虑到商品的搜索性能，通过订阅binlog构建商品索引库，提供商品读写分离的能力，如图所示。
图片
但这又带来了新的问题，在强一致性读的商品场景中，如在变更商品别名保存后，因为binlog消费的延时等原因，会导致用户体验不一致的问题。因此对于强一致性读直接读取mysql表，对实时要求不高的场景或搜索场景直接由索引库提供。另外mysql同步至es索引也有可能出现数据不一致，一方面通过retry和死信队列来异步保障写失败导致的不一致，另一方面通过引入对账机制进行小时级和天级对账补偿保障。而在实际过程中，实现了零故障的商品数据模型迁移。在整体改造后，实现了具备读写分离、事务控制、独立模型的拓展性高的商品库，成为整个商品中台的底层模型和稳定性存储。
平台能力
平台能力是平台化建设的重中之重，核心解决货怎么带的问题，负责支撑带货业务平台的所有核心能力，如自然带货、投流带货、直播带货所有服务应用及能力输出。早期的服务，和其他业务基本都是耦合在一起，仅提供了带货的基本链路，缺乏业务能力沉淀，特别是多个应用相互依赖，相当混乱，如图所示。这直接导致了很多问题和冲突，需求支持效率极低，开发上线风险很高，交付质量也难以符合业务预期，难以满足业务的快速发展。
图片
为彻底解决系统几乎为零的平台化能力，结合业务本身和发展的情况，就业务能力进行全面的聚合分析。首先从带货链路看，在保障了商品源头的供给，关键在于人货场的建立，即对up主、货品及场景的撮合，来解决人端、货端的联动，如下图业务的撮合途径和业务底层能力诉求。
图片
如何构建对应的平台能力去支撑人货的撮合？这是需要急待解决的重要问题。一方面从系统本身出发，对于历史债进行全面的模块化梳理，整合核心的业务能力和通用的基础服务，明确各系统应用的上下文边界。同时，对于带货系统核心应用建立统一的分层架构规范（包含client/service/common/starter）如下图核心业务层规范，彻底解决历史应用间调用混乱，相互依赖的问题。
图片
另一方面，从业务领域考虑，进一步抽象核心能力，建立带货平台底层模型，包括权限模型、投放模型、结算模型、pid模型，数据模型等，从投流带货、视频带货、直播带货、社区种草等场景，全面构建平台化投放带货能力，支撑复杂场景以及多用户不同形态的带货需求，如下图所示，从0-1逐步系统化建立的业务平台能力。
图片
交互模型
平台能力除了业务场景的支撑需要，更要考虑如何高效稳定支撑带货底层数据的交互。带货引擎，解决货怎么出的问题，支撑带货投放的索引构建能力及C端（评论/视频）广告检索端的服务交互能力，同时负责带货业务服务针对主站的透出。早期的带货引擎利用广告引擎建立了基本的链路，但和业务底层耦合严重，需要订阅大量的底层数据表，引擎的构建效率和业务整体支撑效率较差。交互模型链接了带货的关键通路，业务模型的解耦与重构，尤为重要。
一方面考虑到历史其他业务在稿件投放维度的交互方式，另一方面为后续图文投放带货标准化交互方式，因此，我们把稿件类（框下、浮层、弹幕）、图文类（评论、专栏、动态等）分别作为最基础的交互模型。但是，当各个资源位上的带货稿件发生变更时，稿件的带货属性也会发生动态变化，而这一变化引擎无法实时感知，就会出现非带货稿件的错误分发。有两种解决方案，要么是建立实时稿件属性API方式，要么构建带货属性实时交互表，前者直接提供C端的大流量实时请求，对于API的压力极大，同时需要时时聚合各资源位的实际情况，相对复杂，而后者则将实时信息通过db方式进行交互，交由索引构建后来感知稿件带货属性，可以较为灵活控制。因此，整体的带货底层形成了下图的标准交互模型。
图片
上文提到，构建带货属性实时交互表，需要对各资源位下的带货情况分别统计聚合。而带货场景相对复杂，我们通过带货识别层的引入，如下图，形成标准统一的带货属性底表供实时订阅，采用异步解耦，对于业务几乎零入侵。对于引擎索引的构建及业务效率均有显著的正向提升，另外对于下游的算法、数据等依赖方提供了统一的判断数据源，也完全解决了稿件带货动态的一致性问题。
图片
平台化治理
平台化建设的过程中，整个平台体系的稳定性和健康度尤为重要。早期系统线上服务质量较差，客诉相对较多，业务支撑的质量无法有效衡量，特别是系统存在大量无效的报警，系统的稳定性存在很大的挑战，这也直接导致业务项目需求的交付质量很难达预期，同时也需要投入额外的资源跟进，交付效率受到很大影响。面对复杂快速的业务发展节奏，整个平台体系的稳定性保障与风险治理成为当前业务较大的矛盾，如何有效推进平台化治理方向尤为关键。
存储稳定性
带货业务的存储早期相对混乱，历史债务极重。一方面核心投放模型表和其他多个商业业务共库共表，而这些单表已达近亿条记录，另一方面带货本身的业务表相对分散，部分散落在广告业务库。二者直接带来的影响较大，亿级表查询常常会超时，同时频繁读写，出现死锁的概率相对较高，对线上业务系统造成相当大的风险，因此我们将存储稳定性作为首要治理的方向。
面临两个问题：其一，部分表和广告业务库参杂在一起；其二，近亿级单表记录的多业务查询。问题一会受到广告库自身稳定性影响，一旦广告库链接打满，带货服务因散落在广告库的权限表、类目表等连接异常就会发生线上用户故障。首先进行db解耦，将广告库的数据预加载至缓存，每天reload一次，避免广告库的读故障问题，另外将权限、类目等领域统一，逐步迁移至带货主库，这样彻底节解耦了与广告库的历史关联问题，将该类问题直接降为零。最麻烦的是问题二，亿级核心表所涉业务相对较多，面临两个选择：要么直接迁走，要么保留现状。迁走将意味着上下游全部需要重新切换，涉及方极多，有限的资源和目标完成时间风险均太大，最后决定保留现状治理。在全面分析大表后，从增量和存量两个维度推进。增量层面结合最大的业务增量记录，发现部分历史业务在野蛮生长，而该业务已基本停滞，拉齐产运研决定下线，使得降低了近20%的增量。存量层面进行数据归档，我们按时间跨度分步推进归档。系列的治理核心表数据量，如下所示，整体降低了50%多，容量倍降，使得db的查询扫描记录整体降低50%，平均查询性能倍增，整个业务的服务体验得到较大提升。
图片
业务监控体系
平台的监控能力是最基本的要求，早期带货业务体系，尽管有一些监控报警，分布十分零散，大量无效的报警占比高达95%，基本可视为早期零监控状态。在业务体系的服务健康度和稳定性基本无从感知的现状下，提出了从0-1构建业务平台体系的监控和预警能力。
采用什么方案进行体系化建设成为最为关键的问题，在调研多种监控方案后，结合B站本身的一些公共基建能力以及技术业务目标诉求，我们决定不重复造轮子，选用了基于prometheus和grafana结合的数据监控解决方案，其中prometheus架构原理如下所示。这里面需要解决三件事情，通用埋点方式的建立，目标数据的采集和展示，指标定义和预警能力。
图片
通用埋点如何解决？我们自定义了一套通用的埋点标准sdk，通过AOP方式实现日志数据的统一生产。数据的采集部分，通过prometheus采集组件对sdk的日志、接口、请求等统一收集。过程中我们发现，采集存储到es的业务日志在数据量达到较高的状态，无法百分百采集，可能会造成重要业务日志的丢失，因此我们首先将es存储方式迁移至clickhouse存储，整体的迁移极大降低了es的存储成本，更重要的是保障了业务日志的全量性。展示维度指标结合业务的需要，主要对商品中台、服务调用、平台应用、异常日志、直播服务等核心模块确定监控指标，包含服务RT、服务qps、错误率、调用量等如下所示。
图片
图片
根据对应指标，有效的报警机制对业务端相当重要，否则会出现大量的无效报警，造成真正的问题被掩盖，起不到预警的作用。针对核心的服务，进行了分组并梯度划分，按照不同的业务属性如C端服务、B端服务、用户读写等不同场景，分别通过RT组别、API错误数以及NPE数三个核心纬度进行预警通知，如下规则所示。
图片
业务监控体系形成后，对于整体业务而言，有了系统体系化的健康指导，更重要的是提前发现了较多线上潜在的问题，为平台体系问题的提前发现和干预以及后续的优化方向提供了有力保障。
服务稳定性
平台体系的服务稳定性，更多的是服务层面在tp99及tp95线的表现。一方面需要有足够的qps承受性能，同时对服务的RT也有一定的要求。在监控体系构建后，观测到整体服务的超时异常并不少，严重影响了用户体验和系统稳定性。因此，针对该方向的治理，持续重点推进。
在对tp95线的超时现象进行统计分析后，主要集中在db慢查询以及缓存失效两个层面。慢查询在存储治理后得到了较大的改善，但是依然存在偶发现象。深究下来，业务多表join查询以及索引失效的情况下，在并发操作的一些场景出现频率明显升高。因此，我们将索引问题和join慢查询分别治理，对于前者，将所有大量复杂查询均重新添加联合索引，并不断测试索引的命中情况不断优化。对于后者，进行业务逻辑拆解，尽量保持单表索引查询。治理完成后，整体的慢查询问题得到相当大程度的解决，基本由原来每天多case几乎降至为零，查询性能平均提升3倍，如下图所示。
图片
缓存失效的现象，主要是因历史系统依赖的公共缓存集群内存不足，时常超过整体的95%。另外老集群因机器原因，无法扩容。更深入后，发现存在大量不合理的大key以及持久化的key，引起缓存滥用，致使内存饱和，影响到业务对缓存的依赖。从两个角度，针对大key删除和优化，针对持久化key增加合理的过期时间，最后统一迁移至新的带货缓存集群，整体的缓存容量从近乎95%的风险值降低到平均30%的健康状态。
图片
图片
特别在一些C端核心服务接口，通过db、缓存及服务本身的持续优化推进，tp95线超时率大大降低如下图，评论种草API 优化前后对比。同时，平台体系的服务稳定性显著倍增。
图片
决策平衡
在带货体系平台化建设推进过程中，因整体业务发展太快，近一年来，业务增量较大，无论是投流收入、带货gmv还是带货up的活跃情况均呈现出极大的增长趋势，如下图所示。
图片
面对极速的业务增势，在有限且紧张的人力情况下，通常情况下，决策的主要矛盾就凸显出来。一方面需要保障业务项目需求的快节奏推进达成业务目标，同时还需要投入额外的资源消化历史的技术债以及应对线上相当多的客诉问题，另一方面平台体系化的建设已刻不容缓，如果仅仅只是支撑需求而不全面规划并推进技术各层面能力建设，一段时间后将很可能没法支持业务的发展诉求。所以我们在实际的过程中，面对业务的超量需求，如何保障业务项目支撑同时去平衡技术方向的决策，成为技术侧较大的挑战。
从一开始我们就确定了多线推进的策略，大方向以业务目标保障为优先，技术优化并行。但如何并行？我们按照全局架构和局部改造的方式，分别决策了监控体系、商品中台、平台能力、服务治理等核心方向，先确定每个子方向的阶段性技术推进目标后，结合业务的节奏，寻找契机穿插并行推进。如直播选品融合业务项目同时启动商品中台商品域模型改造，如评论带货业务项目中并行启动了接口稳定性治理等技术项目。这样，在大的构架及整体技术方向上，结合更多的业务项目，客服资源和交付周期等因素影响，进行子模块和实际业务需求的抽象和统一，形成底层能力，并在技术层面0-1落地。
经过近一年来并行推近重点技术项目的建设，整体业务的支撑效率很好的实现了倍增，如渠道商品标准化接入专项的落地，业务的开发周期从早期的46人日降低至5人日，交付质量也显著大大提升，如线上问题case数从早期日均3个以上几乎降低至零。从早期几乎无法支撑的业务服务化开发状态，不断持续地平衡业务和技术双线推进决策，已经具备较好业务体系平台化的能力，整体的支撑效率及交付质量在一定程度上很好满足了阶段性的业务发展需求，但对于后续的业务体量和增速，仍然存在一定的挑战。
未来演进
带货体系平台化的建设，从历史债务严重的耦合性系统开始，结合带货业务生态体系，阶段性决策了平台加小中台的平台体系化建设方向，搭建并落地了整体的平台化架构。首先从0到1探索并构建了公司级商品中台，彻底解决货从哪里来的问题，为带货提供源头支撑。其次抽象业务模型，沉淀业务能力，建立了人货场的平台撮合能力，解决货怎么带的问题。接着在货怎么出的问题层面，一方便依赖带货引擎和广告引擎的通路，另一方面逐步建立底层交互模型的标准和统一，为自然流量和商业流量的出货问题建立稳定高效的交互机制。最后进行平台化的治理，以平台的稳定性为目标，0到1建立带货业务监控预警体系，同时全面治理业务存储和持续优化服务稳定性，为整个系统的质量和健康度提供了较大保障。尽管当前平台化已取得了较为显著的成果，但目前仅仅只是完成了从0到1这个阶段的建设，相对市场竞对，未来的演进之路依然漫长。如何从1到n？如何更好支撑未来百亿级gmv及高速增长的营收目标，还有相当大的困难与挑战，还有相当多的方向需要持续投入深入建设与探索。
- 业务网关、数据中心、业务能力如统一投放能力等目前还较薄弱，未来图文带货、数据参谋等较多的业务发展更需要逐步深入建设；
- 商品中台将会面对从百万级向千万级的演变，如何更高效的通用性接入和精选联盟等业务应用以及搜品推品能力的支撑，也将需要更可靠和更稳定的中台基础支撑；
- 业务中台化的领域模型演进与探索，以及底层业务交互模型以及开闭环归因领域也需有更高的要求和演进；
- 从1到n的系统稳定性建设也将持续思考和不断推进落地，加速拉齐在重要领域与行业竞对的差距，持续实现平台体系的高可用、高性能、可扩展等现存及潜在的诸多问题。
本期作者
周植宇哔哩哔哩资深开发工程师
