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
特别声明：除特别标注，本站文章均为原创，转载请注明作者和出处倾城架构，请勿用于任何商业用途。