Jet_qi的博客

本文是项目实战的第一讲，如何优雅地记录操作日志。操作日志几乎存在于每个系统中，而这些系统都有记录操作日志的一套 API。操作日志和系统日志不一样，操作日志必须要做到简单易懂。所以如何让操作日志不跟业务逻辑耦合，如何让操作日志的内容易于理解，如何让操作日志的接入更加简单？上面这些都是本文要回答的问题。我们主要围绕着如何“优雅”地记录操作日志展开描述，希望对从事相关工作的同学能够有所帮助或者启发。文章目录1、操作日志使用场景2、实现方式3、使用AOP生成日志4、代码实现5、总结参考资料1、操作日志使用场.

软件核心的复杂性，并不是来源于庞大的软件体量或者复杂的业务流程，而是来自于项目长期迭代过程中不断冒出的超出当初设计之外的不确定性。本文为项目实战第52讲，搭建服务开放平台，向互联网开放企业内部核心业务能力。通过服务开放平台迭代的三个不同实现版本，逐步体会DDD解决了哪些软件核心复杂性问题。DDD并不是万能的银弹，映射到具体的业务场景时，DDD的理论系统也需要由模糊到清晰。

本文是DDD领域驱动开发第2讲，先讲解当前业务存在的问题，什么是DDD，为啥需要使用DDD解决现有业务问题，DDD让技术主动理解业务，通过领域模型将可以描述各个业务领域之间的关系，最后讲解领域驱动开发在货代订单的实践。

为了实现货运项目的支付需求，调研了支付宝支付，本文是项目实战第五十一讲，详解支付宝支付对接。

为了实现货运项目的支付需求，调研了微信支付，本文是项目实战第五十讲，详解微信支付对接

背景：店铺属标准中心业务，基础数据①开发实例店铺(旗舰店、专卖店、综合卖场)逻辑②接口调用量巨大，加缓存①使用Guava Cache 工具类 + Redis 记录缓存②使用MQ解耦业务如下图所示：实例店铺表：4.2、业务逻辑4.2.1、供应商注册店铺流程1、–》店铺创建 --》用户中心(云临时供应商成为云正式供应商，发送云消息创建店铺) —》消息体：用户id、用户名、机构id、店铺名== MQ（普通）： topic：ZCY_SUPPLIER_CREATE_SHOP cid：CI

项目实战第二讲：如何优雅地清理缓存

