朱晔的互联网架构实践心得S1E9：架构评审一百问和设计文档五要素

朱晔的互联网架构实践心得S1E9：架构评审一百问和设计文档五要素

【下载文本PDF进行阅读】

 

本文我会来讲说我认为架构评审中应该看的一些点，以及我写设计文档的一些心得。助你在架构评审中过五关斩六将，助你写出能让人收藏点赞的设计文档。

 

技术架构评审

 

架构评审或技术方案评审的价值在于集众人的力量你们一块儿来分析看看方案里是否有坑，方案上线后是否会遇到不可逾越的重大技术问题，提早尽量把一些事情先考虑到提出质疑其实对项目的健康发展有很大的好处。不少公司都有架构评审委员会都有架构评审的流程，作业务的兄弟要么看到这个流程每每心惊胆战惧怕本身作的方案被毙了咋整，要么就是认为这是一种过场，随便糊弄一点文档发给委员会看一下就算过去了。我作过架构评审委员也作过提交评审方案的业务兄弟，无论哪一个角色我都不惧怕而是喜欢这一流程，评审这个事情作的好其实能够很享受，你们都是一块儿学习的过程，不存在谁为难谁。下面说说我以为架构评审（非代码评审）中看重的须要评审的一些点。

 

组件选型

• 为何选A不选B呢？
• A不是开源的，出了问题怎么办？
• B虽然是开源的，可是是Erlang写的，公司没人能看懂怎么办？
• C我看待解决的Issues还有不少，有没有去了解过？
• 这个组件在性能方面你是否了解过？
• 开源的免费版本不支持集群怎么办？
• 若是完全要本身写这个组件有没有可能性？

组件特别是存储组件选型挺重要的，真心建议事先能够有那么几周的时间搭一个高可用的集群，使用接近于真实的数据对组件进行压测（你看以前我博客上的Mongodb的压测文章停火的，说明不少人没有这个时间和条件对一些组件进行压测）。眼见为实耳听为虚，本身经过压测对比一下本身得出的数据和公开的数据是否有差别，若是有的话说不定还能发现本身使用上的一些问题。尽可能仍是选用使用的人多的开源组件吧，出了问题至少Patch不会来的太慢。

 

性能

• 咱们需求的TPS、QPS和RT是多少？
• 总体设计上会作到的TPS、QPS和RT是多少？
• 随着数据量的增大系统性能会不会出现明显问题？
• 系统哪一个环节会是最大的瓶颈？
• 是否打算作压力测试，压力测试方案是怎么样的？
• 怎么提升前端用户的访问流畅性？

对于重要的项目，建议作一下总体压测，没有通过压测得出来的估计的结论每每多是错的，咱们总觉得最终会死在最后的存储上，可是极可能早早就死在了程序的低级错误上，好比在一些存储组件的Client使用上，若是没把控好最佳实践（把应该做为单例使用Clinet每次都去建立一次，默认的线程数小的可怜应该从新配置可是保留了默认值），死的很是难看。

 

可伸缩性

• 每个环节是否都是能够横向扩展的？
• 扩容须要怎么作手动仍是自动？
• 数据库不能横向扩展怎么办？
• 纵向扩展有多少效果？
• 横向扩展是不是线性的？
• 扩展后是否能够提升响应速度？

 

灵活性

• 是否有了解过产品层面之后会怎么发展？
• 模块A是否能拆分出去独立为其它业务服务？
• 模块B是否能够替换为另外一种第三方数据源？
• 若是流程有变，须要多大的工做量来适应？
• 业务是否能够作到可配？
• 为何A和B都有差很少的逻辑？
• 是否考虑到了A业务的实现之后还有B的可能性？
• 若是如今有两种策略之后扩展到了八种策略怎么作？
• 之后是否能够把这个业务的H5前端适配到PC？

可扩展性

• 为何A和B都有差很少的逻辑？
• 是否考虑到了A业务的实现之后还有B的可能性？
• 若是如今有两种策略之后扩展到了八种策略怎么作？
• 之后是否能够把这个业务的H5前端适配到PC？

可靠性

• 是否架构中有单点？
• 故障转移是怎么实现的？
• 集群内部故障转移须要多久？
• MQ或存储出现问题的时候系统会怎么样？
• MQ或存储出现问题又恢复了系统是否会本身恢复？
• 是否考虑过异地故障转移的方案？
• 是否考虑过多活的方案？
• 是否有数据丢失的可能性？
• 数据丢失后是否能够恢复？
• 系统完全挂了对其它业务的影响是什么？
• 系统完全挂了是否能够有线下的方式走业务？

 

