架构设计文档模板参考

以类微博功能的消息队列为例,给出架构设计中最重要的两个文档的模板和关键说明。这个案例文档仅给出一些关键内容供参考,部分细节无法全面覆盖或者完全保证正确。

备选方案模板

需求介绍

需求介绍主要描述需求的背景、目标、范围等

随着业务的不断发展,业务上拆分的子系统越来越多,目前系统间的调用都是同步调用,由此带来几个明显的系统问题:

  • 性能问题:当用户发布了一条微博后,微博发布子系统需要同步调用统计子系统、审核子系统、奖励子系统等共 8 个子系统,性能很低;
  • 耦合问题:当新增一个子系统时,例如如果要增加广告子系统,那么广告子系统需要开发新的接口给微博发布子系统调用;
  • 效率问题:每个子系统提供的接口参数和实现都有一些细微的差别,导致每次都需要重新设计接口和联调接口,开发团队和测试团队花费了许多重复工作量。

基于以上背景,我们需要引入消息队列进行系统解耦,将目前的同步调用改为异步通知。

需求分析

需求分析主要全方位地描述需求相关的信息

5W

5W 指 Who、When、What、Why、Where。

  • Who:需求利益干系人,包括开发者、使用者、购买者、决策者等。
  • When:需求使用时间,包括季节、时间、里程碑等。
  • What:需求的产出是什么,包括系统、数据、文件、开发库、平台等。
  • Where:需求的应用场景,包括国家、地点、环境等,例如测试平台只会在测试环境使用。
  • Why:需求需要解决的问题,通常和需求背景相关

消息队列的 5W 分析如下:
Who:消息队列系统主要是业务子系统来使用,子系统发送消息或者接收消息。
When:当子系统需要发送异步通知的时候,需要使用消息队列系统。
What:需要开发消息队列系统。
Where:开发环境、测试环境、生产环境都需要部署。
Why:消息队列系统将子系统解耦,将同步调用改为异步通知。

1H

这里的 How 不是设计方案也不是架构方案,而是关键业务流程。消息队列系统这部分内容很简单,但有的业务系统 1H 就是具体的用例了,有兴趣的同学可以尝试写写 ATM 机取款的业务流程。如果是复杂的业务系统,这部分也可以独立成用例文档

消息队列有两大核心功能:

  • 业务子系统发送消息给消息队列。
  • 业务子系统从消息队列获取消息。

8C

8C 指的是 8 个约束和限制即 Constraints,包括性能(Performance)、成本(Cost)、时间(Time)、可靠性(Reliability)、安全性(Security)、合规性(Compliance)、技术性(Technology)、兼容性(Compatibility)

需求中涉及的性能、成本、可靠性等仅仅是利益关联方提出的诉求,不一定准确;如果经过分析有的约束没有必要,或成本太高、难度太大,这些约束是可以调整的。

消息对列的约束限制如下:

  • 性能:需要达到 Kafka 的性能水平。
  • 成本:参考 XX 公司的设计方案,不超过 10 台服务器。
  • 时间:期望 3 个月内上线第一个版本,在两个业务尝试使用。
  • 可靠性:按照业务的要求,消息队列系统的可靠性需要达到 99.99%。
  • 安全性:消息队列系统仅在生产环境内网使用,无需考虑网络安全;如消息中有敏感信息,消息发送方需要自行进行加密,消息队列系统本身不考虑通用的加密。
  • 合规性:消息队列系统需要按照公司目前的 DevOps 规范进行开发。
  • 技术性:目前团队主要研发人员是 Java,最好用 Java 开发。
  • 兼容性:之前没有类似系统,无需考虑兼容性。

实际操作的时候每个约束和限制都要有详细的逻辑推导,避免完全拍脑袋式决策

复杂度分析

分析需求的复杂度,复杂度常见的有高可用、高性能、可扩展等

识别复杂度

高可用

对于微博子系统来说,如果消息丢了,导致没有审核,然后触犯了国家法律法规,则是非常严重的事情;对于等级子系统来说,如果用户达到相应等级后,系统没有给他奖品和专属服务,则 VIP 用户会很不满意,导致用户流失从而损失收入,虽然也比较关键,但没有审核子系统丢消息那么严重。

