完整代码:
https://download.csdn.net/download/weixin_55771290/87897132
持续编写中,您的 star 就是我的动力。请持续关注~
简介
完整的一套毕设级别项目,用于学习如何原生开发微信小程序,以及使用前端技术栈搭建较为完善的后端 Web 服务。
feature
- theme、banner 业务划分
- activity & 优惠券业务支持
- 商品分类
- 购物车业务
- 订单业务
- 延迟支付功能
- 用户登录
- 真实微信支付接入
对优惠券业务和订单业务做简单介绍,其余功能请扫码体验。
TODO:二维码
优惠券
用户只有在进行登录授权后,才可领取优惠券。并且优惠券是有品类限制和使用条件的,在品类上分为全场券和品类劵,在使用条件上除了上述有可能存在品类限制外,还需要达到一定金额方可在支付时使用。因此大体有如下种类优惠券:
-
全场无门槛减免劵
-
甜点满 100 减 30 优惠券劵(单个类型限制)
-
主食和热菜满 508 折优惠券(多个类型限制)
...
订单业务
当用户在购物车添加商品并触发下单逻辑后,后端首先需要对前端提交的数据进行详细校验,主要目的在于:
- 保证数据的准确性(牢记前端传递过来的数据可能会被篡改或者存在时差)
- 核查库存,防止负库存情况发生
随后进行库存的预扣除、优惠券的核销。当扣除和核销成功后,会为该订单生成一条数据并插入到数据库中,并将该订单信息推入到消息队列中间件中,以便在订单支付超时能够进行库存和优惠券的归还。
用户在下单完成后,可以选择在一段时间内进行支付,也可以手动取消,或者超出时间范围内自动取消订单。
TODO:支付成功后将数据写入到 MQ 中间件(提高并发能力),方便其他 RPC 业务(短信通知、仓库发货等)进行处理。
该项目是本人在做毕业设计时的产物,之所以拿出来分享并做教程,是因为当时在对整套系统进行技术选型时遇到了比较大的阻力。
如果不感兴趣,或者比较想直接看干货,请跳过该部分。
阻力
dataBase
首先我有一点数据库基础(停留在 MySQL 应知应会水平)以为数据库就那么简单,撸袖子干就行了。可见当时是有多无知。
后来随着不断开始设计数据库表时候,就明显觉得异样。当时脑子里并没有对于一个相对有点复杂系统有完整的设计思路,或者说是经验。
因为系统内部的每一个模块是有关联的,不是相互孤立的,所以最初版的数据库设计的跟屎一样。冗余字段、连表查询困难、连最基本的业务软删除硬删除都没有意识到,于是就开始找寻只跟数据库设计的书有关,或者说:能够快速教我如何设计这个数据库。
很显然,数据库好的书籍比比皆是,但教你如何设计一个系统,我还真没找到。于是在某网上找到一套课程,开始学习起来。这,就有了本套系统的数据库雏形。
但当时,比较大的阻力就是,如何将老师讲得东西迁移到自己的系统中?并能够用比较适合自己的技术栈给他应用起来?
经过很多资料的查询和尝试后,最终选择了 TS+typeORM 这种 ORM 去嫁接在 MySQL 之上。有几个原因:
- 我想学习 TS,并应用它。
- typeORM 语法很干练,类型注解用起来开发效率暴增
在开发的过程中,发现国内有的资料很少很少,官方文档也没有写全。往往很多时候需要去查询.d.ts 文件,如果还看不懂就要去 stackOverflow 和 typeORM 下面的 issue 查,查完自己还要反复试错。
因此就萌生了想把整个开发过程复盘下来,并分享给其他人。
webapi
同时在对 Web 框架进行选型时,由于我想尝试并学一下后端较为成熟的项目架构分层,就开始在 egg.js 和 Nest.js 之间进行选择。不是说 egg.js 不好,只能说我火候还差的太远我用不好,或者说理解不好。于是便选择了 nest.js 作为整套项目 Web 后端框架,同上述数据库一样,依然国内没有较为体系的、较为细致的教程。nestJS 官方文档虽然还不错,但是能够直接看文档就拿他撸一个项目,还需要有一定功底的。(除非你的项目根本就是小 demo,好多问题不考虑的那种。)
更何况后面由于项目存在一定复杂度,需要通过接入延迟消息队列去解耦业务时,自己又是趟了一把 rabbitMQ 的坑。因此更加坚定了自己写教程的想法。
技术栈
前端:微信小程序 + LinUI 组件库
后端:TypeScript + MySQL(typeORM)+ Nest.js + rabbitMQ
部署:Docker + Docker Swarm + CentOS + Nginx
技术难点
- 实现一个功能的思维路径是怎样的?
- 如何设计合理的订单系统?
- 如何设计并实现优惠券活动?
- 如何实现高效的延迟支付功能?
- 如何通过 Docker 部署可拓展集群?
沉淀
闭环思维提升
并不是认不清自我要往全栈发展,只是作为一名 RD 人员,应该在力所能及的情况下对整个研发流程有一定理解和体会。这样在多人协作时才能发挥出最大价值,并且在一定程度上进行能够换位思考,而不是互相甩锅。
从一个 ide 产生,到具体落地需要几步?
设计规划 -> ... (接下来混乱了)
这就是当时我拿到课设题目时的状态,有主意但难实现。当时自己简单的学过一个 express 开发的项目 : (TODO:地址)
该项目较为简单,当时只是体验了一把 TS + express + GraphQL 开发的后端的乐趣,但并没有形成系统性的思维。
于是在经历某夜失眠后,将整个问题拆解成如下几个部分:
- 一个需求如何从前端到后端进行具体实现?
- 如何设计一个“能用的数据库”?
- 合理的后端分层是怎么做的?
- 如何部署一套“能用的“服务器?
在这漫长的修行之旅中,先后补充了如下知识:(如果需要,请私信我,我都会发给你~)
- 数据库设计
- Spring 设计电商(大体了解一下 Spring 写 webserver)
- docker 部署
- zero-to-nestJS
在这过程中,也参考了如下专栏:(TODO:地址)
将整个过程记录在该仓库中,一是为了能够给其他兄弟一些参考,另外是做一个自己的技术沉淀,毕竟好记性不如赖笔头。
虽然自己离真正的闭环还差的十万八千里,但好歹也是迈出了第一步~希望在下一个节点,能让这个圈儿,再壮实一把!
产出意识
凡是需要有“产出”,道理我都懂,但做的一直都不好。在学习前端知识的时候自己就有意识去产出,但都没有做的很满意。(TODO:仓库地址)
我想可能有如下原因:
- 学习资料比比皆是,感觉自己的总结对他人无用(其实是错误的观点)
- 枯燥乏味,难以坚持产出
- 缺少内驱力
但依然还是坚持在做产出,例如我自己的技术脑图(TODO:脑图截图)
但都没有达到能真正的解决其他人的问题,虽然自己收获的蛮多。但没有得到市场(他人)认可,就是失败的产出(消极了)。
于是这次重新上路,决定将自己对于每一个 feature 的理解、思维路径、以及实现过程中遇到问题如何解决都会详细记录。力图给 nodejs 社区添砖加瓦(努力做,一定可以的)。
TODO:(反复思考重整) 思维路径可以归纳为如下步骤:
对需求进行详细分析,提炼需求点
进行数据库设计 设计数据层(repository),思考数据库事务操作,找到核心点 分解业务层(service),对复杂的业务分解处理完毕后,交给上面分析过的数据层。 接口约定 设计控制层(controller),主要起到承上(http)启下(service)作用。 抽象DTO,... 接口保护 接口校验
整个分析过程会适当借助流程图辅助进行梳理,比如 jwt 登录鉴权、订单校验逻辑以及延迟消息队列的接入。