安全性

• 是否完全避免SQL注入和XSS？
• 是否作了风控策略？
• 是否有防刷保护机制？
• 数据库拖库了会怎么样？
• 是否有数据泄露的可能性？
• 数据的权限怎么控制的？
• 功能的权限是怎么控制的？
• 是否作了日志审计？
• 受到了DDOS攻击怎么办？
• 数据传输是否加密验签？

 

兼容性

• 老的系统打算怎么办？
• 怎么进行新老系统替换？
• 新老系统可否来回切换？
• 别的系统怎么链接你这套新服务？
• 上下游依赖是否梳理过，影响范围多大？
• 上下游改造的难度怎么样？
• 上下游改造有排期吗？
• 上下游改造的计划和通知时间肯定了吗？
• 使用了新的数据源数据怎么迁移？
• 使用了新的技术老项目开发可否适应？

 

弹性处理

• 这个数据重复消费会怎么样？
• 这个接口重复调用会怎么样？
• 是否考虑了服务降级？哪些业务支持降级？
• 是否考虑了服务熔断？熔断后怎么处理？
• 是否考虑了服务限流？限流后客户端表现怎么样？
• 队列爆仓会怎么样？
• 是否考虑了隔离性？

 

事务性

• 这段业务由谁保证事务性？
• 数据库事务回滚后会怎么样？
• 服务调用了失败怎么办？
• 队列补偿怎么作的？
• 服务调用补偿怎么作的？
• 数据补偿实现最终一致须要多久？
• 在数据不完整的时候用户会感知到吗？

 

可测试性

• 测试环境和线上的差别多大？
• 是否支持部署多套隔离的测试环境？
• 是否打算作单元测试，覆盖率目标是多少？
• 测试黑盒白盒工做量的比例是怎么样的？
• 是否支持接口层面的自动化测试？
• 是否有可能作UI自动化测试？
• 压测怎么造数据？
• 是否能够在线上作压测？
• 线上压测怎么隔离测试数据？
• 是否有测试白名单功能？

 

可运维性

• 每个组件对服务器哪方面的压力会最大？
• 从新搭建整套系统最快须要多少时间？
• 系统是否能够彻底基于源代码构建？
• 系统是否有初始化或预热的环节？
• 系统里哪些环节须要人工参与？
• 数据是否须要按期归档处理？
• 会不会有突发的数据量业务量增大？
• 随着时间的推移若是压力保持不变的话系统须要怎么来巡检和维护？
• 怎么在容器里进行部署？

 

监控

• 业务层面哪些指标须要监控和报警？
• 应用层面系统内部是否有暴露了一些指标做监控和报警？
• 系统层面使用的中间件和存储是否有监控报警？
• 是否全部环节都接入了全链路跟踪？
• 出现报警的时候应该由谁来处理？
• 每个模块是否有固定的主要和次要负责人？
• 有没有可能系统出了问题没法经过监控指标体现？
• 哪些指标须要上大屏由监控进行7*24监控？

 

 

看了这么多问题可能会以为这架构设计是无法作了，其实不一样阶段的项目有不一样的目标，咱们不会在项目起步的时候作99.99%的可用性支持百万QPS的架构，高效完成项目的业务目标也是架构考虑的因素之一。并且随着项目的发展，随着公司中间件和容器的标准化，不少架构的工做被标准化替代，业务代码须要考虑架构方面伸缩性运维性等等的需求愈来愈少，慢慢的这些工做都能由架构和运维团队来接。一开始的时候咱们能够花一点时间来考虑这些问题，可是不是全部的问题都须要有最终的方案。

 

技术设计文档

若是你在Google搜索架构设计文档、技术设计文档、概要设计文档能够搜索到不少模板，不少公司也会以这些模板做为设计文档的模板来让你们填写。对于大部分所谓的项目只是一个项目中的一个小环节是一个具体的业务逻辑，所以老是能够看到你们写的所谓的技术设计文档只能填满文档的20%，其他都不知道怎么写。当你不知道文档应该写哪些内容的时候能够这么来考虑问题，就是你这个项目接下去是要卖给别人来用的，你没有机会当面和他把这个项目说清楚，你只能经过文档来把事情写清楚，别人就给你一次机会，若是看不懂你文档表达的意思，不能理解你的项目，你的项目就卖不出去不值钱，这个时候你必定会从各个角度来剖析你的系统想尽一切办法来把事情说清楚，用这个方法逼一下本身的，你的文档会很优秀。接下去我想说一下若是是个人话我看重技术设计的哪些部分以及这些部分的文档的写做方式，这些内容构成了一个必要的（概要）设计文档，算是抛砖引玉。

 