综合来看,消息队列需要高可用性,包括消息写入、消息存储、消息读取都需要保证高可用性。

高性能

用户每天发送 1000 万条消息,那么微博子系统一天会产生 1000 万条消息,平均一条消息有 10 个子系统读取,那么其他子系统读取的消息大约是 1 亿次。
将数据按照秒来计算,一天内平均每秒写入消息数为 115 条,每秒读取的消息数是 1150 条;
再考虑系统的读写并不是完全平均的,设计的目标应该以峰值来计算。
峰值一般取平均值的 3 倍,那么消息队列系统的 TPS 是 345,QPS 是 3450。
考虑一定的性能余量,由于现在的基数较低,为了预留一定的系统容量应对后续业务的发展,我们将设计目标设定为峰值的 4 倍,因此最终的性能要求是:TPS 为 1380,QPS 为 13800。
TPS 为 1380 并不高,但 QPS 为 13800 已经比较高了,因此高性能读取是复杂度之一。

可扩展

消息队列的功能很明确,基本无须扩展,因此可扩展性不是这个消息队列的关键复杂度。

备选方案

备选方案设计,至少 3 个备选方案,每个备选方案需要描述关键的实现,无须描述具体的实现细节。

  • 备选方案 1:直接引入开源 Kafka
    此处省略方案描述

  • 备选方案 2:集群 + MySQL 存储
    此处省略方案描述

  • 备选方案 3:集群 + 自研存储
    此处省略方案描述

备选方案评估

备选方案 360 度环评。注意备选方案评估的内容会根据评估会议的结果进行修改,也就是说架构师首先给出自己的备选方案评估,然后举行备选方案评估会议,再根据会议结论修改备选方案文档。

备选方案及评估

架构设计模板

备选方案评估后会选择一个方案落地实施,架构设计文档就是用来详细描述细化方案的

总体方案

总体方案需要从整体上描述方案的结构,其核心内容就是架构图,以及针对架构图的描述,包括模块或者子系统的职责描述、核心流程。

架构总览

架构总览给出架构图以及架构的描述

核心流程

  • 消息发送流程
    此处省略流程描述

  • 消息读取流程
    此处省略流程描述

详细设计

详细设计需要描述具体的实现细节

高可用设计

  • 消息发送可靠性
    此处省略具体设计内容

  • 消息存储可靠性
    此处省略具体设计内容

  • 消息读取可靠性
    此处省略具体设计内容

高性能设计

此处省略具体设计

可扩展设计

此处省略具体设计

如果方案不涉及,可以简单写上“无”,表示设计者有考虑但不需要设计;否则如果完全不写的话,方案评审的时候可能会被认为是遗漏了设计点

安全设计

消息队列系统需要提供权限控制功能,权限控制包括两部分:身份识别和队列权限控制。

  • 身份识别
    省略具体内容

  • 队列权限
    省略具体内容

其他设计

其他设计包括上述以外的其他设计考虑点,例如指定开发语言、符合公司的某些标准等,如果篇幅较长,也可以独立进行描述。例如:

  • 消息队列系统需要接入公司已有的运维平台,通过运维平台发布和部署。
  • 消息队列系统需要输出日志给公司已有的监控平台,通过监控平台监控消息队列系统的健康状态,包括发送消息的数量、发送消息的大小、积压消息的数量等,详细监控指标在后续设计方案中列出。

部署方案

部署方案主要包括硬件要求、服务器部署方式、组网方式等。例如:

消息队列系统的服务器和数据库服务器采取混布的方式部署,即:一台服务器上,部署同一分组的主服务器和主 MySQL,或者备服务器和备 MySQL。因为消息队列服务器主要是 CPU 密集型,而 MySQL 是磁盘密集型的,所以两者混布互相影响的几率不大。

硬件的基本要求:32 核 48G 内存 512G SSD 硬盘,考虑到消息队列系统动态扩容的需求不高,且对性能要求较高,因此需要使用物理服务器,不采用虚拟机。