①使用 redis+guava cache 做缓存②使用了回溯算法表1：类目配置项表2：实例配置表表3：配置项控制表表4：实例关联关系表4.3、类目配置项业务逻辑梳理配置项写接口—》初始化数据(填充平台/实例,操作人信息)–》类目特许资质单独处理–》更新类目资质要求配置–》删除redis缓存(配置项+类目id)–》如果配置项json为空，由原先存在类目资质要求变更为不控制，需要进行删除操作 --》事务中：批量关闭类目资质，关闭类目配置项 --》校验资质证书参数(size.............

作为标准中心业务owner，完成接口代码梳理及结构优化，稳定提升接口性能，并做好限流措施保障系统稳定性。

项目实战第五讲：开放平台代码小重构1/2/

项目实战第六讲：协议变更联动商品变更项目背景主要技术项目职责项目实现项目review

基于缓存将库存信息前置，就是我们针对秒杀设计的一个主要的思路，宗旨就是尽最大可能的保护数据库，减少对数据库的访问，只将最后结果记录到数据库中就可以。，这样会比使用分布式锁效率高一些，如果时使用分布式锁尽量不是使用redisson的锁实现，不管是否是公平锁，他都会将你的请求进行排队并将线程挂起，如果一个请求加锁成功之后不知道什么原因处理的时间很长，就会导致请求加锁排队，线程被大量的挂起，从而影响系统的吞吐量，这个时候如果缓存中的库存已经是0 了，也会造成很多不必要的redis的请求。

在开发中 会遇到两个实体类DTO/POJO/VO相互比较其中数据是否有不同实体类中可能包含基础数据类型和List思路这时候需要自己写一个比较器获取两个类获取两个类中的get方法通过反射提供invok方法执行两个类中的get方法获得数据比较如果是List就递归比较List中的子对象返回不同的数据集合......

项目结构采用了star方法，概括性的总结业务背景和挑战；介绍你负责的任务已经需要达成的目标；项目中你采取的关键行动；项目落地后的实际效果。本文是项目实战第九讲运营导入导出工具。

背景：商品巡检有可能出现上万个商品不符合规范，供应商修改后，集采又需要一个一个审核后才能解冻，希望增加一键审核功能。①在监管按商品审核的审核列表页，新增“一键审核”功能②异步处理商品审核子任务逻辑①在商品一键审核流程中，大量使用了MQ②性能todo商品一键审核流程图如下所示：商品审核读接口 batchAudit/status --》批量审核，传递jobType=2(按商品审核)，查看审核执行进度–》参数校验(当前操作人非空，入参非空)–》由用户id+jobType 分页查询任务执行情况–》如果为空，返回给

背景：目前ocr事前拦截识别已经上线应用，经过2轮存量商品的识别，目前误杀率较高，需要通过一系列的规则配置优化模型，减少误杀几率①商品风险识别逻辑梳理②敏感词规则表设计③敏感词规则运营页开发④商品识图时规则匹配①在识图流程中，大量使用了MQ②考虑性能如下所示表2：敏感词白名单表4.2、流程图流程图如下图所示4.1.1、敏感词白名单写接口–》新增白名单规则–》数据校验(允许勾选的敏感词个数，敏感词重复检查，OCR命中文本检查，价格区间检查) --》组装参数–》创建规则 --》创建

商品中心规则引擎梳理优化需求使用了设计模式1、梳理规则引擎业务逻辑2、优化规则，减小规则引擎执行的rt表1、商品属性表表2、类目属性表4.1.2、项目整体流程图首先在商品发布时，从类目属性模块渲染发布页然后商品在创建或编辑时，执行规则引擎，校验入参的合法性，同时也会修正入参数据在商品查询时，对出参数据进行订正处理，透出符合要求的数据商品审核时，对审核数据进行合法性校验可以分为以下几个步骤–》组装用户信息–》校验拓展信息(分为精度校验和值域范围校验)–》使用了TreeRangeSet这个数

TMF2.0关键模型介绍在业务配置主线中，由业务产品来看当前业务涉及到哪些业务域，以及这些业务域下面有哪些功能和产品可以去使用，哪些业务点是可以去扩展的。这其中就需要能力域模型的支撑，通过这个模型所透出的结构化数据，来研究平台中每个域具备的能力、每个能力具有的可变点，从而有针对性地进行设置。在配置模型里，通过关键的视图模板，进行模板透出，然后保存、下发配置数据到业务运行主线。业务配置主线和业务运行主线是相交互的。基于TMF 2.0关键模型，整个平台实现了业务定义可视、可管、可配。业务定义可视化包括系统能力

使用异步编排优化商品详情页， 商品详情页在业务高峰期频繁超时，导致下游业务受到影响；难点：商详页是整个系统中日均访问次数最高的页面之一, 数量多（4亿一千万商品、11.3亿sku），重量大(商详页包含了大量文字、图片)项目职责：①接口减负：提供大量入参上下文，减少数据量；②提供缓存+批量查询：减少查询次数；③异步编排：优化线程依赖关系，获取上一个任务返回的结果，并返回当前任务的返回值

项目实战第二十一讲平台商品库需要有自己的思考，及对技术有深度和广度的理解。

项目实战第二十二讲：使用职责链模式实现商品审核。重庆的商品巡检有可能出现上万个商品不符合规范，供应商修改后，集采又需要一个一个审核后才能解冻，希望增加一键审核功能。

项目实战第二十三讲：标准中心-类目体系。标准中心承载了平台商品标准的元数据，目的在于通过沉淀元数据，来规范平台的商品数据，使得商品更加标准。标准主要分为三大体系：类目体系、属性体系、SPU体系。

商品中心规则引擎梳理优化需求使用了设计模式1、梳理规则引擎业务逻辑2、优化规则，减小规则引擎执行的rt可以分为规则编译和规则执行。当规则引擎算法进行事实的断言时，包含三个阶段：匹配、选择和执行，称做 match-select-act cycle。接口：Rule提供的方法1、 规则分类 提供的枚举ALL、SAFE、INFO、PRICE2、 适用什么阶段 ，枚举共六种：CONTEXT_INIT上下文初始化 PRE_CHECK前置检查 DATA_PREPROCESS数据前置处理 DATA_CHECK数

目前品牌库不支持重名品牌，一直采用技术订正的方式，需对品牌申请重名问题进行优化。

本文是项目实战第三十二讲：图片上传

本文是项目实战第三十三讲：标准中心-属性体系。标准中心承载了平台商品标准的元数据，目的在于通过沉淀元数据，来规范平台的商品数据，使得商品更加标准。标准主要分为三大体系：类目体系、属性体系、SPU体系。

SPU(Standard product unit) 即标准产品单元，SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。SPU是淘系最初电商化创造的概念，国外的电商平台如亚马逊并没有SPU的概念（亚马逊有个类似的概念叫父商品）。信息聚合SPU会集中定义一部分数据（框定类目下某些属性的值，关键属性和绑定属性）。比如格力KFR-25GW/E。

随着业务的发展，数据量迅速增⻓，单实例 Mysql 数据库的磁盘存储容量很快就会达到上限（阿⾥云 RDB 最⼤上限 6T）。因此为了解决⽣产环境的存储瓶颈，需要对数据库进⾏分库设计，加⼤存储空间。本⽅案基于 Apache 开源项⽬ Sharding-JDBC 进⾏商品⽔平分库设计（数据分⽚）缓解存储压⼒。⾄此，基于 Sharding-JDBC 完整的商品分库改造完成，包含选择分库分⽚键、定义分库数据分⽚算法，添加数据源 &表配置，代码改造等。

本文是项目实战第三十七讲：：商品中心-运费模版。主要逻辑是设置、编辑运费模版，然后在发布商品时使用该运费模版

本文是项目实战第四十讲：：商品中心-服务商品/服务承诺。主要逻辑是云端共享商品服务承诺需挂载到协议商品上，然后源商品服务承诺变更，共享商品服务承诺需联动变更

目前前台的标签需求，需求内容类似，每次都需要研发介入开发，后续需要做到研发尽可能不需要开发，**通过配置即可实现标签需求上线**。将**采购端和商家端**的标签接入个性化显示配置。- ① 使用了httpClient调用http接口；使用redis缓存色系库和icon库，以及按configId缓存标签详情- ② 实现回溯读取标签详情逻辑- ③ 定时任务计算最新色系库和icon库数据- ④ MQ异步记录标签操作日志

后端拦截的实现思路是在方法执行之前，先判断此业务是否已经执行过，如果执行过则不再执行，否则就正常执行。我们将请求的业务 ID 存储在内存中，并且通过添加互斥锁来保证多线程下的程序执行安全。

本文是项目实战第43讲：使用模版模式优雅实现财务编辑费用。支持查看司机填写费用信息，并且附件管理支持展示司机上传费用照片。

本文是项目实战第44讲：订单如何优雅增加港口报关状态信息。1、使用MQ接收港航信息变更；2、使用定时任务定期扫描订单数据，爬取通关宝数据；3、使用Spring Event监听箱信息变更，触发实时爬取通关宝数据

操作员只能看到自己的订单，但是操作主管和管理层可以看到所有的订单；业务员只能看到自己维护的客户的订单和客户信息，业务主管和管理层可以看到所有的客户信息。员工根据不同职位掌握不同体量的数据信息，以保证公司的“数据安全”。这个诉求可以通过“数据权限”解决

本文是项目实战第四十六讲，财务经营看板。财务模块划分为两类：① 财务工具（执行和业务财务闭环）② 财务报表，本期需求为新增财务看板，共增加4个看板

本文是项目实战第四十七讲，易宝支付对接详解。1、xxl_job 接入fix；2、支付接口，将thirdOrderNo赋初始值，并将数据库中third_Order_No设置为非空；3、性能提效：将深拷贝改为字符赋值，提升程序性能；先不改动。

支付、账户、三方支付机构、银行等；涉及到各方的信息流（账、余额、流水、运单状态等信息）和资金流匹配的问题是一个涉及交易的系统中**用户最关心的问题**；**对账系统是支付体系中最重要的一环，也是保证交易、资金安全的最后一道防线**。做对账系统的主要目的是为了实现对企业的交易数据进行实时对账，以确保企业的交易记录符合规定，提高企业的管理效率，降低企业的风险。

想让程序员写的代码部署到服务器，首先需要使用gitlab管理代码，然后通过jenkins来构建、部署项目，最后将生成的jar包部署到服务器，此过程中可以接入钉钉审批，方便控制风险。针对这件事，各家公司都有自己的应用发布平台。那么该如何设计一个应用发布平台呢，分为这几步：1、基础服务能力(jenkins提供任务构建能力，gitlab提供分支校验，merge能力，钉钉提供消息通知，审批能力，底层还需提供应用管理，ecs管理能力) 2、应用管理：负责应用的创建、查看详情 3、发布管理：提供代码构建

本文是SpringBoot第21讲，在以SpringBoot开发Restful接口时，当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，所以就有了降级和限流。在接口层如何做限流呢？ 本文主要回顾限流的知识点，并实践单实例限流的一种思路