JD 实习记录

业务需求

管理端数据隔离

• 情景:管理员通过管理端各模块的查询接口可以获取不属于其管辖仓库的相关配置数据
• 任务:根据管理员的操作权限实现基于仓库级别的数据隔离
• 行动:首先使用单例模式获取用户上下文，然后查询当前登录用户对应的仓库权限并用 Redis 做缓存,使用 Spring AOP 拦截查询接口将仓库权限注入查询对象中,然后在 Mybatis 拦截器中获取查询对象的仓库权限字段并拼接到待执行的 SQL 语句中
• 结果:最终实现了需求，也自定义注解以简化后续的开发任务。

盘点功能对接 WCS

• 情景:盘点模块需要接入 WCS,扩展盘点功能的操作范围
• 任务:创建盘点任务后下发至 WCS,并且接收 WCS 回传的盘点结果并执行盘点结果处理
• 行动:在原有流程将属于自动设备储区的盘点任务分离,并根据不同的设备类别,通过策略模式下发至WCS,并提供对外接口接受 WCS 回传盘点结果,最后执行后续的盘点结果处理（差异中心）
• 结果:最终实现了通过自动设备执行盘点任务,并为后续自动设备的接入预留了接口

订单预组波处理

• 情景:为提高拣货效率，需要将订单合并处理，这个过程称为组波
• 任务:需要对大量订单根据指定的筛选条件和分组维度进行汇总
• 行动:先将表关联，然后根据筛选条件查询出符合条件的订单,再使用集合运算对复杂限定条件进行过滤，然后分组查询将结果通过Stream流封装为树形结构返回操作端，用户选择分组项后，将分组条件代入查询 SQL 语句，查询后汇总订单并返回，用户选择对应的订单组，将待组波的订单号返回，最后执行组波操作
• 结果:最终实现预组波功能，提高组波的效率。

订单拆分规则配置

• 情景:订单初始化时需要根据不同的拆分规则，将上游系统下发的订单进行拆分，便于后续的流程处理
• 任务:提供运营端配置拆分属性，操作端配置订单拆分规则的功能
• 行动:运营端先配置拆分属性(商品单价，商品类目，商品等级，商品数量上限，商品体积上限，危险等级等)，操作端创建订单拆分规则前根据不同拆分属性，利用策略模式查询对应的拆分值选项或校验规则返回前端，后端接收拆分规则并进行有效性校验（单选，多选，固定值，范围，上限值），最后落库
• 结果:最终实现了订单拆分属性和规则的配置功能

项目管理

开发流程

1. 了解需求,系统方案设计,排期
2. master分支中拉取创建自己的开发分支(如:v_fearure_lushan)
3. 在v_feature_lushan分支上开发,并自测
4. Code review
   1. 发送 review 报告邮件
   2. 根据 review 建议修改代码
5. 将v_feature_lushan分支合并到v_test
6. 通过JDOS部署测试环境
7. 与前端联调
8. 提测
   1. 发送提测邮件
   2. 协助测试处理BUG和问题
   3. 收到测试报告
9. 将v_feature_lushan合并到v_gary
10. 通过J-ONE部署到预发布环境
11. UAT验证:解决UAT验证中遇到的问题
12. 将v_feature_lushan修改合并到master(临上线前1-2天,看情况,沟通好)
13. 正式发布上线
14. 线上验证(凌晨)

行云

1. 工时填报应在对应的项目和任务下进行,不可和其他项目,其他任务混填
2. 任务的安排周期不能超过3天,若超过,则需要进行合理分解,划分出多个更短的任务周期安排
3. 每天的工时应按实际的工作情况进行填报,填报方式选则按天填报
4. 每个任务的工时填报需建立卡片,卡片上应详细注明当天的工时利用情况,不可笼统地写为"研发,维护等简略词语"
5. 需求分析,系统设计,代码编写,自测,提测,代码审核,预发布和上线等工作内容都可以录入在行云卡片中
6. 按天填报的工作总结内容可以简略填写,但不能简单地写为"开发了xxx功能”,而是应该大致说明当天工作内容和任务进度,能够让项目组成员了解自己的任务实施情况
7. 对于当天相同的工作内容,工时信息不要重复填写,对于不同的工作内容,工时信息不要混写
8. 卡片可以自行建立,但是需要和相应负责人商讨

技术要点

JSF

• RPC框架:轻量级,更佳的性能,兼容旧版本协议
• 注册中心:基于DB作为数据源,前置Index服务,支持十倍接入量,部分逻辑放在注册中心减少客户端负担
• 监控中心:监控Proxy服务+InfluxDB(2015后改为ElasticSearch)
• 管理端:基于DB,功能更强大,提供完善的服务治理管理功能,打通京东应用管理平台,提供应用依赖关系梳理
• HTTP网关:基于Netty,支持跨语言调用
• 优化与特点
  • 引入Index服务概念:该服务就是一个最简单HTTP的服务,用于找注册中心节点(同机房或者压力最小或者其它特定场景),可以认为是不会挂的服务,RPC框架会优先连该服务拿注册中心地址,这样子的好处是注册中心地址变化后,RPC框架不用修改任何设置
  • 注册中心内存有服务列表全量缓存,连不上数据库也保证可读
  • 数据库的数据结构更适合各种维度展示,过滤,分析等,例如根据分组/IP/应用/机房等不同维度
  • 注册中心就是个JSF服务,监控到压力大即可进行动态水平扩展,不会出现2015年双十一那样的事故了
  • 服务列表推送逻辑改进:例如原来100个Provider,现在加1个节点,之前的SAF是需要下发101个节点,自己判断加了哪个节点,进行长链接建立,现在的改进是:修改为下发一个add事件,告知RPC框架加了1个节点,RPC框架进行长链接建立,这样做大大减少了推送的数据量
  • 注册中心与RPC框架可各种交互:注册中心和RPC框架是长链接,而且JSF是支持Callback的,注册中心可以调用RPC框架进行服务列表变化之外的操作,例如查看状态,查看配置,配置下发等

JDOS

• JDOS是基于open stack的云服务平台,包括以下使用流程:创建系统,创建应用,编译打包,构建镜像,创建分组,创建负载均衡,集群上线,更新集群,调整集群副本数,集群下线
• 部署项目时,首先将修改合并到指定分支,然后使用JDOS管理平台可以使用该分支的最新提交记录构建镜像,再通过镜像启动容器,部署在服务器上
• 解决线上问题时,可以通过JDOS提供的容器日志服务查看日志并定位问题

外部接口管理（jwms-local-common-outer）

• 提供统一的对外接口调用API，并且通过后台系统配置外部接口的调用方式,例如域名,是否为异步调用,是否启用,是否可重置等等,将调用外部接口的逻辑与业务代码分离,降低系统耦合度
• 提供统一的对外接口,通过入参指定被调用的接口方法,使用反射调用对应的业务接口,将与业务无关的逻辑从 Service 层分离,体现了单一职责原则，同时外部系统每次向服务端请求时候会附带一个短时间内唯一的序列号,使用 Redis 防止重复请求,同时缓存一段时间内相同请求的返回数据,提高并发下的响应速度并实现接口的幂等性
• 接口调用的日志会被记录在异常中心,通过接口异常模块可以看到所有接口调用的记录,并且可以查看接口调用失败的原因并重置

实体类格式化

替换前	替换后	作用
\/\/	/\*\*\n\t\*	将 // 替换为/**
private	\*/\n\tprivate	补上*/
;\n /\*\*	;\n\n /\*\*	字段之间插入空行