0
点赞
收藏
分享

微信扫一扫

全流程开发 | 高并发电商服务系统 | 第1关

通过本专栏,‌‌你不仅可以学到完整的电商逻辑开发,还可以学到‌‌企业项目通用的解决方案。
从两个大方向来划分,框架核心、框架基础服务,‌‌框架核心我们可以学到容器,依赖注入,门面模式,中间件,服务,事件路由,驱动,‌‌这些基本上都是框架的核心和灵魂。
从框架基础服务当中我们可以学到控制器的巧用,模型‌‌,视图,请求,响应,异常处理,日志,错误,调试,验证,‌‌多应用,缓存等等,这些内容都会在我们的专栏项目当中一一涵盖。‌

‌还会分享一套代码分层架构,‌‌能够做到高度解耦多复用的能力。
其中包括5层架构,
控制器层,controller
业务逻辑层,business
内部基础库层,lib
视图层,view
模型层,model。
每一层都有它相应的职责。‌‌比如说控制器层它只负责接收请求的参数,然后对参数进行相应的校验,‌‌然后去调用业务逻辑层的内容,业务逻辑层它只负责去‌‌获取模型层返回的数据,然后对模型层的数据进行相应的组装,‌‌它还会去请求内部基础库层的数据,同样也会进行相应的封装,然后把数据呈现给控制器层,‌‌模型层它只负责去调取数据库里面的数据,它的职责很明确,只负责去‌‌调数据库里面的数据就可以了,它并不对数据库里面的数据拿到之后再次的进行封装,它的职责不会这样去做。‌
‌而lib层是一些基础库的封装,视图层它只负责一些相应的模板引擎,‌‌比如说我们的后端页面是采用了 layui 前端框架,那么这个时候我们就可以结合‌‌ 模板引擎 来处理视图层的逻辑,‌‌这样的话控制器层会去调用视图层的内容,然后视图层将内容返回给控制器层,最终呈现给我们的用户,‌‌是这样的一种思想。

‌接下来我们再来看一下我们项目当中电商核心的技术点,其中包括反作弊场景,‌‌关于反作弊它是电商系统不可缺少的一个环节,‌‌因为我们可以利用它来解决黑产进行抛羊毛的场景,‌‌所以说它是我们系统当中一个重要环节。‌
‌消息队列,关于消息队列,我们会从‌‌最基础的什么是消息队列?为什么要使用消息队列?消息队列的使用场景,‌‌以及我们使用消息队列之后,我们能带来什么收益?并且我们还会利用 redis 来做最简单的消息队列,最后过渡到 kafka,‌‌循序渐进的方式来讲解这个消息队列。‌‌
redis 集群 ,负载均衡,限流,在限流当中,我们会采用‌‌ nginx+lua+redis 来做我们的限流场景,服务容灾,系统降级,性能优化,‌‌商品抢购,并发锁,分布式session,服务评估。‌

‌在服务评估当中,我们会‌‌根据不同的 qps 来评估我们系统的架构,比如说当我们 qps 达到5000的时候,达到1万的时候,‌‌达到2万的时候,达到5万的时候等等,我们如何去架构我们的系统服务,这是我们的关键‌‌。
压力测试,排队机制。‌
‌优秀的开发者能力往往会体现在调试过程中问题挖掘,‌‌如何快速定位系统问题是一个非常重要的环节,‌‌本专栏也会带领大家手把手的教你如何去挖掘系统存在的一些问题。

支付的服务化,‌‌支付会采用阿里支付,微信支付,‌‌并且我们还会把它单独抽离出来,做成一个微服务的思想,从而做到高度解耦。‌

‌以上是我们电商核心的技术点,这些内容都会在我们的后面的实战内容中一一的进行讲解,‌‌在我们课程当中会讲解企业级开发流程,让大家对企业级开发流程有一个初步的认知,‌‌并且后面的实战也是严格按照这种流程进行相应的开发。‌

‌我们的开发流程会包括需求评审,‌‌需求评审它会涉及到很多人员,包括产品经理、开发工程师、开发工程师会包括前端工程师、‌‌后端工程师、测试工程师、UE设计师等等这些人员,‌‌大家坐在一起进行需求的评审,看一下哪些需求合理,哪一些需求不合理,不合理的我们剔除掉。‌

‌还有一种场景就是没有考虑到的需求,我们也可以在需求评审完这个地方加进去。‌‌我们的需求评审完之后,这个时候的话并不是一次就过了,可能会涉及到两次三次等等以上,‌‌最终会定一个需求评审的最终版本。‌

‌然后接下来‌‌设计师就会根据最终的需求进行相应的设计,设计相应的图,比如说我们的电商项目,‌‌设计师的话就会去布局我们的电商的图,有哪些功能,如何进行相应的交互等等,这都是设计师需要做的。‌

