电商项目开发中的几个重要技术点
项目重要技术点介绍项目简介项目是一个B2C模式的电商网站，采用的是前后端分离开发模式。前端主要使用vue.js开发，后端则主要使用DRF框架。celeryCelery是一个简单、灵活且可靠的，处理大量消息的分布式系统专注于实时处理的异步任务队列同时也支持任务调度Celery架构Celery的架构由三部分组成，消息中间件（message broker），任务执行...
·
项目重要技术点介绍项目简介
项目是一个B2C模式的电商网站，采用的是前后端分离开发模式。前端主要使用vue.js开发，后端则主要使用DRF框架。
celery
Celery是一个简单、灵活且可靠的，处理大量消息的分布式系统
专注于实时处理的异步任务队列
同时也支持任务调度
Celery架构
Celery的架构由三部分组成，消息中间件（message broker），任务执行单元（worker）和任务执行结果存储（task result store）组成。
celery是一个专注于实时处理和任务调度的分布式任务队列。本质上来说就是通过提前创建的进程调用函数来实现异步的任务。它有三个比较重要的组成部分：任务发出者，中间人和任务执行者。任务发出者通过 .delay()来发出指令，发出的指令好像排队一样按先后顺序在中间人的地方进行排列，而任务执行者则是实时的检测中间人中的任务指令，一有任务，立马调用封装的函数进行处理。
它有很多的优点，比如任务执行者可以单独的创建在其他的电脑上，这样的分布式也可以一定程度上缓解服务器的压力；异步执行任务，减少等待时间，提高效率等等。
在项目中一共有三个地方用到了celery异步任务。分别是发送短信验证码、发送验证邮件以及生成详情页面。下面拿发送短信验证码的例子来简单的说一下celery。
传统的发送短信的方法是客户端向服务器请求短信验证码，服务器再向云通讯发送请求，让其帮我们发送短信，但是有一个很大的问题，就是每一步请求都是需要等待响应的，如果网络较差，服务器迟迟得不到响应，那么客户端也得不到响应，最直观的现象就是用户点击了发送短信验证码后，没有任何反应。为了解决这一问题，我们使用了celery异步发送短信，减少了等待的时间。使用之后过程就变成了用户点击发送短信验证码按钮，服务器向中间人的任务队列中添加一条任务，立马向客户端返回响应，客户端开始倒计时。celery的任务执行者调用发送短信的任务函数，使用云通讯给指定的手机号发送短信验证码。
jwt
1.JWT使用的过程中服务器端保存了什么，客户端保存了什么？
答：服务器端保存的是SECRET私钥；客户端保存的是服务器加密后的jwt token。
2.JWT的校验过程？
答：客户端发起请求的时候，传递给服务器一个jwt token，jwt token分为三部分：头部(header)、载荷(payload)和签证(signature)。服务器在收到这个token的时候将前两部分header和payload使用header中的加密算法HMACSHA256进行加盐SECRET组合加密，然后将生成的签名信息与jwt token中的第三部分signature进行对比，如果一致，说明token合法，否则就是伪造的。因为生成签名信息的SECRET只有服务器知道，所以相对来说很安全。
3.JWT中是如何加密的，安全吗？
答：JWT中header、payload都是由base64加密的，而base64是对称加密解密的过程，不安全，详细内容介绍见5。signature部分则是将上面加密过的头部和载荷利用头部中声明的加密方式(HMACSHA256)进行加盐 secret组合加密，这样一来三部分组合而成的JWT就相对安全了。因为万事没有绝对，只能是相对的安全。
注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。
4.token中可以存放敏感的信息吗？
答：不可以，前面已经提到了，token的header和payload是经过base64加密的，而base64是对称加密，并不安全，因此不建议存放敏感信息。
5.为什么使用jwt认证机制？
答：在美多商城项目中，jwt token认证机制是对session认证机制的替代，基于之前的session认证机制，存在很多问题。比如，session信息存储在服务器端，如果登录用户过多，会占用过多服务器的空间；session依赖于cookie，session信息的标识保存在cookie中，如果cookie被截获，可能会造成 CSRF(跨站请求伪造攻击)；session认证不适合的分布式站点的应用场景。
6.jwt认证机制？
答：对于jwt token的认证机制，在用户登录时，服务器会签发( 生成)一个jwt token字符串。然后服务器在响应时将jwt token数据返回给客户端，客户端需保存jwt token数据。之后客户端在请求服务器时，如果需要进行用户的认证，需要将jwt token数据通过请求头传递给服务器，服务器会核验jwt token数据的有效性。
ES
ES是java语言实现的一个开源的搜索引擎，很火，一般我们首选ES搜索。它的原理就是先建立索引结构数据，类似于咱们新华字典的前面索引表。在通过搜索引擎查询的时候，和咱们查字典一样，先通过拆分关键字的方式查一下这个数据在哪，然后直接就找到了。
我们使用haystack全文检索框架，它是python中的全文搜索框架，支持多种搜索引擎，能帮助开发者利用搜索引擎建立数据表的索引数据。能帮助开发者利用搜索引擎进行关键词搜索，获取对应的索引数据。还能利用索引数据查找到对应数据表的数据。也就是它什么都有了，你直接使用就好了。
在美多商城项目中，使用Docker搭建es搜索引擎服务器并使用haystack对接es搜索引擎来实现商品的搜索功能。
redis
redis数据库是非关系型数据库，将数据存储在缓存中，读取速度快是其最大的优点。在Django中需要引入第三方扩展django-redis来使用。redis适用于存储使用频繁的数据，这样减少访问数据库的次数，提高了运行效率。它又五种数据类型列表、字符串、哈希hash、无序集合set和有序集合zset。详细的操作流程点击链接『redis操作命令总结』
在购物车记录存储的时后用到了redis，因为如果存储在mysql中，用户频繁的操作购物车的记录(删除或这添加)，就需要频繁操作mysql数据库。在redis中存储登录用户的购物车记录。读写效率要快很多。每个登录用户的购物车数据采用两条数据保存。其hash用于保存用户购物车记录中添加的商品id和对应数量；set用于保存用户购物车记录勾选状态(保存勾选商品id)。
浏览记录的保存的时候也用到了redis。采用的是列表数据类型。因为字符串和hash存储的时候需要额外的字符串操作，而列表直接可以存储，然后直接取值。zset需要额外的权重值来保证有序，而列表不需要。
nginx
Nginx相当于一个中转站，它的并发处理能力十分强劲，可以将客户端的请求转发给业务服务器，也可以将业务服务器的响应返回给客户端。我们在Nginx中设置了两台服务器，一台是静态文件服务器，一台是提供后端API服务器入口的服务器。
1.静态文件服务器用来向客户端提供静态文件。静态文件服务器在处理xadmin站点和富文本CKEditor的请求时，会报错。因为这两个接口是由业务服务器处理的，解决的办法就是修改静态文件服务器的配置文件，让其转发给业务服务器。
2.在Nginx中的另一台服务器，是后端API服务器的入口，向业务服务器转发请求，实现负载均衡。这台服务器收到请求后向业务服务器进行转发，默认的形式是轮流转发。
跨域请求
对于两个url地址，如果协议，ip和port完整一致，这样的地址就是同源地址，否则就是不同源地址。客户端发出请求时，如果源请求地址和被请求地址不是同源，这个请求就是跨域请求。而浏览器在发起ajax跨域请求时，会有CORS跨域请求的限制。在发起跨域请求时，在请求中携带一个请求头Origin（源请求地址）。被请求的服务器在返回响应时，如果允许源地址对其进行跨域请求，需要中响应时携带一个响应头Access-Control-Allow-Origin（源请求地址），要是没有响应头，直接就报错，将请求驳回，概不受理。
在我们的项目中使用了django-cors-headers这个扩展，通过设置白名单的方式指明可以访问后端的域名。
前往低代码交流专区
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)