架构演进规划

通常情况下,规划和设计的需求比较完善,但如果一次性全部做完,项目周期可能会很长,因此可以采取分阶段实施,即:第一期做什么、第二期做什么,以此类推。例如:

整个消息队列系统分三期实现:
第一期:实现消息发送、权限控制功能,预计时间 3 个月。
第二期:实现消息读取功能,预计时间 1 个月。
第三期:实现主备基于 ZooKeeper 切换的功能,预计时间 2 周。

--------来源《极客课程》∙ 学习摘要

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
(本文档为软件开发设计文档模版,由项目设计人员编写,主要读者为项目需求提出者、项目设计人员、项目开发人员、项目测试人员等,通过本文档要能使读者初步了解项目内容及最终成果) 1 项目背景与目标 (简要叙述本项目的背景及本项目最终要达到的目标) 研发xxx系统。根据用户需求,提供安全、简单和使用友好的B2C电商系统,该系统包括: (1) XXX子系统:XXXX(简述主要功能和作用); (2) XXX子系统:XXXX(简述主要功能和作用)。 2 系统总体目标 2.1 系统建设原则 (逐条列举网站的建设原则,并对每一原则做简要说明) (1) 统筹规划,统一设计 ……………… (2) 功能实用 项目建设要力争做到技术先进,根据实际需求确定项目各项功能。 (3) …… …………………………………… 2.2 性能及要求 (简述网站对性能方面的要求,并作简要说明,如兼容性、安全性等等) 兼容性:对硬件要求低,对软件依赖少。 配置灵活:………………………… 安全性:………………………… XXX:…………………… …………………… 3 系统总体架构 3.1 系统逻辑架构图 (简要叙述本系统的构成部分有哪些,然后以图的方式绘制出系统整体架构) 根据XXX系统的建设需求,应用软件平台主要包括XXX子系统、XXX子系统、XXX子系统和XXX子系统。整个系统的逻辑结构如图 1所示。
Java软件架构设计文档是用于描述Java应用程序的整体结构和组织方式的文档。下面是一个常见的Java软件架构设计文档模板的示例: 1. 引言 - 文档目的:说明文档的目标和范围。 - 文档背景:描述项目的背景和上下文。 - 定义、缩写和术语:列出在文档中使用的定义、缩写和术语。 2. 系统概述 - 系统目标:描述系统的整体目标和预期结果。 - 系统范围:说明系统的边界和功能范围。 - 系统架构图:展示系统的高级组件和它们之间的关系。 3. 架构设计 - 架构风格:描述所采用的架构风格,如分层、微服务等。 - 关键设计原则:列出在设计过程中遵循的关键原则。 - 主要组件:描述系统的主要组件及其职责。 - 数据流和处理流程:说明数据在系统中的流动和处理过程。 - 接口定义:定义组件之间的接口和通信方式。 4. 技术选择 - 编程语言和框架:列出所选用的编程语言和相关框架。 - 数据库和存储:描述所选用的数据库和数据存储方案。 - 第三方库和工具:列出所使用的第三方库和工具。 5. 部署架构 - 硬件需求:描述系统所需的硬件资源。 - 软件需求:说明系统所需的软件环境和依赖。 - 部署图:展示系统在不同环境中的部署方式。 6. 性能和可扩展性 - 性能目标:定义系统的性能指标和目标。 - 扩展性策略:描述系统如何支持水平和垂直扩展。 7. 安全性考虑 - 安全需求:说明系统的安全需求和风险评估。 - 访问控制:描述系统中的访问控制策略和机制。 - 数据保护:说明系统中敏感数据的保护措施。 8. 高可用性和容错性 - 高可用性策略:描述系统如何实现高可用性。 - 容错机制:说明系统中的容错策略和机制。 9. 监控和日志 - 监控指标:定义系统的监控指标和报警规则。 - 日志记录:说明系统中的日志记录方式和级别。 10. 参考资料 - 列出在设计过程中参考文档、书籍和网站。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值