爱盈球项目详细设计
1 项目简介
1.1 项目背景
2005年,中国互联网彩票开始兴起。彩票是一种虚拟商品,在网络上的便利性和可玩性远远超过线下门店。所有的知名互联网公司都在销售彩票,比如淘宝、腾讯、网易等等,其中淘宝的销量最大。2015年,国家有关部门宣布禁售互联网彩票,主要理由是:容易放大彩票博弈特性,导致彩迷过度沉迷;难以堵塞未成年人购买彩票漏洞;给地方公益金分配带来难题;部分售彩机构存在偷票吃票行为;导致部分地区的实体彩票店大量关闭。
互联网彩票虽然已经落幕,但是培养了彩民在网络空间交流经验的习惯。竞技彩票以真实赛事为依托,既有球赛的娱乐性也有博彩的刺激性,广受彩民和球迷的追捧。许多球迷喜欢在关注比赛的同时购买彩票,但是大部人并不知道怎么分析赛事、预测结果。彩票专家应运而生了,他们长期研究赛事和赔率,有自己的一套提高彩票盈利率的方法。在网络彩票禁售前,网络彩票网站的订阅彩票专家解读只是边缘业务,但是禁售之后成为唯一盈利的业务。
1.2 项目简介
爱盈球是一个体育赛事推荐平台,汇聚知名足球和篮球赛事专家,为用户提供优质赛事解读和赛果预测。专家结合球队资讯和全球市场的赔率,发布包含赛果预测和最佳购彩方式的赛事解读,用户付费订阅解读,平台和专家各自获得相应的分成。
爱盈球项目主要由用户订单系统、专家解读系统、平台运营管理系统组成,辅助系统有赛事管理系统、用户社交系统等等。
1.3 项目里程碑
2021年03月,爱盈球项目立项。
2021年06月,爱盈球组建研发团队。
2021年08月,爱盈球APP v1.0上线推广。
2021年10月,爱盈球APP v2.0上线推广。
2022年01月,爱盈球APP v3.0上线推广。
2023年06月,爱盈球注册用户达到30K,全站日活达到2K。
2 系统设计
2.1 系统架构
系统架构的目标是持续支撑业务增长、提升系统服务能力,架构方案要根据用户和业务的规模逐步演进。初创项目的用户规模和系统压力都较小,技术团队成员也少,架构应该保持简单和轻量。如果架构的复杂度远远超过业务的需要,会浪费大量的人力和硬件资源。
开发常规的业务系统,系统架构选型要考虑技术稳定性和用人成本,优先采用稳定成熟的技术栈和解决方案,在市场上能低成本招聘到相应的开发人才。基于以上两点考虑,Java或者C#技术栈是最好的选择,Java使用更广泛一些。
开发框架:Spring Boot 、Mybatis
微服务:Spring Cloud (Eureka、Feign、Gateway)
链路追踪:Skywalking
性能监控:Skywalking
分布式缓存:Redis
日志收集: Elasticsearch + Logstash + Kibana
数据持久化:MySQL
消息队列:RocketMQ
分布式配置:Ctrip Apollo
2.2 核心模块
- 赛事服务
(1)通过竞彩官网采集最新赛事信息,并持续同步赛事状态。
(2)通过运营管理系统手动添加赛事、编辑赛事、修改赛事状态。
- 解读服务
(1)赛事专家撰写包含由文字和图片的解读,设置售卖价格。
(2)根据赛果计算所有解读是否命中,统计专家战绩。
- 用户服务
(1)注册、登录、个人设置等功能。
(2)查询个人订单、积分、优惠券等数据。
2.3 重要设计
3.2.1 数据库悲观锁
数据库悲观锁是业务并发控制的最后一道关口。以用户下单扣除账户余额为例,在并发的情况下,存在多个业务同时扣除余额,造成余额计算错误。这个操作可以采用数据表悲观锁,伪代码如下:
//查询用户账户
MemberAccount memberAccount = memberAccountDao.queryByMemberId(select id, from member_account where id = #{member_id} for update);
//判断用户余额是否可用
if(memberAccount.getBalance() < orderAmount) {
return resultModel;
}
//更新用户余额
MemberAccount memberAccount = memberAccountDao.updateMemberBalance(update member_account set balance = balace - #{order_amount} where id = #{member_id});
3.2.2 通用秒杀系统
秒杀活动是绝大部分电商选择的低价促销、推广的方式。秒杀活动对稀缺或者特价的商品进行定时定量售卖,吸引成大量的消费者进行抢购,但又只有少部分消费者可以下单成功。因此,秒杀活动将在较短时间内产生比平时大数十倍,上百倍的页面访问流量和下单请求流量。秒杀系统设计有2个关键点:采用内存缓存商品库存数量;采用消息队列缓冲创建订单。
3.2.3 RocketMQ延时消息
延时消息是指消息发送到 RocketMQ 后不会马上被消费者拉取,而是等待一定时间才被消费。在爱盈球项目中,延时消息的使用场景有两个:
(1)关闭超时未支付的订单
(2)某些场景下延迟特定时间后发送消息
3.2.4 分布式锁
分布式锁是用于分布式环境下的并发控制锁,它的使用场景有两个:
(1)提升效率:避免业务在不同机器上的重复执行。
(2)保持正确性: 防止并发访问或者修改数据。
4 研发管理
4.1 人员配置
后端 3 人
前端 2 人
测试 2 人
UI设计 1 人
运维 2 人
4.2 工作流程
开发需求是技术团队最重要的工作,开发需求的流程必须确保低成本高效率。如果流程复杂、执行成本高,是否能得到更高的产出质量。
- 需求开发流程
(1)产品人员整理需求文档,召开需求评审会议,与会人员至少有研发、产品、测试人员。
(2)技术人员评审需求,一个工作日内给出开发排期表。排期表中至少包含:开发耗时工作日、测试耗时工作日、上线截止日期,并标注参与人员。
(3)开发阶段,技术人员编码实现需求,及时与产品人员沟通疑点;如果有争议无法达成共识,上升到研发经理、产品经理。
(4)开发阶段,测试人员召集测试用例评审会议,与会人员至少有研发、产品、测试人员。
(5)进入测试阶段前,开发人员部署好测试环境和相关配置,再交个测试人员。
(6)测试阶段,测试人员根据用例测试,开发人员保持测试环境稳定,响应测试人员的协助。
(7)测试阶段,必须先测试通过3个环境,依次是 test(测试)、pre(预发布)、gray(灰度),最后进入生产环境。其中gray环境承接10%的生产环境流量。
(8)测试通过,测试人员发送邮件通知所有相关人员,并抄送研发经理、产品经理。
- 故障处理流程
(1)发现故障,研发经理指派责任人排查故障原因,拟定解决方案。
(2)解决故障,责任人根据方案修复问题,可寻求测试人员测试功能点,确保不会重现。
(3)故障复盘,责任人根据故障影响范围和严重程度评定级别,最高P0,其次是P1、P2,研发经理复核级别。如果属于P0级故障,必须输出《故障复盘》文档,并发送邮件给全体研发和产品人员,抄送技术总监。
- 代码评审流程
(1)在技术评审阶段,技术经理指定代码评审责任人。
(2)在开发阶段尾声,开发人员提交需要评审的代码给评审责任人。
(3)评审责任人开始评审,根据业务需求、编码规范、性能指标、安全等因素评审代码,并给出修改建议。
(4)代码评审通过,开发人员再进入测试阶段。
4.2 工作软件
- 项目敏捷开发:TAPD
- 内部知识库:Atlassian Confluence
- 内部IM:钉钉
- 原型设计:墨刀、Axure RP
- 绘图工具:Drawio
- 常用文档:WPS
- 代码评审:CodeStriker
5 技术参考资料
https://blog.csdn.net/weixin_71682097/article/details/125152722
https://blog.csdn.net/qq_16320025/article/details/106355483
https://zhuanlan.zhihu.com/p/561731421
https://blog.csdn.net/qq_16320025/article/details/106355483
https://www.modb.pro/db/72507
https://www.jianshu.com/p/b544aa1e46f7
https://www.cnblogs.com/wangyingshuo/p/14510524.html
https://blog.csdn.net/fuzhongmin05/article/details/119251590
本文链接:https://www.codingbrick.com/archives/1331.html
特别声明:除特别标注,本站文章均为原创,转载请注明作者和出处倾城架构,请勿用于任何商业用途。