为了账号安全,请及时绑定邮箱和手机立即绑定

报告!7至8月中旬项目总结!

2018.11.03 11:25 1238浏览

序章

18年7月至8月中旬一直在忙公司新项目,这也是我第一次做技术领队的项目,从面试开始就一直在阅读有关技术团队管理有关的书籍,本文将简述此项目的总结,从设计到编码实现到上线测试用户反馈等方面,篇幅略长,建议收藏。

当然,这是期间也可能有更好的技术实现方案,希望各位朋友看后提出自己的建议,MySelf自当摸索了解,吸收消化,谢谢。

前言

这是一个基于小程序的电商类项目,前端一人,UI一人,后台兼项目技术总控一人,小弟不才,负责了最后一项,具体原因是公司内部…

人员也是由我亲自面试,因为3至6月自己负责设计完成了一整个类共享的小程序(后续相关推文介绍),所以对于小程序还算一点了解,仅在于功能实现与开发上的了解吧,对于UI,我一向是比较重视的,无论你的技术多好,产品对于用户没有吸引力那么一切都无从说起。

前端面试:小程序类MVC开发模式(model层js)

UI面试:产品核心理解、用户体验为主、功能核心突出

项目数据库设计

这个在面试阶段就开始设计了,项目是图书类电商,所以与商品差不多,主要是ISBN这块,对于数据库设计主要遵循范式,不要存在不必要的多表关联,数据读写逻辑清晰,CRUD便捷,由于上一项目的基础,所以我这次的设计也是比较熟练,当然还是存在一点缺点,类似一些推荐模块、积分商城、优惠券等的设计可能是没有经验,总感觉设计的不是很好。

对于数据库相关的具体,后期会推出一个系列,实际的践行,这里不是重点。

后台架构设计

上个项目SSM后,对于配置上的一些重复工作,让我这次直接选择SpringBoot,且它对于Java Web的功能都很好的便捷集成了,数据库操作工具选择JPA,缓存涉及登录Token、搜索引擎关键字,我选择大众品牌Redis,消息队列Kafka配合ElasticSearch搭建搜索引擎,数据库选择MYSQL,现在很少用Oracle。由于项目较赶,所以后台的管理界面使用Freemarker模板,确实比较方便。支付使用微信的SDK,小程序所以仅使用微信支付。对于日志系统,由于公司决定,所以仅做了基本的日志输出到对应文件,定期备份,没有做可视化模块,后期再上线,

大致项目架构图,没有画的很详细。
图片描述

逐步分解:一

对于后台实现而言,如果你要写对应的Api文档给前端对接,那是一种相当耗时的事情,那么你可以选择SwaggerUI,一个小小的插件,可以减少你对文档花的时间,如下图,api开头的就是对应小程序的RESTFui API,fb开头的是后台管理界面的Freemarker模板生成页面。
图片描述

逐步分解:二

首先是后台管理界面,你要与上线后的操作人员沟通,一般会有原型文档,对于产品与模块有上线下线,类似本项目的一个功能:阅读推荐,需要选择推荐的图书与编辑对应的文案还有作者、时间等信息,它也是需要上下线的,且对于图书的信息,只录入一次,库存或其他模块,需要唯一ID去对应获取信息即可。

VO的重要性,View Object,即排行版需要的数据信息仅仅是封面、书名、借阅人数、金额等,但是图书信息Entity是由这本图书的全部信息,我们需要定义一个对应的VO对象,针对排行版去给前端对应的数据,不要把全部信息都给前端,这是一种准则!且可能后台的属性名,与前端要读取的JSON参数名不一样,你可以使用@JsonProperty去与前端统一。
图片描述

逐步分解:三

登录校验,Aspect切面处理,后台管理是一个禁区,所以需要Token的校验,除了登录、登出URL,其他URL都需要去校验Token的有效性,Token存放于Redis中,时效性是半小时,开发时可以设置长一点。

小程序也有对应的登录校验,app.js初始化小程序时,进行token校验,不存在就使用code来后台生成一个token,并保存用户的OpenId(SessionId),之后每次请求Token都放在Header中。

SpringBoot对于Redis、Kafka、ElasticSearch等其实都有默认支持,这一点是一个福音。

统一异常、Constants常量包、Utils、SDK包等这里就不一一介绍了。

逐步分解:四

搜素引擎ElasticSearch与Kafka的搭建,大致简介一下,图书数据入库(新增时)或更新,ElasticSearch中也有新增对应的图书信息,参数根据业务而定,图书下架时,ElasticSearch中进行移除,但是每次图书新增需要同步去执行ElasticSearch的操作,是一件存在隐患的事情,那么我们可以使用Kafka消息队列,让ElasticSearch去消费Kafka中的消息,去除同步的隐患。

ELasticSearch还能快速实现Search-as-your-type,保存关键字,定义返回关键字的个数,定义优先级别等。(后期因部分原因未上线)

在搜索中,还加了历史搜索,这个存在Redis中,一个Set,不重复且长度为7,即最多为7条历史搜索记录,会自动迭代上去。
图片描述

逐步分解:五

对于用户信息,是比较重要的,押金、订单、快递信息等都是需要重复测试,不过这里主要是业务实现了,就不细说。

那么我们说说前端吧,我对前端实现的要求,H5模块,小程序有Template,即一些模块可以抽取,重复的样式抽取后使用双向数据绑定填充,js块则是MVC,算是这么说吧,多定义一层model进行数据的请求操作,原js层引入model(ES6的类操作),去调用model的数据请求方法,获取到的数据重新转给View层。
图片描述

逐步分解:六

优化,数据懒加载,缓存使用等,这里涉及的比较多,那一个较容易理解的解释,排行版的数据是最多的,如果一次性加载完,那么用户需要等待10几秒不止,这个是绝对不允许的,那么我们可以一次加载10条,当用户下拉到底部时,再向服务器请求10条,这样可以提高用户体验,服务器接口也能提高工作效率,那么如果用户重新回到排行榜页面,那么我们又要再加载一次,其实这是没有意义的,我们可以使用小程序本地缓存,加载过的数据都放到缓存里面,当用户重新进入页面时,之前加载过的直接去缓存里面拿,不需要再次请求api,即如果用户之前已经看了100条数据,那么重新回来页面会直接显示100条,速度非常快,这样减少了服务器的不必要请求。

这里的缓存设置,再用户每次重新进入时,会重置,即每一次缓存里的数据是当前的最新数据。

结尾

本次项目总结到此结束,还有不足,将慢慢填充,如访问量瓶颈、数据读写瓶颈等,Tomcat横向扩展、Redis分布式等等。

往下一个阶段都会写总结,勉励自己,发现不足,定制目标,谢谢。

点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

1人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消