怀柔网站建设优化seo,怎么让WORDPRESS首页显示菜单,网页设计网站模板网站建设网页模板下载,wordpress主题官方网站说在前面
在40岁老架构师 尼恩的读者交流群(50)中#xff0c;很多小伙伴拿高薪#xff0c;完成架构的升级#xff0c;进入架构师赛道#xff0c;打开薪酬天花板。
最近有小伙伴拿到了一线互联网企业如京东、网易、微博、阿里、汽车之家、极兔、有赞、希音、百度、滴滴的架…说在前面
在40岁老架构师 尼恩的读者交流群(50)中很多小伙伴拿高薪完成架构的升级进入架构师赛道打开薪酬天花板。
最近有小伙伴拿到了一线互联网企业如京东、网易、微博、阿里、汽车之家、极兔、有赞、希音、百度、滴滴的架构师遇到一些很重要的面试题 一个系统如何进行 技术架构演进你的方法论是什么一个系统如何进行 服务边界划分你的方法论是什么 现在40岁老架构师尼恩站在京东如何架构商品治理平台的巨人肩膀给大家提供一份比较全面的参考答案。使得大家可以充分展示一下大家雄厚的 “技术肌肉”让你的面试官爱到 “不能自已、口水直流”。
也一并把这个题目以及参考答案收入咱们的 《尼恩Java面试宝典PDF》V113版本供后面的小伙伴参考提升大家的 3高 架构、设计、开发水平。 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF请关注本公众号【技术自由圈】获取 文章目录 说在前面480 万商品京东如何架构商品治理平台背景系统架构介绍早期的治理系统治理系统架构升级抽象思维显神威 难点问题巧手破业务难点问题技术难点问题治理触达终落地 治理业务全景图未来规划总结说在最后有问题可以找老架构取经推荐阅读 480 万商品京东如何架构商品治理平台
注意此文作者不是尼恩 作者京东到家技术团队/达达集团技术柯贤铭
此文仅仅是作为架构师的重要学习材料供大家参考。
同时希望此文也能给京东到家的产品多做点宣传 建议大家多用用京东到家的 服务和商品。
背景
作为一家即时零售电商平台京东到家致力于在一小时内将各类优质商品送达消费者手中同时也在努力提升商品的价值和平台的满意度。
京东到家商品管理系统其主要职责
对商品的创建、修改和展示的全流程进行干预和审核旨在发现并解决商品信息中如敏感词、虚假宣传、错误信息等不符合平台规范和质量要求的问题确保商品与实物的一致性以及信息的准确性。
系统架构介绍
京东到家的各个业务线都采用了标准化的微服务架构设计各个系统在迭代过程中只需按需申请对应的组件。
以下是治理系统所使用的技术组件
日志服务提供日志采集和查询服务。RPC调用利用京东的 JSF 平台实现服务间注册、服务间调用和服务治理等功能支持请求超时自动阻断。服务监控使用统一监控与告警服务平台实现秒级监控、多方位监控、服务告警、全链路追踪等功能。分布式调度引擎基于 TBSchedule 分布式调度引擎框架构建的服务负责定时任务的执行和分发。高性能存储使用 Redis 集群、MySQL 集群等。消息中间件采用京东的 MQ 中间件实现业务解耦。
系统架构如下 注意请点击图像以查看清晰的视图 早期的治理系统
第一个需求与大多数业务系统相似即基于数据的增删改查构建一套敏感词管理模块同时为商品主系统提供敏感词的校验能力。
第二个需求是为运营团队提供一个核验结果的报表主要逻辑是通过上传 Excel内部解析后调用接口获取相应的数据结果基于 MySQL 进行存储然后提供查询和展示功能方便运营人员使用。
然而由于缺乏设计和长远的考虑因此当时的治理系统与商品主系统耦合严重早期治理系统业务架构图示如下 注意请点击图像以查看清晰的视图 随着平台对商品信息合规性的规定日益严谨针对商品分类、净重、图片等各项治理需求也相继出现。
然而在上图的设计之中我们可以明显看出治理系统是基于具体业务来构建对外接口的。
因此随着业务需求的持续扩大两个系统之间交互的接口数量也会急剧增长这是我们不愿意看到的。
另外治理的最终目标是期望商品问题能够得到解决而不仅仅是发现因此将问题暴露给运营或商家是必要的。然而目前存在两个问题
商品系统在其主要流程中过度依赖治理的核验功能且随着业务的扩展依赖程度会逐步增加。商品系统只能将前置拦截的核验结果告知商家业务覆盖面不足。
再加上许多问题属于弱合规性不需要强制拦截但仍需要解决因此需要将商品治理业务的核心从商品系统转向治理系统。
为了实现商品治理的高效率对治理系统的设计和定位进行了调整提出了两个基本原则
治理系统需要完成整个治理业务的闭环作为商品问题发现和解决的总入口和总出口。治理系统需要具备高扩展性当增加特定化治理需求时能够迅速响应。
治理系统架构升级
抽象思维显神威
在理清治理系统的业务架构升级思路之后我们首先需要确定的一个问题就是治理系统最基础的原子能力是什么
以各个主系统为例‘
商品系统最基础的原子能力即商品的创建、修改和提供查询能力、
库存系统最基础的原子能力即商品库存信息的维护及查询能力。
根据治理业务的发展规划我们也基本确定出治理系统的原子能力即发现商品存在的合规问题并向外提供查询和辅助解决的能力。
对于合规问题的定义我们做出了如下解释即不符合电商平台商品展示规范的如敏感词、虚假渲传等问题。
例如商品名称中包含敏感词会被视为敏感词问题需要说明的是在编码阶段一种可量化的具体规则可以对应一种合规问题且同一商品可能同时存在多个不同的合规问题。
目前到家治理系统所涉猎的合规问题主要有
合规问题大类对外描述问题细节商品毛重问题商品毛重不准确商品毛重与实际商品不符、商品毛重超过最大运力限制等商品信息不正确商品信息不正确请检查具体内容商品名称包含敏感词、商品分类与实际商品不符、虚假宣传等商家商品经营范围问题当前售卖商品超出商家经营范围当前售卖商品超出商家经营范围等图片信息问题商品图片信息存在问题商品无主图、商品主图为默认图、商品主图为黑底图等未来计划商品价格问题––商品画像问题––...
为了方便理解我们可以将每一种合规问题看作是一种策略而针对策略的顶层接口又定义了四个核心方法
核验方法根据业务规则实现的具体核验逻辑自定义过滤能力根据业务特点减少无用处理问题关联的字段每一个问题都需要关联具体的影响字段或被影响字段映射关联的枚举每一个问题都需要关联具体的问题原因
具体的实现逻辑如下图所示 注意请点击图像以查看清晰的视图 以商品毛重信息填写错误为例下图为处理前后的展示结果 关于毛重的问题我们可以将其与相关的枚举和文案映射联系起来即当商品毛重出现偏差问题类型时建议的毛重为 XXX文案映射。其关联的字段包括商品的重量和名称。通过结合一定的过滤逻辑和验证算法我们可以完成对毛重问题的抽象处理。以此方式我们在处理新的治理问题时可以借鉴这种做法。
熟悉设计模式的读者可能已经发现这个设计方案实际上是策略模式和模板方法模式的混合体。在编码阶段我们也会用到工厂模式在编码层面整体的变化如下图所示 注意请点击图像以查看清晰的视图 上述方案落地之后产研团队对治理业务的未来发展有了基本的共识同时需求的实现也变得更加简单。我们不再需要关注其他系统的逻辑而是专注于合规问题的业务规则实现。
业务部门和产品团队能够通过数据分析来确定未来的治理重点和需求规划研发人员也通过优雅的方式解决了系统间耦合和业务代码重复的问题。
难点问题巧手破
在我们初步设定治理系统的业务架构设计后后续迭代过程中我们遇到了两个比较棘手的问题一个是业务问题一个是技术问题。
业务难点问题
业务部门要求 APP 展示的商品主图不能与默认图如空白图、品牌商标图等不能体现商品信息的图片相同然而商品图片的校验逻辑一直由图片核验系统承接。
这就引起了一个问题治理系统是否需要集成图片核验逻辑如果不集成那又该如何将其图片违规问题纳入至治理体系中
有经验的开发者可能会建议使用消息队列MQ的方式由图片核验系统将校验结果发送至治理系统以解决此问题。
实际上我们也是这么做的只是做得更加彻底。
在设计模式中我们通常会将一系列类似业务整合成一个公共接口向外提供能力我们将其称为门面模式或外观模式。
针对上述类似问题我们找到了一个通用的处理方法即将治理系统作为门面其他系统作为组件各系统都可以主动的向治理系统提供需要治理的内容。
该方案确定后各种棘手的业务场景也变得简单起来同时此举还扩大了治理系统的边界例如商品无图合规问题商品差评率高的问题只需要对应系统将相关数据/结果以消息队列MQ的形式发送至治理系统然后由治理系统为其绑定具体的合规问题即可。
在编码层面我们采用最简单的消息队列MQ解耦方式实现示意图如下 注意请点击图像以查看清晰的视图 在进行治理迭代的过程中有一系列的需求是针对平台商品的图片进行治理以破损图逻辑为例。
在最开始的处理逻辑中大家查询资料整合信息发现平台偶尔出现的破损图是由于图片在下载过程中未下载完整后流中断触发上传引起的。
因此在第一版的逻辑中我们查阅资料作出了如下逻辑判断当图片下载完成触发上传前对比请求体中的ContentLength与实际图片字节大小问题初步解决。
技术难点问题
然而不久之后问题再次爆发我们发现事情并非想象中那么简单。
由于我们的平台对接了众多的商家系统各个系统的图片服务器和后台逻辑都不尽相同因此我们无法对所有图片都采用文件大小比对的方式进行处理。’
因此我们重新进行了调研并实现了针对破损图的核验能力。 注意请点击图像以查看清晰的视图 即通过下载后的图片内容进行处理和分析利用算法与目标问题的业务特征进行识别从而基本解决了这个问题。
同时基于该思路我们也衍生出针对黑底图、默认图的处理方式在图片问题的治理上更进一步。
治理触达终落地
基于上述的方案和设计治理系统在问题发现的流程上已经趋于完善
接下来产品提出了新的要求即部分问题实现自动治理及问题触达商家。
机器学习的模型大致可分为两种分类模型和生成模型。
抛开它们的具体含义我们可以借鉴这种设计理念将治理系统划分为两个部分即发现和解决。
上述的业务提取和技术问题、业务问题都是用于侦测问题的当我们将解决问题的目标纳入治理体系只需要对现有架构进行适度的扩展就能满足需求。
以商品毛重信息填写错误为例我们只需要在上述的提取中添加两个待实现方法
是否需要自动处理毛重问题需要自动处理自动处理的具体实现规则当实际毛重大于某一阈值时将商品系统下架处理依托于商品对外接口能力
在核验结果存储前依据具体的执行逻辑以及数据反馈结果来判断是人工处理还是系统处理即可。
对于触达需求其实现更加简单因为在初始阶段我们就定义了治理业务交流的基本元素是具体的治理问题我们只需要将已存储的数据通过接口或消息队列的形式展示即可。
至此整个治理体系从编码层面也就建设完成其核心逻辑在三个环节
商品变动MQ/其他系统治理内容通知触发具体合规问题核验。针对核验结果进行判断人工处理或系统自动处理处理的能力需借助于商品对外接口。核验结果对外露出。
下图为治理系统当前整体业务结构图 注意请点击图像以查看清晰的视图 治理业务全景图
自从治理平台业务框架升级以来已经连续稳定运行了九个多月。
在此期间我们已成功治理了 480 万以上的平台商品构建了 8 种识别能力、3 种处理方式和 2 种触达方式。
同时我们依托商品和标品系统为商品快速建品、基础信息建设和治理审核等方面提供了有力保障。
以下是到家治理的全景图 治理业务全景图 注意请点击图像以查看清晰的视图 未来规划
现行的治理体系主要围绕商品系统的核心环节进行设计和构建其影响范围相对较小。
实际上我们可以将商品治理的成果扩展应用到商品体系之外的其他系统。
例如下图中的各个业务场景 注意请点击图像以查看清晰的视图 以搜索推荐为例我们可以针对各种合规问题制定相应的扣分规则在搜索侧构建数据时将商品的合规分数纳入其中并根据分数大小进行排序以满足搜索条件。
同时我们也需要将一些算法无法识别的问题纳入治理体系例如商品差评率高、退货率高等。
总结
随着业务的不断发展对商品信息质量的要求将越来越高。到家治理系统需要与各上下游系统紧密联动提供更加精细化的商品管控能力。
我们期待在未来我们的治理能力能够更加优秀为用户提供更真实、贴近实际的商品数据和更优质的服务。
说在最后有问题可以找老架构取经
架构之路充满了坎坷
架构和高级开发不一样 架构问题是open/开发式的架构问题是没有标准答案的
正由于这样很多小伙伴尽管耗费很多精力耗费很多金钱但是遗憾的是一生都没有完成架构升级。
所以在架构升级/转型过程中确实找不到有效的方案可以来找40岁老架构尼恩求助.
前几天一个小伙伴他们要进行 电商网站的黄金链路架构 开始找不到思路但是经过尼恩 10分钟语音指导一下就豁然开朗。
推荐阅读
《百亿级访问量如何做缓存架构设计》
《多级缓存 架构设计》
《消息推送 架构设计》
《阿里2面你们部署多少节点1000W并发当如何部署》
《美团2面5个9高可用99.999%如何实现》
《网易一面单节点2000WtpsKafka怎么做的》
《字节一面事务补偿和事务重试关系是什么》
《网易一面25Wqps高吞吐写Mysql100W数据4秒写完如何实现》
《亿级短视频如何架构》
《炸裂靠“吹牛”过京东一面月薪40K》
《太猛了靠“吹牛”过顺丰一面月薪30K》
《炸裂了…京东一面索命40问过了就50W》
《问麻了…阿里一面索命27问过了就60W》
《百度狂问3小时大厂offer到手小伙真狠》
《饿了么太狠面个高级Java抖这多硬活、狠活》
《字节狂问一小时小伙offer到手太狠了》
《收个滴滴Offer从小伙三面经历看看需要学点啥》 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF请到下面公号【技术自由圈】取↓↓↓
