Nursor后端服务

负责nursor的api和官网，是后端的主要部分。

使用django开发，目标是使用django的最新版，所以可以升级。目前稳定在5.0；

正文

用户下单的逻辑

1. 创建订单，temp-token不被消耗，以前会被消耗
2. 支付成功，订单状态从pendding->active（需要判断是否需要激活）
3. 订单记录中还是要有限制属性，这有助与对单独的用户进行调整，比如补偿流量，ai询问次数；

用户的逻辑

• 匿名用户的时候需要使用到temptoken表；
• 当匿名用户购买套餐的时候生成对应的匿名用户，通过membership_type字段来标记；
• 匿名用户注册的时候，直接绑定这个token，不会受到token是否参与购买而被影响；
• 当用户在app上激活软件的时候，普通用户和匿名用户都一样，查看是否存在可用的套餐；
• 用户新注册的时候，如果是属于被邀请用户：
  • 当前新注册的这个用户，给他一个免费的套餐，创建subscription
  • 邀请发出人，也赠送同样的额度，如果没有激活套餐则新建一个记录，否则直接在原来的（UserSubscibe）上增加额度，这个订阅记录上存储使用额度的设计，就是用来处理这种场景的

邀请的逻辑

由于可能存在多个活动，inviteship就是用来管理用户参与邀请的记录的；而用户发出一个邀请记录之后，就会出现在inviteship中，而用户的邀请记录，才存放在inviterecord中，甚至可以认为inviteship才是inviterecord的主键，owner。

使用方法

dev环境

export mode=dev

将会进入开发模式，开发模式下，静态资源即改即生效，可以用作开发，数据库是测试数据库

prod环境

默认是prod模式，prod模式下，css文件使用了cdn加速，所以要看到效果需要将静态资源上传到腾讯云；数据库是prod数据库

开发日记

上古问题

• 一直有collectstatic之后，相关静态文件没有自动上传到Cloudflare的r2的问题，后来Cloudflare的网络在大陆有点慢，后来干脆就放到腾讯云上边去了，以后每次静态资源变化，都需要手动上传腾讯云；

• 最开始是使用了Access_token的设计，就是完全一个随机字符，前后端比对来确定是否是正确用户；随着业务从淘宝切换到公网，现在已经改成了inner_token，这个设计也是为了学习pandavpn，不注册就可以购买，相当于来了就给你一个预设的账户。所以项目中还会有一些奇奇怪怪的设计，没有清理完整，以后见一次清理一次，不用保留。

• 用户的流量限制一直没有好好做，目前可以叫个s-ui来完成