引言
架构评审作为公司必不可少的一环，越早发现问题，修改软件项目的代价也就越小，尽可能多地发现隐患是架构评审的目的。当然，设计出的项目就像自己的“孩子”，特别不希望别人“挑刺”，都要说好，心里才舒服，但是，为了自己的“孩子”更能茁壮成长，面对“挑刺”，应该是相爱的过程，同时也是相互学习的过程。
评审的标准
-
技术选型 *****
技术选型的重要程度不言而喻，为避免重复造轮子，公司内部已有的公共组件或服务是否满足需求，为此我们提供了组件或服务的检视清单。
如果要引入开源组件，除了业务数据量，业务需求为依据作为技术选型的标准，开源的框架还应该考虑几个硬性的指标，用什么语言，考虑到如果公司没有这个语言的高手，开源软件出问题了是否能够快速解决；开源作者最近是否还在维护；开源社区是否活跃，用此开源软件的生态是否多；开源协议是否支持修改以及能否商用；
自己用python写了个github技术选型的辅助小工具
-
性能 ****
任何抛开业务谈性能，都是耍流氓。比如预计的QPS、TPS,RT多少，数据量能达到多少，可能涉及到技术选型以及部署的不同，那么预计是怎么个估法呢，我觉得主要考虑未来3年的使用情况，就可以了。因为公司的基本的应用技术基础框架已经确定了，更多的可能是考虑数据量的问题。
-
可靠性 *****
避免单点故障，如要达到5个9，涉及到设计自动恢复机制。
-
兼容性 *****
是否向后兼容，此次的性能对其他系统的影响是哪些，是否会导致其他系统的不可用或者调用错误。
-
安全性 *****
提供安全检视清单，主要涉及是否有XSS攻击、DDOS攻击、SQL注入、安全的用户体系（密码是否明文传输，密码是否可以暴力破解）；敏感数据是否脱敏；是否有操作日志（日志审计）；涉及外网，提前申请域名以及https证书。
-
可扩展性 ****
可扩展性主要分为系统的可扩展性和代码的可扩展性，系统的可扩展性，考虑是否是无状态的服务，可方便增加，减少节点；代码的可扩展性主要在代码走查部分完成。
评审的内容
- 应用架构图
应用架构主要以架构图的方式描述系统的组成和框架，一般从系统功能和系统技术层次两个架构视角进行设计。
实际操作中架构图只要描述清楚了就可以了，看用什么比较详细的描述，如果整个系统比较庞大，则可以这样：
如果只是某个模块的变动，则附上之前评审过的整个系统的架构图，并体现出该模块是属于整个系统架构图的哪块。再对变动的该模块画C4模型的架构图，建议小模块的架构图，都可以用C4模型把系统上下文以及调用关系描述清楚，如
- ER图
ER图不是把数据库罗列出来，更多的是体现实体之间的关系 如
- 流程图
关键的且复杂性高的部分，可以画一个业务的流程图，也可以是时序图、状态图来表示，更加清晰。
- 部署架构图
略。
参考： 架构图如何画：www.cnblogs.com/xiang--liu/…