交代背景和需求全貌

 

 

 

在这里，推荐使用脑图在技术角度给出一下本身理解的项目需求的分布。PRD中的产品功能脑图能够和这里技术角度的脑图有差别，在说清楚需求的同时侧重技术层面，体如今：

• 能够不按照需求的功能点进行归类而是按照实际项目归类，把需求列在实际的项目下面
• 能够区分需求是本身干的仍是调用外部的接口，能够在图上以不一样的形态提现
• 能够画出功能之间的依赖关系，以虚线实线进一步区分依赖的程度
• 能够在图上体现需求的优先级以及需求目前的进展和负责人，这样基本一个图就能够看清楚这个项目须要消耗多少资源须要多久能够结束

看了这个图基本产品需求就能够理解个大概，具体的细节规则能够进一步参考PRD。

 

系统架构图

 

 

 

在本系列文章的第二到第五篇中，我都配了一个架构图。架构图须要传递清楚下面的信息：

• 项目由哪些模块、服务、缓存、存储构成，能够以不一样的图案和颜色表明不一样类型
• 模块之间的依赖关系（固然，也能够从数据的流向角度来画）
• 核心流程的步骤，沿着图上的一、二、3基本就能够大概了解核心流程的实现
• 能够用大的框把组件进行分组来描述组件的部署方式（好比相同机器上承载的组件在一个框内）
• 能够以边框的虚实来分类项目内的组件或三方组件，能够以箭头的虚实来标记主要流程次要流程等等

UML里会有一些具体的分类，什么类图、组件图、部署图等等，我以为没必要拘泥于这些细节，经过线线框框的架构图能把模块和模块之间的关系表述请求，而后再配以必定的文字来讲明每个组件便可。我本身经常使用的是gliffy，只要能说清楚，Word画也能够。根据项目的大小，图上的模块不必定是须要独立部署的进程，模块也能够是项目内部的一个模块或类。对于复杂的项目，要画一个图说清楚很难，能够画一个大的架构图，而后针对每个模块或流程再细化画不一样层次的图。

 

对外API定义

 

 

 

API的详细定义能够由Swagger UI、Spring REST Doc、Miredot等等工具生成，这些生成的接口是按照代码来组织层次关系的，只能体现接口的参数定义不能体现接口的形态等，是没有思想的，不适合用来阅读，只适合用来参考。所以仍是建议作一个脑图来整体阐述一下接口的：

• 分类，按业务功能的分类，按受众的分类等等
• 形式（图上不一样的颜色），同步仍是异步（结果不在响应中，单独的回调返回），单条仍是批量，数据接口仍是页面调用等等
• 重要性（图上文字后的星号），好比重点标记主流程的接口

图上能够不显示出参数清单，但能够以简单的文字来描述重要参数，好比下单接口：->@用户身份，优惠券ID*，[{商品ID,数量}]<-订单号，下单结果（0-失败，1-成功）。（->表明输入，<-表明输出，[]表明数组，@表明隐式参数，*表明可空参数等等）。

以前强调过好屡次涉及到和外部交互的API是设计中很是重要的一个环节，不只仅体现了系统对外输出的能力，也体现了系统设计在安全性、复用性、封装等方面的平衡。

 

交互时序

 

 

 

时序图的表达很是重要，能够表现需求脑图、架构图和API脑图没法表现出来的几个方面，清晰展示了某个事情：

• 关键的利益关系方。这个事情由哪几个方面构成，能够是用户、甲方、乙方这么来分，也能够是用户、APP客户端、服务端这么来分
• 每一方在作什么，依赖的又是什么，整个顺序是怎么样的
• 技术层面这是同步接口、仍是回调、仍是非技术的线下流程
• 还能够在图上表现出可选逻辑，条件判断逻辑，循环逻辑等等

我以为能在比较高的层面说一下技术（对接）流程便可，不必定要详细到类和类之间的交互，类和类之间的交互阅读代码或直接看全链路调用的图就能够。若是项目有多个合做方多个依赖方，项目流程比较复杂，那么序列图是能把这个事情说清楚的最好的方式。

对于这种时序图，采用传统的工具来画费时费力，推荐下面两个工具（https://www.websequencediagrams.com/和http://plantuml.com/sequence-diagram），能够在几分钟内生成须要的图。

咱们输入相似的文字：

title 合做流程

