如何定义和建立架构.doc

在牛津高阶词典（第7版）中，架构（architecture）一词的解释是：the design an structure of a computer system。这个解释实际上已经描述了架构的本质：架构是关于怎么做（构成系统）的，而非做什么的。更进一步，架构是由人来设计实施，因此架构实际上是一个文化（culture）——我们怎么认识或理解系统/产品的，并且我们准备怎么做，在做的过程中我们认为什么是好的，什么是好的等等。任何系统都有架构，无论多小的系统都有。区别在于其架构是否是经过明确设计并表达。一个合理的架构无疑是经过精心设计和维护的，而进行架构设计，或者说定义/建立一个架构可以分为如下几个步骤。?特别的，本文针对于企业应用架构，其他应用未必适用。基线准备如果建立第一版架构（即从零开始）可以跳过此步，但对于建立第n版（n=2）架构，则需要进行基线准备。通常从上一个架构设计开始，去除不在必要的内容作为基线。?非功能性需求的收集、分析和细化这步骤非常关键，本质上架构关注的是系统的非功能性需求，虽然不是系统的全部，但无疑是最重要的20%，而这也是不同公司/产品的架构差异性的根源。一个完整的非功能性需求列表不仅仅来自业务部门（系统客户），还需要包括开发/研发管理层以及开发团队。实践中可以如下检查列表来帮助收集：????????? 目标应用，企业应用和互联网应用就不太相同????????? 目标环境，系统部署的硬件环境、网络环境等，更有云计算环境和传统服务器环境的差异。????????? 常见技术指标????????? 稳定性/可用性，主要是MTBF和MTBR指标要求????????? 性能，如Web应用下单次操作1/5/10原则，相关并发压力要求等????????? 容量，主要是数据容量，此外有时还要考虑内存的限制????????? 实时性，涉及到数据同步/复制/消息传播/异步操作????????? 易用性，这个指标不容易衡量????????? 系统/项目/产品自身，来自客户????????? 管理指标，主要来自管理层????????? 成熟度/培训招聘成本????????? 产品化/定制化????????? 组件化????????? 领域化????????? 标准性????????? 平台化/小型中间件????????? 集成性/兼容/迁移能力涉及遗留系统，关于兼容需要明确的兼容方式和兼容模式。兼容方式包括：语义兼容/源代码（语言级/API级）兼容/运行时兼容（运行库/二进制）；兼容模式：向前兼容/向后兼容。????????? 1.4.6 容错性包括速错能力和消除易错机制（error-prone mechanism）????????? 1.4.7 升级性以上列表略显草根性，实际过程中也可以从架构评估角度反向进行非功能性需求收集，可以参考《Attribute Based Architectural Evaluation》。一次性完整地收集非功能性需求并不是件容易的事，因此在架构发布后也要不停的进行改进。?架构定义完成非功能性需求并明确后，就可以进行架构定义了。架构定义可以分为三个部分：设计、选型以及构建和评估。?架构设计这个阶段相对务虚，但却是整个架构定义的基础，决定了所有的后续工作。主要包括如下三个工作内容：????????? 确定架构手段，包括架构的原则、规范、模式、工具、框架/平台和语言，以及这些手段的适用范围，哪些问题应用工具来解决，而另一些问题采用哪个框架/平台完成，还有一些通过原则或规范处理。????????? 确定组织分工和流程，不同的工作通过组织内不同角色完成。????????? 确定结构化范围，区分系统内和系统外，并非所有非功能性需求都是通过系统的手段解决，适当采用系统外手段甚至更简单和准确。?技术选型/预研纸面上的架构其约束性和可操作性非常低，为了让架构从三万英尺的高空落地有两种办法：流程和平台。其中，流程是由组件分工完成，而平台构建通常不会从零开始，实践中会尽可能利用已有成果：商业产品和开源产品。因此技术选型以及预研工作则显得非常重要。进行技术选型需要注意两个关键点：??????? 评估单项技术的有用性（技术功能）和可用性（非功能性需求，即使用成本）有用性是指相应的技术功能点是否解决架构所面临的功能性和非功能性需求；可用性是指是否满足整体的非功能性需求，如性能、容量和稳定性。以及管理层关注指标（使用成本），如技术成熟度、标准性、培训招聘成本以及产品的生命周期，以及License费用等。??????? 保持全局视角关注全局，木桶理论的再次应用，避免某项技术存在的缺陷影响整体。主要的选型内容如下：????????? 语言，不同语言所能提供的开发能力是不同。而且开发语言直接影响到后续技术的选型以及人员的招聘。????