Lottery项目总结

2023年7月到2023年11月

抽奖系统总结

经过三个月的零散学习，写项目，终于将项目写完了。这个过程也让我学习到许多解决问题的能力，目前就是多尝试。

从基础的搭建DDD项目开始，看文档、查资料、向大家提问，一步一步的写代码，刚开始我并不会从哪里开始写代码，有人说先从入口开始写，有人说从测试类入口开始写，也有人说从接口开始写，然后缺什么就补什么。就这样我一步一步的尝试，写了几章又停歇了几天甚至一周吧，然后再继续写，这时前面的可能忘记了，边写边熟悉。经过了如此反复，才渐渐完成。抽奖模块中使用到分库分表，但这分库分表没看明白，就直接使用lottery提供的自研分库分表组件了，也没花时间写一写。再到在这DDD架构分层applicantion、common、domain、infrastructure、Interfaces、rpc（对外暴露接口）这几层接口，实现领域驱动的充血模型，mvc则是贫血模型，简单理解mvc就是多个人穿一条裤子，ddd则是一个人穿一条裤子。

在这其中我也简单了解到分库分表中使用抖动算法，使用到决策树，还有什么忘记了。

用到策略模式，还使用抽象类，让方法进行复用。

模板模式一般用于处理抽奖流程，

id策略，不同的业务使用不同的策略id，像表中数据比较多的就使用id表长的，貌似是雪花算法。

活动流程编排，后续就是对业务的处理

业务上就是对活动的管理，比如编辑活动后就需要审核，审核通过后才能开启活动，可能还存在提审等流程，
而

规则引擎则是对不同用户群体进行划分，也就是不同用户群体抽奖的奖品不同、策略也不同。

后面还使用到门面接口来封装和转换对象，转换使用到structmap

再到后续抽奖接口写完了，就是编写后台、对接公众号回复抽奖、转盘方式抽奖，
后台主要是对库表中的活动管理、奖品管理，这部分主要是crud，也是需要完善的地方。
而公众号则就是需要增加用户唯一id的管理，对每个用户进行限制抽奖次数、用户群体等
转盘抽奖方式，首先得用户让用户进行注册，然后领取活动次数，才能进行抽奖，不然不能让其进行抽奖活动。

像后台管理，一般都是调用lottery通过rpc暴露的接口，然后后台管理调用对应暴露的接口，这个过程用到了dubbo和nacos服务注册与发现，也就是后台管理中需要添加对应的dubbo依赖和配置，同样nacos也需要。

redis主要是抽奖要么成功要么失败，这样的执行策略。
mq主要是抽奖成功后过一段时间更新库表，相当于延迟发奖让用户不用一直停留在抽奖界面等待。
也就是现在使用kafka中的提供者和消费者，而nacos则是管理这里的提供者和消费者以及一些服务的注册和发现。

dubbo作用就是rpc服务调用

之前一直使用zookeeper或者直连方式进行测试的。

技术上使用到springboot、MyBatis、mysql、redis、xxl-job、dubbo、zookeeper、kafka、nacos