用户->XX:投资YY标的

XX->YY:同步投资状况，更新可用额度

用户->YY:在额度内消费

YY->XX:同步消费状况，更新可用额度，更新回款计划

YY->XX:还款

XX->用户:回款（已消费部分做为手续费给XX）

opt 线下流程

XX->YY:对于YY用户的消费出帐单

YY->XX:对帐确认帐单

XX->YY:打款开具发票

End

网站生成相似的时序图，还能够自由选择本身喜欢的样式：

 

 

数据库ER

 

ER图就是实体联系图。形式上咱们能够在图上表现几个点：

• 实体：哪些表
• 实体上的属性：体现实体之间关系以及实体业务功能的重要字段
• 联系：实体和实体之间的关系，好比一对多，多对一仍是多对多之类

在有的时候咱们能够省略属性的类型定义，甚至能够直接省略具体的属性（实体名和M对N的关系是必须的），把图简化为相似下面的部分：

 

ER图的信息量很是大，绝对不是粘贴一下表结构的DDL能够替代的，缘由是：

• ER图能够以极小的空间展示不少信息，这样咱们能够在图上对业务进行分组，看到全貌
• ER图展示的是表和表之间的关系，一眼能够看出最重要核心的表是哪些

好比下图，是否一眼就能够看明白一套P2P金融业务整个数据结构的架构呢：

 

（随便画的图，不表明任何意义，请不要以这个图作P2P的表结构设计）

 

全部的图，文字只是一个维度，咱们要学会利用边框类型（矩形、圆角矩形），边框样式（虚线，实线），填充色，文字颜色，关联线条粗细颜色样式，框内ICON来增长咱们要表现信息的维度，最多能够增长到6维+，这种能力是文字很难实现的。一图赛过千言，因此我一直认为图是设计文档中很是重要的部分。

 

其它

 

以前我说了咱们能够以五图的形式（需求脑图、架构图、API脑图、序列图、数据库ER图）把系统大概介绍一个底朝天，说清楚了需求、架构、对外接口、交互流程和数据结构设计这几个事情，业务项目说清楚这些足够了。

对于偏向于中间件（无论是基础中间件仍是业务中间件，中台）的项目（而不是业务项目），这里我再补充几个重要的方面，须要在设计文档中有体现：

• 可靠性：是否有单点的组件，非单点的组件如何作故障转移
• 高性能：是否有抗突发性能压力的能力，大概能够知足多少的TPS和QPS，怎么去作来实现高性能
• 可扩展：随着压力上升哪些环节能够作扩展，怎么作扩展
• 安全性：哪些手段防突破，万一突破了后果怎么样
• 兼容性：和遗留系统怎么通信，怎么作迁移
• …………等等方面

这些点我就不一一展开说了，在第一节说架构评审的时候都有提到过，针对那些问题写一下本身的设计是怎么应对的吧。

 

这些点我认为能够构成一个合格的设计文档，文档的形式不重要，重要的是能够把业务的技术实现梳理清楚，确保咱们在开发以前有一个清晰的思路，在开发上线后，文档也是一个后人熟悉系统的很是重要的手段。你可能会提出疑问说这样的设计文档是否是太粗略了一点，彻底没有体现到软件层面设计的细节，没错是这样，可是我一直说的是互联网架构心得，敢问如今互联网项目从0开始的大项目1到2个月上线，大的版本迭代2周一次，若是设计的时间是五分之一的话，设计也就是2天到一周这样子，咱们有多少时间和能力来细化文档呢，若是能把我这里说的五要素都作好，对于互联网项目已经笑死。

还有一点每每会比较惋惜，咱们或许能够作到在开发以前有一个概要设计文档的产出，可是咱们很难作到在系统上线后随着迭代还能继续维护初版产品上线时那个大而全的文档。随着产品的迭代，咱们的技术文档也像PRD迭代文档同样只说此次迭代的技术改动的话，这种设计文档由于没有全局观意义不大。对于这个状况，我以为对于每一条业务线的产品，我都建议咱们至少能维护大而全的下面这些文档的全量版本：

• 完整表结构（顺带标一下归档方案、重要程度）
• 需求全貌
• 对外产品能力输出全貌
• 总体架构图
• 关键业务交互流程（特别是那种很难说清楚的多方结算关系）

按期回顾一下这五个文档，根据最近的需求改改，可能也只须要花费几小时的时间，对于大项目其意义每每是新人的灵魂导师（以前我有画过一个比较复杂系统的架构图，这个架构图我看到有人作了桌面）。