酒旅项目总结
项目背景
依托微信小程序和App 客户端提供线上预定酒店和旅游产品的互联网产品。
- 解决用户痛点1:提高了用户搜索酒店和预定酒店的效率
- 解决用户痛点2:售后功能保障了用户的合法权益
- 解决用户痛点3:基于数据分析提供给用户多需求场景的组合产品
项目架构
项目流程分析:
-
用户通过客户端发起请求,经过DNS解析(包括WAF,CDN,NetWork网络分发器)发送到Nginx
-
再通过Nginx集群反省代理到WebFlux网关,再通过GateWay进行动态路由由指定的Predicate(断言)和Fiter(过滤器)
判定寻址与Sentinel+Shard进行权限认证和令牌限流
-
DateWay通过Ribbon进行负载均衡,Sentinel熔断降级和业务集群建立桥梁,形成联系,通过Spring Security框架和OAuth2认证中心整合JWT进行公钥私钥的颁发授权与相应的验证功能,最终调用相对应的应用层。
-
SpringBoot应用层则在业务集群中通过OpenFeign实现相互调用。并可以整合Redis,Mysql,MQ,ES,OSS,JOB等工具,完成相对应的业务。
-
整个项目通过Skywalking为核心的运维监控中心可以提供链路追踪和监控报警机制,与运维报警系统Prometheus结合grafana最终通过Alertmanager告知负责人。
-
最终项目通过Docker容器的方式进行部署,使用K8s AP对资源进行编排,管理应用的生命周期,最后通过Jekinspipeline进行整个项目的构建。
工程结构
项目结构
项目设计
注:本队只负责用户中心及订单模块,且由我和一个好兄弟负责签到、我的现金、积分模块,仅针对这几个模块做具体展示
产品流程熟悉
数据库设计
个人中心模块
订单模块
签到表
积分流水表
积分过期表
用户钱包
钱包流水
注:开发过程中针对不足已做修改,非最终版本
接口设计
附上签到,积分,钱包部分的部分简图![在这里插入图片描述]
问题及解决
-
连续签到判断问题
解决:创建签到表,通过签到表该用户的纪录更新时间来判断,如果更新时间是昨天,则为连续签到,否则则为非连续签到
-
积分过期时间处理问题
分析:由于用户积分存在过期时间,需要判断用户积分是否过期,从而来更新用户的积分数。
解决:
方案一:使用xxl-job组件,定时检查用户积分是否过期
方案二:通过延时队列来实现实时更新,此方案对比方案一更加精准,误差极小。
(由于经验不足,第二种方案发现过晚,此处采用第一种方案)
-
xxl-job使用问题
解决:由于第一次使用,存在众多问题,通过各种教程解决。
(此处书写了一篇xxl-job入门博客供诸君参考)
项目总结
项目开发注意事项
开发注意事项
- 路径请求格式(业务/模块/方法) 方法名里面要加能表示动作的词,比如说 getMileage()
- 要统一返回格式,Controller层只返回正常处理的结果,错误,失败均在service层处理
- 使用全局异常处理,调用Asserts.fail 会抛出 ApiException异常,被 GlobalExceptionHandler 全局异常处理器(处理GlobalExceptionHandler 里面对应的异常),@NotNull 注解也会抛出异常被 ControllerAdvice 捕获
- 继承自父类的方法要用this.来调用,更加明确话。
- 注释:参数介绍 和 返回值
- DAO和VO都要大写
- service尽量调用service,继承ISercice
- 全文不要写两表或多表联查,尽量单独的用独立的service封装,联查时调用多个service即可,然后用java的流来拼起来,因为
- 单表走索引好保证,很难保证联合查询走索引,所以不见得联查会有多快
- 系统拆分的话联合索引很难判断
API接口规范
-
接口命名要简单易懂
-
请求路径接口文档为准,与代码对应controller层一致
-
GET 请求的参数在 Query 里面填写,POST 在 Body 里写。不要混用
-
参数名采用驼峰命名
-
数据库中存在的字段的参数,命名要保持一致,参数描述简单
-
如果参数中用多个 id 参数,必须区分命名,且要与数据库一致
-
响应数据示例的格式必须依据实际的格式
-
响应数据的类型和描述和请求参数的要求一致
个人总结
。不要混用
-
参数名采用驼峰命名
-
数据库中存在的字段的参数,命名要保持一致,参数描述简单
-
如果参数中用多个 id 参数,必须区分命名,且要与数据库一致
-
响应数据示例的格式必须依据实际的格式
-
响应数据的类型和描述和请求参数的要求一致
个人总结
在这一个月的开发过程中,通过代码的反复优化使得个人的代码变得更加更加规范,通过对项目的整体框架的学习,也使得我更加了解SpringCloud-alibaba这套体系 了,也通过不断不断的修改bug,提高了寻找问题及解决问题的能力,也充分了解到了业务逻辑的设计以及处理方案,也更加明确了开发规范。通过团队合作的方式,强化了交流能力,意识到了团队的重要性,处理问题要以团队为核心.最终十分感谢这一个多月和我一起努力,一起学习的伙伴们!