‌UE设计师把这个图设计好之后,接下来还需要进行评审,看一下这个图‌‌是否满足我们的需求,这个时候同样需要包括 UE 设计师、开发工程师、产品经理、‌‌测试工程师等等,我们坐在一起进行 UE 图的评审,最终我们会定一个初版,然后慢慢的‌‌进行一个最终版本的确定。‌

‌UE图确定好之后,接下来的话我们前端工程师和后端工程师‌‌就需要去定我们的接口了。因为我们的项目当中会涉及到很多 API 接口,这个时候我们需要双方工程师进行相应的‌‌协商,看一下某一个功能需要什么接口,访问什么字段,这是两类工程师一起‌‌才能确定下来。比如说你后端工程师,一个人定的接口没有任何意义,‌‌因为你定的接口不一定适合前端工程师,知道吗?所以这是很关键的因素,需要大家一起决定。‌

‌定完之后,双方工程师就可以进行开发了,比如说后端工程师直接去开发它的接口,前端工程师‌‌就去布局它的页面,后端工程师如果开发完了,他首先需要进行自测,我在我本地测试没问题,‌‌这个时候我就发起联调,我把我的接口给前端,然后我们一起进行相应的联调,‌‌联调完之后,同样前端工程师和后端工程师要整体的对当前功能进行一个相应的测试,‌‌测试完之后,开发工程师觉得没有问题了,这个时候方可进行提测,提测给谁 就提测给‌‌ QA 工程师,‌‌或者说叫测试工程师,‌‌而测试工程师就会对我们整个的功能或者项目进行第一轮测试,‌‌测试肯定会遇到一些小小的问题,这个时候测试工程师就会发一些测试报告,说你这个地方有什么问题需要修改,‌‌这个时候像后端工程师都要针对于测试工程师提的这些建议,bug 进行相应的修复,修复完之后‌‌再进行相应的提测,最终 QA 工程师认为没有问题了,才能够方可上线。‌

‌这个时候 QA 工程师必须要去发一个测试报告,认为本次功能没有问题,‌‌可以上线,这个时候我们的前后端工程师才能够进行相应的上线,那么这是我们整个开发的流程‌‌。‌

‌接下来我们来看一下我们的页面展示,‌‌
体验地址:http://39.107.30.137:8089/
这个地方我们只展示项目当中的前端页面,我们的前端页面是采用 VUE 进行相应的构建,‌‌ta直接会去请求我们的后端 API 服务,这是我们的首页,我们的首页会包括分类、‌‌搜索、‌‌购物车、轮播图,商品某个分类的推荐,‌‌这是我们的商品详情页,点击某一个商品会进入到商品详情页,我们会展示‌‌单个商品的详细信息,并且还会支持 sku ,立即购买,加入购物车,爆款推荐,‌‌

这是我们的登录页面,我们的登录页面会采用手机号加短信验证码的方式进行登录,‌‌短信验证码我们是使用阿里云短信的方式,这是我们的订单列表页,这是我们的个人中心页面,‌‌个人中心页面我们会有个人资料,收货地址等等这些内容,

这个是我们的支付页面。‌
‌关于支付页面,我们会使用支付宝和微信支付的方式,并且在课程当中我们会把‌‌支付宝,微信支付这些支付的场景会单独抽离出来,做成一个服务化,‌‌从而做到高度解耦。
因为这样的话,后续比如说我们的电商可以使用,活动也可以去使用支付,‌‌很方便。

‌接下来我们再来看一下我们 项目的功能点。
从两个大方向来划分的话,包括电商前端和电商后端,‌‌
前端我们会包括首页、商品详情页、注册登录页、购物车页、订单页面、‌‌支付页面、商品列表页面、个人中心,
后端我们会包括登录、商品管理、分类管理、‌‌订单管理等等。‌

‌首页会包括商品展示,搜索分类,支持‌‌无限极分类,购物车,页面静态化,redis 缓存,
商品详情页会包括sku设计,‌‌购买,加入购物车,爆款推荐,高并发下商品的抢购。‌
‌登录页面会包括手机号加验证码的方式进行登录。分布式session解决方案,
支付页面我们会包括微信支付,‌‌支付宝支付,在前期过程当中,我们的微信支付、支付宝支付会在我们电商‌‌系统当中开一个小小模块,后续为了高度解耦,我们把微信支付和支付宝支付单独抽离成一个‌‌服务,进行高度解耦。

个人中心包括个人资料、收货地址,我的订单等等。‌
‌后端当中,‌‌我们的商品管理其实还会包括很多的功能,比如说 sku 的设计和管理,图片上传,多图上传,‌‌分页搜索等等,
分类管理,我们支持无限极分类等等,
这些都是我们‌‌需要或者说常见的一些功能点。


举报

相关推荐

第1关:节点监听机制

0 条评论