作者: Anders小明
在牛津高阶词典(第7版)中,架构(architecture)一词的解释是:the design an structure of a computer system。这个解释实际上已经描述了架构的本质:架构是关于怎么做(构成系统)的,而非做什么的。更进一步,架构是由人来设计实施,因此架构实际上是一个文化(culture)——我们怎么认识或理解系统/产品的,并且我们准备怎么做,在做的过程中我们认为什么是好的,什么是好的等等。
任何系统都有架构,无论多小的系统都有。区别在于其架构是否是经过明确设计并表达。一个合理的架构无疑是经过精心设计和维护的,而进行架构设计,或者说定义/建立一个架构可以分为如下几个步骤。
特别的,本文针对于企业应用架构,其他应用未必适用。
基线准备
如果建立第一版架构(即从零开始)可以跳过此步,但对于建立第n版(n>=2)架构,则需要进行基线准备。通常从上一个架构设计开始,去除不在必要的内容作为基线。
非功能性需求的收集、分析和细化
这步骤非常关键,本质上架构关注的是系统的非功能性需求,虽然不是系统的全部,但无疑是最重要的20%,而这也是不同公司/产品的架构差异性的根源。
一个完整的非功能性需求列表不仅仅来自业务部门(系统客户),还需要包括开发/研发管理层以及开发团队。实践中可以如下检查列表来帮助收集:
l 目标应用,企业应用和互联网应用就不太相同
l 目标环境,系统部署的硬件环境、网络环境等,更有云计算环境和传统服务器环境的差异。
l 常见技术指标
n 稳定性/可用性,主要是MTBF和MTBR指标要求
n 性能,如Web应用下单次操作1/5/10原则,相关并发压力要求等
n 容量,主要是数据容量,此外有时还要考虑内存的限制
n 实时性,涉及到数据同步/复制/消息传播/异步操作
n 易用性,这个指标不容易衡量
l 系统/项目/产品自身,来自客户
l