当前位置：首页 > news >正文

站点推广促销外卖平台如何做推广效果好

news 2026/4/29 11:52:37

站点推广促销,外卖平台如何做推广效果好,低代码app开发平台,一个app开发大概要多少钱业务背景平台主要售卖电子商品和少量特定的实物商品。经营模式#xff0c;主要分为平台商家和自营店#xff0c;自营店的流量占整个平台业务的50%以上#xff0c;我负责自营店交易履约相关业务。以前的架构#xff0c;平台交易和履约中心是所有流量共享#xff0c;在…业务背景平台主要售卖电子商品和少量特定的实物商品。经营模式主要分为平台商家和自营店自营店的流量占整个平台业务的50%以上我负责自营店交易履约相关业务。以前的架构平台交易和履约中心是所有流量共享在发品的时候可以针对产品的归属平台商家/自营店进行打标后续可以针对产品的归属进行流量染色和路由。下图以正向交易为例 PS下图简化了整个交易的核心链路其他域还有产品域、商品域、资源域、购物车域、出行人域、凭证域、商家域等很多强依赖以及弱依赖的相关域后文所提到的商品和产品在本文的语义可以理解为一样的实际上在平台业务定义上商品为C端所属商品有自己的特别属性比如零售价商品详情等产品为B端所属产品也有自己的特别属性比如供应商、结算价、成本价等这个“采购平台”历史悠久领域边界模糊代码和技术腐化严重对后续的业务支撑非常不友好。考虑到疫情结束业务前景向好于是在慎重决定下要在原有的平台架构上构建一套涵盖交易、履约、产品、资源、合约、直连、风控、计费结算等多个领域的全新供应链体系期望能在短暂时间内能够将原有的业务流量平滑迁移到新架构上并且新架构在未来能够友好的扩展新的业务模式显著提高平台收益。因为平台主要售卖电子商品几乎所有的商品走的都是线上履约方式所以交易和履约以及逆向业务都收敛到了我这里。关键词电商、供应链、交易履约、采购中心、订单中心、系统设计、技术方案、高并发、分布式工程难点时间 Question这个新架构是倒排需求第一版迭代周期只有三个月。在保证工程质量的情况下需要在三个月之内完成需求评审 - 技术方案评审 - 研发 - 自测 - 联调 - QA - 上线 - 切流并且能够完全承接旧系统的业务流量。 Answer敏捷开发、做好规划、风险把控、人力协调、视死如归、我是牛马。业务 Question旧系统的业务架构单一新架构的业务复杂多变未来预期很高所以在系统设计之初就需要具备一定的扩展性在领域设计时也要处理好领域边界和领域模型的建设。 Answer深学平台全链路业务广学行业内相关业务和解决方案向前辈求学问道无论如何先把东西学到手。技术 Question系统的流量和未来预期的流量很高每天增量的订单就有千万级别。新系统上线之后如何将旧系统的数据和流量平滑迁移至新系统面对复杂业务架构如何保证系统具备良好的业务扩展性面对复杂技术架构如何保证订单数据的一致性产品数据的一致性流量会集中在某一天或一天的某段时间如何保证系统的可用性和稳定性 Answer具备领域驱动知识、分布式解决方案、行业解决方案、高并发场景解决方案深入理解集团中间件。组织 Question平台侧的团队变动频繁一套平台工程经历了十几个团队业务逻辑不透明平台侧的研发同学新人居多接入很漫长心理压力大再加上组织架构的隔离性比较高平台侧的问题很难推动。 Answer提供足够的情绪价值、夸她、爱她、包容她交付进度阻塞必须风险上升一切以解决问题为主。业务演进之前的“采购平台”仅支持平台自营店新的架构希望能够扩展业务模式所以在原有的业务模式上给新架构设定了三个目标。目标核心打通供应链交易履约逆向链路完成流量的平滑迁移在原有的业务基础上具备横向纵向业务领域的扩展 a. 在原有类目的基础上能够自由扩展更多的业务类目 b. 在原有销售模式的基础上能够扩展更多的销售模式直销、分销、代理等 c. 在原有业务模式的基础上能够扩展更多的业务模式秒杀、二次预约、囤货、预售等 d. 在原有支付体系的基础上打造域内的资金池等体系预付款、授信等能够支持线上计费结算完全替代线下手工对账体系演进阶段在初步设定好新架构的目标之后规划了一下业务演进的方向大致分为了 3 个阶段。第一个阶段构建高可用、高扩展的技术架构并支持单业务类目单销售单支付模式完成上线切流。第二个阶段持续建设系统的稳定性并支持单业务类目多销售模式单支付模式。第三个阶段针对核心业务进行极致优化并推动系统平台化发展支持多业务类目多销售模式多支付模式。收益体现新架构的收益总结经济收益针对自营店2023年的GMV大概为 n 亿元经过业务战略的调整和完善2024年的GMV保守估计已达 2n 亿元完成了自营店收益跨越式增长。基于业务资源背景打通分销销售渠道一年入驻分销商/代理商 x 家接入核销商/系统商/供应商 y 家资源数量级涌进国内行业前列。分销和代理渠道的GMV在一年内已远超自营店2023年的GMV2024年保守估计已达 1.3n 亿元成为平台经济收益新来源。技术收益解决了高并发下的系统可用、数据一致等问题解锁集团域内中间件新玩法。沉淀出一套完整的交易履约技术方案、系统治理方案以及业务领域架构方案实现域内相关业务可复用能力。团队收益项目初期周末加班双倍工资项目稳定上线之后每个人获得13个月工资的项目奖金提升了团队人员流动的稳定性。团队在前3个月一直保持007高强度的工作节奏无一人缺席倡导的狼性文化得到验证提升了团队的凝聚力。业务相关数据成指数级增长带来了当下和未来及其可观的收益供应链侧研发团队由 n 人已经扩展到目前的 2n 人。业务设计交易角色对于整个平台的交易角色可以划分为C - B - P - S对于整个供应链领域可以划分为B - P - S C用户B自营店/分销商/代理商P采购平台主体S供应商交易属性对于自营店在 B - P 阶段的交易本质上是虚拟交易。对于分销商和代理商是真实支付的线上交易。交易阶段在供应链交易这个领域是两阶段交易BP PS。流量从 B 端过来可能会涉及到拆单的操作映射到系统设计上BP 阶段产生的订单定义为主单BP 单主单拆成的订单也就是 PS 阶段产生的订单定义为子单PS 单。领域设计在设计之初需要将各个领域边界划分清晰方便后续的系统迭代和架构升级。领域架构整个新团队职责划分非常明确和清晰在经过数次的“脑暴”后领域框架选型成了最大的问题。以前研究过Axon几年并且有过Axon在大型区块链交易系统从0到1的实战经验所以在领域架构选型上首推Axon作为整个团队的领域基础框架。但是在 “技术落地讨论会” 中发现团队内的同学们技术分散严重只有一半是做过Java相关业务的业务分散也很严重只有一半是做过/了解过电商相关业务的。因此大家对行业的业务领域和这些领域驱动框架了解的不是特别多。为了让项目尽快落地在领域框架设计上并没有严格采用DDD的思想但是在系统设计上参考了Cola这类框架的整洁结构和Axon这类框架的事件驱动设计结合平台的业务将“脑暴”后的领域模型不断推演最后将传统的领域驱动框架进行抽象和精简就有了现在的基础领域架构。 scc-starter是在大学开源的一套适配器组件的域内升级版方便灵活一键启动。领域划分最开始绿色的领域都是打散到红色领域中第一版上线以后发现各个领域随着业务迭代愈发臃肿于是及时做了调整。核心域订单域支付域资金域履约域退款域支撑域产品域合约域超时域消息域领域能力订单域预下单、收单支付域正向付款、逆向扣款等资金域资金流履约域预定资源、确定资源、服务完成退款域申请退款、快速退、强制退、退款回调产品域产品查询、库存扣减、库存回补、拆单、合单、Hold 单合约域合约信息查询、合约合法性校验超时域集团内部通用的技术解决方案旨在解决分布式事务tcc、消息丢失、任务补偿等消息域领域事件驱动领域事件领域模型实体对象采购单、资金单、履约单、退款单、预付款信息、预付款详情、调度任务值对象联系人信息、账户信息、合作关系、分销商与供应商信息、操作日志、退款规则、POI、凭证信息、出行人信息以及渠道信息数据模型设计是整个系统最核心的环节设计之初要保证数据结构具备足够的扩展性和容忍性。比如订单是否需要聚合、订单模型是否能够支撑未来的业务模式等。订单状态订单态订单初始化 - 订单交易中 - 订单交易完成 - 订单交易关闭履约态履约单初始化 - 履约单已创建 - 供应商创单成功/失败 - 待核销 - 部分核销 - 全部核销 - 履约完成支付态未支付 - 已支付退款态未退款 - 退款单初始化 - 已申请退款 - 同意/拒绝退款 - 退款关闭 - 退款成功资金态未付款 - 已付款 - 付款成功/失败 - 分账完成/失败 - 结算完成/失败 - 交易完成/失败系统设计平台全链路交易履约时序图新架构的预期流程如下面的时序图所示这是相对复杂的一种情况这个全链路时序图屏蔽了很多交易系统弱依赖应用希望能让读者轻松看懂整体的交易履约流程。整体设计图整体是两阶段交易正向交易主单驱动子单逆向履约子单推动主单从下图来看第一阶段收单 - 支付归属于BP交易范畴因为平台和分销商合作的性质不同支付能力基于第三方支付平台和域内资金池等方式但是整体而言都算是实时支付。第二阶段预订资源阶段本质上就是系统商创单的阶段如果创单成功会记录资金流水同时也会给计费结算平台发送计费事件。这里其实也是基于平台和系统商合作的性质因为平台和所有的系统商资金都是T1月结。解决方案收单服务治理收单服务接口是整个交易平台的流量口子在收单过程中会和域内域外多个服务进行交互涉及到各种复杂的业务逻辑。比如合约服务、产品中心和直连网关等这些服务都是交易平台强依赖的这些服务不可用也会导致交易平台不可用本地基本上是没有什么降级方案的。除了本地服务基本的代码优化减少调用链路优化代码逻辑执行顺序将阻断校验流程前置优化数据结构和算法优化查询逻辑减少IO次数利用本地缓存等合约服务接口性能、产品中心服务接口性能以及第三方支付平台的接口性能成为了影响收单服务接口性能的重要因素。合约服务查询合约信息等产品中心查询产品信息、扣减库存、回补库存等支付能力支付宝代扣查、付、退、取消、校验等第一阶段开发周期短核心是如期交付上线接住旧系统的线上流量为后续的业务扩展带来可能。根据已有大KA的要求收单RT在6秒之内收单服务即为可用上线之后收单服务的RT常态化Max为5秒。治理前后各项指标概要总响应时间RT显著提升治理前4700ms 治理后250ms 治理效果提升了18倍本地计算响应时间RT显著缩短治理前200ms 治理后30ms 治理效果缩短了6倍查询产品信息响应时间RT大幅减少治理前800ms 治理后70ms 治理效果提升了11倍查询合约信息响应时间RT大幅降低治理前1200ms 治理后60ms 治理效果提升了20倍校验支付能力响应时间RT极大缩短治理前500ms 治理后10ms 治理效果提升了50倍预占库存响应时间RT显著减少治理前2000ms 治理后80ms 治理效果提升了25倍单机QPS每秒查询次数大幅提高治理前40qps 治理后800qps 治理效果提升了20倍集群Max QPS显著提升治理前1100 治理后4000 治理效果提升了4倍收单Max QPS显著提升治理前300 治理后1200 治理效果提升了4倍服务器数量优化治理前40台4C8G 治理后21台4C12G包括10台、8台和3台不同配置治理效果服务器数量减少配置提升。库存扣减 https://blog.csdn.net/CSDN_SAVIOR/article/details/142887066 产品查询 https://issavior.blog.csdn.net/article/details/140734888 支付能力正式创单之前会进行支付校验域外的支付服务非常不稳定因此增加了重试、补偿等容错手段。为了彻底解决这种问题提高成单率平台在域内打造资金池分销商可在平台预付款每次支付从资金池扣减。流量平滑迁移 https://issavior.blog.csdn.net/article/details/141201666 业务扩展能力 https://issavior.blog.csdn.net/article/details/140891892 https://issavior.blog.csdn.net/article/details/140903785 系统数据治理订单数据一致性 https://issavior.blog.csdn.net/article/details/141275722 订单全局唯一ID https://issavior.blog.csdn.net/article/details/141279168 存量数据针对旧采购系统的订单数据新交易系统不必感知。旧系统的存量数据和新系统的增量数据由买家域和卖家域自行处理这些数据即可。处理数据需要注意数据的一致性在平滑切流的过程中新系统可能会存在旧系统的数据域外在同步数据的时候可以做一层清洗和过滤。数据的分片随着分销商和供应商资源的不断涌入流量在一段时间内成指数增长庞大的订单数据该如何存储这里的方案是采用分库分表未分区和读写分离架构将数据和流量打散。将采购单表、资金单表、履约单表、任务表进行水平拆分设计到相关的技术是TDDL核心原理和Sharding-JDBC差不多。拆分规则因为采购单数据不涉及到实时查询所以根据订单ID直接取模即可。分片规则根据以前业务的数据规模以及业务方针对未来的流量期望每天的增量订单会有千万级别。根据集团的数据库和存储引擎性能最终采取的分库分表方案如下 8库 - 32张表/库 - 256张表数据清理供应链交易履约平台的订单的生命周期比较短目前已知订单最长的生命周期是一个月所以可以将数月之前的数据同步到冷库中。读写分离准确的说读写分离在交易系统上的实践是有风险的交易系统大多为实时查询如果因为大事务、网络抖动等原因导致从库的数据同步有延时那对于交易系统的稳定性是非常致命的。这里读写分离主要是用在一些域内非核心应用小二系统给这些非核心且关键的业务透出一个口子做一些必要操作但是也要注意这些接口的稳定性比如限流措施等。交易等核心业务对于数据的实时性要求比较高读写都需要在master节点上。但是这样的设计显然不合理应该要将这些依赖交易系统的非核心应用全部干掉让他们通过其他渠道去获取数据以此来提升交易系统的稳定性。系统治理流量分组交易平台将自营店流量和分销/代理流量进行分组避免销售渠道相互影响。全链路服务将交易的流量单独隔离开避免非核心业务影响到交易链路。异常监控针对系统和业务级别的异常划分严重等级做聚合告警整合行业AI大模型做智能监控通知运营和研发同学及时处理。发布流程上线之前严格按着发布流程来研发 - 自测 - QA - CR - 安全环境回归 - 观察 - 灰度发布 - 观察 - 分批上线 - 观察而且CR务必经过Owner血的教训。埋点日志针对各个交易节点做全链路trace埋点除了排查问题之外还可以溯源很多次系统商服务的问题无法追溯导致结算出问题。风控巡检上线之后发现系统商这服务说挂就挂很不稳定用风控巡检来对所有的系统商服务接口做探针探活有问题就熔断掉异常系统商服务服务存活后再恢复系统商服务能力。熔断限流对外的接口上线之前要进行服务接口进行压测并根据压测结果设置合理的限流阈值防止服务挂掉。日常工具常见的不可抗拒的问题需要制定相应的工具遇到问题时可以提供给运营或者研发同学。紧急预案如果出现线上的问题需要有止血措施比如在上线之前可以针对改动点增加动态配置开关如果出现问题可以秒级止血即在1秒内关闭上线功能然后在进行回滚以及问题排查等措施。问题复盘出现问题不要怕要及时复盘、总结不能秉持“少做少错不做不错”的态度。节前准备针对于预知的流量节假日、营销活动等要做好扩容值班人员必须保证问题响应效率和解决质量。风险排查成单率、消息堆积、磁盘内存、ES容量、数据同步延迟、慢SQL等。提效秘籍自己这几年用的还不错的复盘计划分享一下希望能对大家有所帮助。结束语本文对“交易履约平台”做了简单叙述主要从宏观视角概述了繁杂业务中仅一条相对复杂的“交易”业务线的相关要点当然履约和逆向业务也是非常的好玩并且具备难点和技术挑战若有机会我将分享这些领域的心得。期望本文能为初涉电商交易领域的小伙伴们提供一些有价值的启发。同时希望各位老师不吝批评指正指出文中的瑕疵与待改进之处。更期盼大家在评论区踊跃留言共同交流心得、探讨问题携手促进我们的成长与进步。

查看全文

http://www.hkea.cn/news/14461260/