自从5月8号写完架构设计三部曲第一部架构设计规范如何写，到现在已经快20天了。这段时间主要是准备接下来系统分析师的考试，当然还有各种工作杂务，所以拖到现在才写第二篇如何审核架构设计规范。当然，这是从复习的角度来说。其实从编写架构设计规范的角度，也可以说明架构设计规范怎么写。就像高考作文一样，复习总是有一些要点的，那么对于架构设计规范的编写，我们应该准备哪些要点呢？编写过程中要注意哪些章节和内容？这就是我接下来要和大家分享的。根据第一篇，我们知道一个架构设计规范的一般章节应该是这样的：等章节；总体架构：主要从整个IT层描述系统的位置，以及与周边相关系统的调用关系；逻辑架构：系统内部功能模块的划分，各模块的功能介绍，以及它们之间关系的表达；接口设计：包括系统之间的接口设计和内部功能模块之间的接口设计；数据架构：系统与上下游系统的数据流转关系，以及系统的关键数据表设计和数据管理策略；技术架构：实现这个架构需要什么技术能力、复用能力和风险；部署架构：如何部署系统，对网络拓扑有什么要求，对硬件服务器有什么要求，需要多少，是否需要优化服务器参数；非功能性性能设计：性能、高可用性、可扩展性、可维护性、安全性、可移植性等。其他解释：如特殊约束、风险考虑、进度要求、政策限制、环境影响等；那么我们依次看看每一章，在审核过程中需要注意哪些问题，写架构设计规范的人具体需要提供什么内容：（1）文档概述对架构设计规范进行说明本身，需要清楚地说明本文档的背景，即为什么有本文档，文档的内容范围，预期的读者，包括哪些文档需要同时引用，哪些Terminology等需要需要说明的，可以写成两级标题。内容形式为：本文档是对XX系统阶段XX项目的架构设计/升级/变更进行说明，主要从总体架构、逻辑架构、接口设计等方面进行说明。..对系统各个架构维度的内容进行了多方面的详细描述，期望读者为项目经理、架构经理、运维人员等，可参考XX需求书、XX架构设计规范等.在准备过程中；审查一般会注意：是否从架构的角度解释了文档的目的和内容范围；否则，参考文档中提到《用户需求规格说明书》、业务知识文档等；术语是否解释了非通用和非IT缩写；整章解释是否清晰文档的整体介绍使读者对整篇文章有一个大概的了解。(2)总体架构描述了系统在架构设计上的总体思路和策略，如采用分层架构、B/S架构、服务、数据分离等，以及设计过程中的一些约束条件，如网络接入约束、开发规范约束、开源产品协议类型等。更重要的是，作为整体架构，系统必须被视为一个内部不透明的整体，必须明确与其交互的外部系统，具体之间的关系外部系统交互实现有什么要求？比如通过消息总线获取客户信息，通过企业内容管理访问非结构化数据，通过CRM获取客户信息等，画出整个以这个系统为中心的交互关系图，即整体架构图。评审一般会关注：设计方案是否清晰，是否与实际设计内容一致；对应的约束是否真实、具体、可查；能否从整体架构图中看出系统需要与哪些系统进行交互，交互的目的是什么；系统之间的交互是否正确，外部系统是否可以满足交互，比如通过CRM获取客户信息，获取组织信息是否可行。(3)逻辑体系结构逻辑体系结构关注的是如何将系统划分成不同的部分以及各部分如何交互。它规定了软件系统由哪些逻辑元素组成，以及这些逻辑元素之间的关系（层、子系统、模块等）等的划分决定+交互接口和交互机制[方法调用、RMI、消息]），所以逻辑架构图需要明确系统包含哪些功能模块，模块之间如何交互，交互的目的是为了实现什么业务需要。同时，对于具体的功能模块，需要详细阐明功能模块的业务意义。审核一般会关注：逻辑架构图是否列出了功能模块以及模块之间的交互；什么业务需要。(4)界面设计架构设计中的界面设计包括两个方面。一方面是指系统与外部系统之间的外部接口关系。需要列举所有与外部系统的接口，并对每个外部系统进行详细的解释。接口名称（如XX数据推送接口）、交互系统名称（如ODS）、交互方式（如Webservice）、交互类型（如后台异步）、接口描述（如本系统通过此从ODS获取XX接口）业务数据）；另一方面是指系统内部功能模块之间的内部调用关系。严格来说，这部分是逻辑架构的一部分。还需要列举每个功能模块的所有实际调用，依次解释。内部接口名称（如报表服务接口）、调用模块（即主动发起内部调用的功能模块，如展示模块）、服务模块（即提供服务的模块），如报表模块），以及接口说明（如展示模块通过此接口从报表模块获取报表数据，实现模块间解耦）。一般来说，内部接口调用属于代码层面。如果需要独立部署的模块使用远程调用，需要特别说明。接口是系统复杂性的体现，是体现高内聚低耦合设计原则的一个非常重要的方面。审查一般会关注：是否列出了所有的外部和内部接口，接口的各个维度的元素是否按照上述进行。界面。(5)数据结构数据处理是系统的最终目标。系统在处理过程中可能需要外部数据的协助。同时，系统处理完数据后，可能还需要提供给其他系统。因此，数据结构最重要的是明确系统处理的数据在整个业务数据流链中的位置，哪些上游系统为系统提供数据，哪些下游系统需要使用的数据系统。另外，关于系统对数据的处理，需要说明系统设计了哪些关键表，数据初始化的方法，如何做数据冗余，如何做备份等，复习一般会重点on：是否从业务数据流的角度明确描述了系统数据与上下游系统数据的关系；针对系统承载的业务处理，设计了哪些关键实体数据表及其对应的表，是否能够全覆盖；系统是否有数据量预估和数据初始化、数据归档方式、备份策略等。（6）技术架构从技术角度描述系统实现过程中使用的关键技术能力和核心技术组件，包括成熟的商业套件和开源技术产品。如果是商业套件，需要说明使用限制、升级支持等，如果是开源技术，需要说明开源协议的要求。它可以基于分层架构的模型。比如表现层使用JQuery、Flex等，逻辑控制层使用spring、json等，这一定是技术上的问题。对于具体使用的组件，必须说明组件的版本、功能、适用场景。当然，可重用性是技术架构的关键。无论是使用以前的组件还是开源产品，都利用可重用性来减少资源的重复投入。因此，有必要在技术组件中强调可重用性的重要性。评审一般会关注：是否对关键技术进行了说明，能清楚表达该技术的成熟度和适用性；某些技术的使用是否与企业常用的同类技术有冲突，如redis，企业内其他系统经常使用，而本系统确实使用了memcached；(7)部署架构明确系统分为几个物理部分，每个部分需要若干台服务器，服务器是集群模式一起提供服务还是一个Master提供服务一个备份-Slave模式，或一种读写分离的方式，一个负责写入，多个设备负责读取。从网络的角度，系统在整个企业网络环境中所处的位置，如外联区、DMZ区或内网区等。对于所需的服务器，需要说明软硬件配置信息服务器的硬件，多少核，多少内存，硬盘大小，网络端口数量和网络带宽要求，软件对操作系统的要求，版本要求，系统和软件参数调整优化设置等；是否预装第三方软件，所需软件的版本，部署说明等。审核一般会关注：是否可以从部署架构图中看出系统被分成几个部分进行物理部署;部署部分之间的服务器之间的协作关系；硬件服务器的型号、配置、数量是否清楚；整体部署的网络区域是否清晰；是否需要说明相关参数的调优和特殊的部署要求。(8)非功能性描述系统的非功能性包括性能、高可用性、可扩展性、可维护性、安全性和可移植性。一般来说，对于性能或安全性要求较高的系统，可以将其作为一级章节独立编写。例如，实时分析系统需要性能，交易系统需要安全。性能和安全可以描述为独立的章节，其他非功能性的特性也可以类似处理。在写的过程中，可以对主次进行阐述，但一定要从系统的实现出发，即需要描述清楚系统做了哪些设计或优化来满足性能，以及什么样的验证机制是为了保证安全性，如何通过集群或者双机热备部署来保证可用性，如何讲过去的状态实现可扩展性等等，这些设计在系统中是如何实现的。即从系统如何满足非功能需求的角度出发，而不是去解释具体的非功能需求是什么。评审一般会关注：非功能性的描述是从系统如何实现的角度，而不是系统的需求；每一类非功能都可以从需求中找到对应的需求点，与实际业务相匹配；系统非功能性的实现与系统本身的结构不冲突，通过合理调整可以满足结构；非功能性评审需要根据不同系统的业务特点进行评审。毕竟架构设计是为了指导后续系统建设的实施。（九）其他说明本章主要说明一些辅助约束或环境，如制约因素、风险考虑、进度要求、政策限制、环境影响等，可根据实际情况和可预见情况编写。如对整体系统的高层要求、开发资源约束、业务环境影响、人员知识结构等。审核过程一般不针对具体事项，除非系统有特殊要求。以上是整个架构设计手册的回顾内容，也是各章编写的指导思想。我根据实际工作中的一些经验粗略总结了一下。不一定全面，但对整个编译会有帮助。我会和你一起讨论和研究。
