一个架构评审文档模板

图片来自pixabay.com的Alexas_Fotos会员

架构评审作为项目研发的一个重要节点,一般发生在项目立项之后、正式的代码开始开发之前,由开发人员从架构的角度思考项目落地方案的合理性、规范性、可行性、可扩展性,使得能够在项目的前期解决架构问题,避免在后期、代码开发完成之后发生大量的返修改造工作,并让测试、运维、平台架构等相关的团队尽早介入项目的推进过程中。

为了让架构评审能够顺利组织运作,好的架构评审模板是关键点。

本文提供一个架构评审模板,本模板从实践中逐步总结而来,供技术团队参考。有几个需要关注的方面是,

  1. 和技术评审文档相比,架构评审文档是以架构师的视角来编写,体现了架构师对项目的整体理解和设计。架构评审文档关注架构设计,技术评审文档关注实现细节。
  2. 作为模板,其一般包含了架构评审所需要的方方面面,在实践过程中,并不是所有部分都需要一一列出,只需列出期望被架构评审的要点即可,无须求全。
  3. 在架构评审会议之前,建议对待评审的架构评审文档先做个快速审查,确认符合评审的要求。好的架构评审文档对架构设计有明确描述,能够帮助大家快速理解,并进入架构要点讨论。

1. 业务/功能简介

简要描述当前功能需求,其目标和意义,建议提供相应的业务主流程图。

2. 架构设计

描述当前项目的组件架构设计,包括物理架构和逻辑架构,用于评审架构是否合理,是否可行,是否符合规范。

2.1 物理架构

绘制应用服务的物理部署架构,以网络拓扑为主线,列出内外网访问的HTTP域名,内部RPC调用主链路。
主要用于查看部署架构是否高可用部署,是否支持水平扩展。
对于有网络流量治理的设计,比如限流和熔断,可以在物理部署架构图中进行说明,描述其网络调用情况和流量治理方案。

2.2 逻辑架构

绘制应用服务的逻辑架构,以组件的上下调用关系为主线,列出所有设计的应用组件和调用链,说明各个逻辑模块的职责功能,及其上下依赖情况。
主要用于查看组件的上下依赖关系是否合理,各个组件是否承载了合理的功能交互。
对核心流程,需要绘制调用时序图。

3. 数据模型和类设计

3.1 数据表ER数据模型设计

描述当前核心数据库表的关系大图,包括关联字段、关联关系(一对一、一对多、多对多)。

3.2 核心类设计

描述当前业务的抽象类、接口类设计,包括其相关继承和组合、实现关系,以及相关类设计模式的应用。

4. 技术难点设计

4.1 高并发场景

对于有大流量访问的项目,需要提供对流量的预估,描述支撑高并发场景的技术方案,包括缓存、异步消息、线程池配置等等,评估并发下的数据线程安全;
对于核心业务链路,还需要考虑相应的治理监控手段,比如限流熔断降级策略。

4.2 数据一致性场景

对于有对数据一致性要求的项目,比如交易、支付等场景,需要考虑相应实现的技术方案,包括数据库事务、消息事务等等。

4.3 数据大表设计

每天的数据记录多少,是否考虑分库分表,归档策略

  • 每天的数据增量多少?
  • 是否需要读写分离?
  • 是否需要分库分表?
  • 是否可以归档?若归档,保留多久的记录?

4.4 慢接口说明

对于单接口运行时间大于10秒的,需要单独列出进行评审。注:这里的10秒为业务入口网关的接口超时时间。

5. 运维设计

5.1 新应用和新域列表

若有新增应用或新域名,列出并说明相关信息,包括AppId、应用框架、功能等。

5.2 运维成本

列举所需的机器硬件配置,硬件成本,软件成本等。

5.3 监控接入

日志监控:是否接入日志和监控平台
告警设置:是否接入告警平台
健康检查接口:是否提供健康检查接口

5.4 可维护性

是否有新引入组件和技术栈?
是否符合发布标准?
是否可以快速水平扩展?
是否接入健康自检?

5.5 安全性

网络:当前的网络调用是否安全?是否需要配置白名单访问?是否遵循产品设计与开发安全红线?
软件:使用的第三方软件框架是否安全?(列出第三方软件、框架、组件,开源协议)

6. 其它

上述文档列出架构评审的基本要点,若有更多方面,可以在本评审模板的基础上进行增减内容。

发表评论

邮箱地址不会被公开。 必填项已用*标注

*

code