1 背景
- 于买家：淘到经济实惠的闲置物品（二手数码），打发闲置时间（兼职，服务）去挣钱
- 于卖家：闲置物品（二手数码）卖钱，闲置空间（二手房租卖）换钱
闲置时间（兼职）和闲置空间（租房）区别于同城传统的闲置物品，闲置物品为传统C2C商品。但兼职、租房等业务，需供应商入驻提供供给。一旦涉及第三方供给，就面临：
- 随着业务的不断发展，必将有越来越多的供应商入驻。为了能让供应商快速接入，除了必备的接入文档，在技术侧应该能有一套动态响应机制，防止在供应商接入过程中被问题频繁打断（双方数量对不齐、同步失败原因等）
- 每个供应商的供给质量和技术水平存在差异，如何控制好供给质量的同时保证服务的稳定性成为另一大关键因素
2 整体架构
整体架构设计会复用中台基础能力，如用户、商品、交易等。抽象出三个领域：
- 商家域
- 审核域
- 独立业务域（每个业务可以单独划分）
安全生产层面，为保证系统稳定性，围绕：
- 限流（高并发下限流重试）
- 监控（对异常的状态出对应的报警）
- 数据安全（重试下情况下保证幂等性）
3 数据对账
- 审核：复用审核中心的能力（机审+人审）。机审：预置过滤规则，不满足过滤规则的判定审核失败
- 开放接口能力：提供查询商品审核、校验操作日志。
3.1 异常回调
- 收到同步消息后，对数据进行校验：数据字段合规性校验（长度、枚举值等）、夹带违禁词、状态更新异常（已经下架的宝贝执行下架动作）
- 针对上述初审通过，进入审核中心二次审核，审核主要内容为语义违规
两种回调场景都复用了异常流转的能力：
通过catch(LocalBizException e)的方式，将e.getCode()**和e.getMessage()**封装为response进行返回，无需对不同异常单独catch，让异常逻辑在业务回调侧闭环。
供应商获取到错误信息后根据错误信息修改信息进行二次同步。
3.2 定时播报
采集状态变更日志表和业务商品表将对应的一个小时内发生状态转化的商品数量（上架、下架、编辑、审核不通过等）最后以钉钉消息播报到钉钉群中（按照钉钉的机器人api）。兼职中主要关心的指标项为上下架成功与否、是否审核失败等指标，兼职播报架构图：
3.3 开放接口
与此同时开放的接口能力提供查询商品审核、校验操作日志。接口定义：提供时间范围、同步id、类型、分页参数等信息。
涉及图中状态日志表和商品表的插入部分见“稳定性”。
作者简介：魔都国企技术专家兼架构，多家大厂后台研发和架构经验，负责复杂度极高业务系统的模块化、服务化、平台化研发工作。具有丰富带团队经验，深厚人才识别和培养的积累。
参考：
