1.备选方案模板
1.1 需求介绍
• [需求介绍主要描述需求的背景、目标、范围等]
• 随着XX微博业务的不断发展,业务上拆分的子系统越来越多,目前系统间的调用都是同步调用,存在如下问题:
• 性能问题:当用户发布了一条微博后,微博发布子系统需要同步调用“统计子系统”“审核子系统”“奖励子系统”等共8个子系统,性能很低。
• 耦合问题:当新增一个子系统时,例如如果要增加“广告子系统”,那么广告子系统需要开发一个新的接口给微博发布子系统调用
• 效率问题:每个子系统提供的接口参数和实现都有一些细微的差别,导致每次要重新设计接口和联调接口,开发团队和测试团队花费了很多重复工作量。
• 基于以上背景,我们需要引入消息队列进行系统解耦,将目前的同步调用改为异步调用。
1.2 需求分析
[需求分析主要全方位描述需求相关信息]
5W
[5W指Who、When、What、Why、Where]
Who:需求利益干系人,包括开发者、使用者、购买者、决策者等。
When:需求使用时间,包括季节、时间、里程碑等
What:需求的产出是什么,包括系统、数据、文件、开发库、平台等
Where:需求的应用场景,包括国家、地点、环境等,例如测试平台只会在测试环境使用
Why:需求需要解决的问题,通常和需求背景相关
消息队列的5W分析如下:
Who:消息队列系统主要是业务子系统来使用,子系统发送消息或者接收消息。
When:当子系统需要发送异步通知的时候,需要使用消息子系统
What:需要搭建消息队列系统
Where:开发、测试、预发、生产都要搭建
Why:消息系统将子系统解耦,将同步调用改为异步调用
1H
[这里的How不是设计方案也不是架构方案,而是关键业务流程,如一个系统怎么发消息给另一个系统,比如在什么情况下发消息,这部分可以独立成“用例文档”]
8C:8个约束限制
注:需求中涉及的性能、成本、可靠性等仅仅是利益关联方提出的诉求不一定准确;如果经过分析有的约束没有必要,或成本太高、难度太大,这些约束是可以调整的
性能:达到RocketMQ的性能水平
成本:参考XX公司的设计方案,不超过10台服务器
时间:希望3个月内上线第一个版本,在两个业务尝试使用
可靠性:按照业务的要求,消息队列系统的可靠性需要达到99.99%
安全性:消息队列系统在内网使用,不用考虑网络安全问题
合规性:消息队列系统需要按照公司目前的DevOps规范进行开发
技术性:目前团队开发主要人员是Java,最好用Java开发
兼容性:之前没有类似系统,无需考虑兼容性
1.3 复杂度分析
[分析需求的复杂度,复杂度常见的有高可用、高性能、可扩展等,具体分析方法mindmap]
1.4 高可用
对于微博子系统来说,如果消息丢失了,导致没有审核,然后触犯了国家法律法规,则是非常严重的事情;对于等级子系统来说,如果用户达到相应等级后,系统没有给他奖品和专属服务,则VIP用户会很不满意,导致用户流失,从而损失收入,虽然也比较关键,但没有审核子系统丢失消息那么严重。
综合来看,消息队列需要高可用,包括消息写入,消息存储,消息读取,都需要高可用性。
1.5 高性能
微博系统用户每天发送1000万条微博,那么微博子系统一天会产生1000万条消息,平均一个消息有10个子系统读取,那么其他子系统读取的消息大约是1亿次。将数据按照秒来计算,平均没秒写入消息115条,读取1150条,再考虑系统的读写并不是完全平均的,设计的目标应该是以峰值来计算。峰值一般是平均值的3倍,则消息系统的TPS是345,QPS是3450,考虑一定的性能余量。为了预留一定的系统容量应对后续业务的发展,我们将设计目标定位峰值的4倍。因此最终的性能要求是:TPS1380,QPS13800。TPS为1380并不高,但QPS13800已经很高了,因此高性能读取是复杂度之一。
1.6 可扩展
消息队列的功能很明确,基本无需扩展,因此扩展性不是这个消息队列的关键复杂度。
1.7 备选方案
[备选方案设计,至少3个备选方案,每个备选方案需要描述关键的实现,无需描述具体的实现细节]
• 备选方案1:引入RocketMQ
• 备选方案2:集群+MYSQL存储
• 备选方案3:集群+自研存储
1.8 备选方案评估
2.架构设计模板
[备选方案评估后会选择一个方案落地实施,架构设计文档就是用来描述细化方案的]
2.1 总体方案
[总体方案需要从整体上描述方案的结构,其核心内容就是架构图,以及针对架构图的描述,包括模块或者子系统的职责描述、核心流程]
2.2 架构总览
[架构总览给出架构图以及架构的描述]
2.4 核心流程
2.5 详细设计
• 高可用设计
• 高性能设计
• 可扩展设计
• 其他设计
• 部署方案
2.6 架构演进规则
[通常情况下,规划和设计的需求比较完善,但如果一次性全部做完,项目周期可能会很长,因此可以采取分阶段实施,即:第一期做什么、第二期做什么,以此类推]
整个消息队列系统分为三期实现:
• 第一期:实现消息发送,权限控制功能,预计时间3个月
• 第二期:实现消息读取功能,预计时间1个月
• 第三期:实现主备基于Zookeeper切换的功能,预计时间2周