转正答辩PPT报告_第1页
转正答辩PPT报告_第2页
转正答辩PPT报告_第3页
转正答辩PPT报告_第4页
转正答辩PPT报告_第5页
已阅读5页,还剩16页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、转正答辩报告中心-部门 姓名2022 . 1. 28工作内容总结试用期工作概述工作完成情况项目成功经验总结与不足目标规划2345目录CONTENTS1工作内容总结商品名称修改工作概述商品名称被抢先注册,对涉及的6款产品进行紧急名称修改。一键涨价配合涨价节活动,对五码产品价格进行零点一键涨价,商品中心建设搭建满足支持历史数据,满足当前需求,支撑未来变化的商品中心。工作完成情况100%已成功上线,稳定运行2个月未发现异常商品名称修改100%2022/1/20已上线,已支撑当前14个外部项目接入,并为其提供了稳定的服务支撑,截止当前未发现异常商品中心建设100%已上线,在2022年零点实现了价格的统

2、一变更。成功支撑涨价节一键涨价商品名称修改01问题收集商品名称涉及数据库数据修改,前端页面固定值修改02问题分析为保证数据修改的一致性,从800+张表中识别出商品名称基础表2张,关联表15张。03问题解决1、更新主表数据2、使用从主表同步更新数据的方式完成数据修改04结果验证1、通过验证sql对数据进行验证发现的问题数据冗余到公司90%的服务中,牵一发而动全身。一处变更,全员出动范围广极易造成遗漏不通过服务调用直接操作数据库,无法校验sql准确性。验证复杂。会造成数据库死锁,整个公司服务瘫痪如何改变?123涨价节一键涨价ABC业务梳理方案制定一键涨价ABC1、了解目前商品价格现状2、如何在对当

3、前业务影响最小的情况下实现目标3、梳理业务流程,数据结构1、基于稳定性优先,影响面小的前提。我们不做原有流程做任何改动,只对商品本身价格做出数据修改。对原业务0影响2、从而我们梳理出与价格相关数据表,累计5张3、从表字段分析,每张表都有对应商品的id。我们可以根据商品唯一id对数据进行修改1、创建调价单2、添加调价的商品id3、执行价格调整涨价节一键涨价通过调价单验证,判断此次调价任务是否合法,避免价格被恶意篡改的安全风险通过调价商品id验证,保证只对本次需要调价的商品进行价格调整,避免操作错误,数据不一致导致的数据异常通过状态机流转保证并发操作问题日志记录,留存下每次价格调整的操作数据,用于

4、问题排查4123商品中心查询api化对接小组对接服务对接人xx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexxxx小组xx-servicexx1、通过跟表内所列同学一对一沟通梳理出他们维护项目的具体需求2、我们一起梳理罗列出总计xx个接入服务商品中心查询api化目标过程结果识别商品中心基础数据表通过与使用到商品相关信息的同学沟通,

5、从他们提出的需求去识别商品中心基础信息表从800+张表中识别出17张表如何提供接口从需求方同学提出的需求,识别出来的商品数据结构,通过领域划分我们来定义具体的api定义出累计44个查询api商品中心查询api化最终目标API粒度适中灵活完备易用根据业务和需求分析提供粒度适中的api,粒度太大面向数据库编程,粒度太小无法满足业务需求业务调整变更小,复用性强,代码用低提供各种api,通过id查询,综合查询的各种api需要通过超过多次接口调用才能获取完整数据的,提供组合式的参数请求,返回多种数据结果可控接口设计有各个粒度的控制,针对服务的身份校验,接口的token校验,方法的token校验商品中心查

6、询api化最终目标1、系统结构上我们竖向进行分层,三层模式。a、控制层统一暴露接口;b、业务层,业务实现;c、数据层,对数据单标操作,提升性能2、横向进行领域划分,划分出类别,SKU,SPU三个大的领域,领域内进行子域划分。让复杂的功能可以利用组装便能实现3、使用映射,通过映射获取到跨领域的数据信息商品中心查询api化我们可以干嘛?在这里我们看一个数学问题,学生A答对题目的概率是99.9%,学生B答对题目的概率是99.9%,那么A,B两个学生都答对题目的概率是对少?商品中心查询api化根据统计商品名称修改涉及前后端15个服务。投入人员开发11人,测试7人,用时2天,累计36人天。运维需要发布1

7、5个服务。接入商品中心后只需要投入开发1人,测试1人。累计2人天商品中心查询api化接口测试 对商品中心对外暴露的查询api进行功能测试,性能测试接入服务测试 对接入服务进行功能测试接入方接入 接入方同学对已识别到的接口进行接入商品中心表迁移测试 迁移走商品中心数据表,暴露出未完全接入商品中心的服务与功能如何确保商品中心的稳定性及接入的完整性商品中心查询api化对接服务对接服务调用商品接口次数说明CloudshopCloudshop1.5W+/appletsapplets3W+/service-rebateservice-rebate1.2W+/zeus-dmszeus-dms1.6W+/se

8、rvice-orderservice-order10W+/vhome-backendvhome-backend2W+/channelchannel1W+/user-center-finaluser-center-final0与江城确认此处只有大区组织机构调整会调用此接口,故此处为正常情况service-contractservice-contract5446/service-logisticsservice-logistics10W+/service-workflowservice-workflow2W+/zeus-codezeus-code2/ncenter-serverncenter-se

9、rver2903/paycenterpaycenter1388/接入结果总结收获 1、遇到问题与新需求时,不能盲目的开始开发工作。而是要做好前期问题分析,信息收集的工作。这样才能找到问题的根因,分析到真正的需求达到事半功倍 2、如何定义接口,避免面向数据库的接口定义 3、合理领域划分带来的好处,提高复用不足,后续持续改进1、在商品中心开发时任务分配不合理,未按照领域分配,而是按照接口分配,造成了一定重复性的工作2、商品中心前期接口测试时,没有与测试同学拉齐信息。造成一些偏差,导致测试早期进度进展缓慢,后续需要注意这一点,磨刀不误砍柴工目标规划完成商品中心新体系内部治理完成中心化在商品中心查询api的基础上,完成数据增、删、改api化。让商品中心所有的能力全部回归商品中心自身,由商品中心统一对外提供能力,统一管控商品中心内部服务治理:1、满足未来发展为商品中心搭建新的基础数据结构;2、兼容原有业务,不做休克式迭代实现新增商品信息在新老数据结构实现数据双写丢下包袱,还清债务:将历史数据迁移到新的数据结构下,完成商品中心的整体升级近期目标中期目标远期目标目标规划终点过程起点一步到位会让我们步入更多的陷阱:1、休克式迭代不能跟上当前业务发展,势必导致需求脱节2、累积更多的缺陷在我们的业务中3、一步接入导致,无法及时获取到需求方最新的需求,无法提供满足要求的服务。接入

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论