尧图网页设计 
本文是文章Microsoft Architecture Overview的翻译和阅读笔记。这是2002年7月的文章作者为Michael Platt。本文档面向希望了解微软企业、应用和技术架构方法的业务、软件和基础设施架构师。它涵盖了架构术语、模式、概念和定义以一系列架构视图或层级呈现。Enterprise ArchitectureANSI/IEEE Std 1471-2000 中对架构的定义为“系统的基本组织体现于系统的组件、组件之间以及组件与环境之间的关系以及支配系统设计与演进的原则。” ANSI/IEEE Std 1471-2000 中对architecture的定义原文为the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. 架构前面是有很多定语的如系统软件企业等。在以上定义中由于其指明了是of a system所以这里的架构指的就是系统架构。最新的系统架构的定义参见这里System architecture is the fundamental organization of a system, embodied in its components, their relationships to one another and to the environment, and the principles guiding the system’s design and evolution. The formal definition originates with IEEE Standard 1471:2000 and its successor ISO/IEC/IEEE 42010:2011, which standardized the vocabulary and framework for architectural description across systems and software engineering. A system architecture encompasses both structural decisions (what components exist and how they connect) and behavioral decisions (what each component does and how the system responds to stimuli), with the explicit goal of satisfying stakeholder concerns regarding function, performance, safety, and evolvability.系统架构是系统的基本组织体现于系统的组件、组件之间以及组件与环境之间的关系以及指导系统设计和演进的原则。该正式定义源自 IEEE 1471:2000 标准及其继任标准 ISO/IEC/IEEE 42010:2011后者为系统工程与软件工程领域的架构描述统一了术语体系与框架。系统架构同时涵盖结构性决策存在哪些组件、组件如何互连和行为性决策每个组件承担什么功能、系统如何响应外部刺激其明确目标是满足利益相关方在功能、性能、安全性和可演进性方面的关注。System architecture as a discipline draws on electrical engineering, computer science, control theory, and industrial engineering. It addresses both the hardware and software subsystems of a technical product as well as the interfaces between them, making it a bridge between high-level requirements and detailed design. A well-specified architecture constrains the implementation space sufficiently to allow distributed teams to work concurrently while ensuring the integrated system will satisfy its intended function.系统架构作为一门学科借鉴电气工程、计算机科学、控制理论以及工业工程的知识体系。它既研究技术产品的硬件子系统与软件子系统也研究各子系统之间的接口是连接高层需求与详细设计的桥梁。一份定义完备的架构能够对实现空间做出充分约束使得分布式团队可以并行开展工作同时保证集成后的系统能够实现预期功能。企业架构EA是一种概念化工具用于帮助组织理解自身结构与运作方式。它提供企业全景视图也是业务与技术变革的规划向导。 架构的目的在于沟通架构师大部分的工作也是在沟通以在众多的干系人之间做出平衡。企业架构通常由一套完整且相互关联的模型构成用以描述企业的结构与功能。其核心用途包括系统化信息技术规划与架构设计以及辅助优化决策。企业架构中的各个模型按逻辑层次组织由粗到细逐层展示企业信息涵盖企业目标与愿景业务流程与组织架构信息系统与数据所采用的技术 上面4点其实就是TOGAF中的战略业务架构信息系统架构应用数据技术架构。Microsoft Architectural Perspective企业架构中的信息可从多个视角进行查看能够满足多样化需求。架构使用者包括业务经理与业务分析师、系统架构师与设计人员、工作流及流程分析师、物流专员、组织分析师等。这些人员既需要高层汇总信息也需要详细数据以及介于两者之间各级粒度的信息。可通过构建概念视图、逻辑分析与物理实现来满足上述各类需求。在微软我们认为有四类通用视角十分重要且被广泛使用分别是业务视角、应用视角、信息视角和技术视角。The business perspective业务视角描述业务的运作方式。它涵盖宏观业务战略以及将组织从当前状态过渡到设想的未来状态的各类规划。业务视角通常包含以下内容企业的高层目标与愿景整个企业或企业重要组成部分所执行的业务流程所承担的业务功能主要组织结构上述各要素之间的相互关系The application perspective应用视角以应用系统为核心定义企业的应用资产组合。该视图通常包含支撑业务流程的自动化服务说明组织内各应用系统之间交互与依赖关系接口说明根据企业目标以及不断演进的技术平台制定新应用开发与旧应用改造计划应用视角可体现跨组织的服务、信息与功能将具备不同技能、不同岗位职能的用户关联起来以达成共同的业务目标。The information perspective信息视角描述组织为执行业务流程与运营活动所需掌握的信息内容。它包含标准数据模型数据管理策略组织内部信息产生与消费模式说明信息视角同时描述数据如何融入业务工作流涵盖数据库这类结构化数据存储以及散布在整个组织中的文档、电子表格、演示文稿等非结构化数据存储。The technology perspective技术视角列出支撑组织运转的硬件与软件包含但不限于桌面端与服务器硬件操作系统网络连通组件打印机调制解调器技术视角对支撑应用视角与信息视角所必需的基础设施和系统组件进行与厂商无关的逻辑描述。它定义执行业务使命所需的一套技术标准与技术服务。尽管可以存在众多视角但所有视角所观察的企业架构只有一个。企业架构的价值不在于任何单一视角而在于各个视角之间的关联、交互与依赖关系。虽然所有视角都是企业架构的核心要素但本文档将重点关注应用视角与技术视角。Application and Technology Architecture软件系统的功能需求描述软件所能提供的业务价值。以气象服务为例一条功能需求可表述为“若输入格式合法的消息 A该服务将返回消息 B消息 B 的内容与消息 A 中指定的时间段和地理位置匹配。”应用架构是支撑并实现上述功能需求的各类自动化服务的架构包含面向业务以及对接其他应用的接口。它描述应用的结构以及该结构如何实现组织的功能需求。理想情况下一个组织应当只有一套应用架构但在实际场景中通常会存在多套不同的应用架构。软件系统的运行需求定义软件在可靠性、可管理性、性能、安全性、互操作性等方面的要求此处仅列举部分。典型例子该服务仅对授权订阅用户开放服务可用率达到 99.999%。技术架构是支撑组织、实现**运行需求或称非功能需求**的软硬件基础设施的架构重点支撑组织的应用架构与信息架构。它描述所使用各项技术的结构与相互关系以及这些技术如何满足组织的运行需求。良好的技术架构能够提供安全能力、可用性与可靠性并可支撑各类其他运行需求。但如果应用的设计未能利用技术架构本身的特性应用仍然可能性能不佳或是难以部署与运维。同理一套精心设计、完全契合业务流程需求并且基于可复用软件组件、采用最新技术构建的应用结构也有可能无法很好地映射到实际技术配置上服务器配置无法适配应用组件网络硬件参数不能支撑信息流转。这体现出应用架构与技术架构之间存在依存关系优秀的技术架构是为支撑对组织至关重要的特定应用而构建优秀的应用架构则充分利用技术架构在各项运行需求下稳定输出一致的性能。Figure 1. Relationships between architecturesConceptual, Logical, and Physical Views对于所有架构视角架构都存在多种视图通常划分为概念视图、逻辑视图和物理视图。概念视图抽象程度最高其描述方式一般采用系统使用者非 IT 专业人员最容易理解的语言。概念视图用于定义功能需求以及业务用户对应用的认知视图以此构建业务模型。逻辑视图展示系统内部主要功能组件及其相互关系不考虑功能实现的技术细节。架构师在确定如何满足业务目标与需求时会构建应用模型 —— 即业务模型对应的逻辑视图。这些应用模型代表应用架构的逻辑视图。物理视图的抽象程度最低展示具体的实现组件及其相互关系。物理视图中的每一项元素通常经由设计与开发流程落地实现为软件或硬件系统。该实现视图一般由组织内部的开发或运维团队负责因此不在本文档讨论范围之内。Figure 2. Architectural views在每一个架构层级上都可以存在实际上通常也确实存在多个架构视图例如一般每个应用都会对应一份逻辑应用架构视图。这类视图由多组需求驱动产生反过来又为设计、开发、部署与运维流程及系统提供输入依据。Figure 3. Architectural views and patterns本指南后续内容将聚焦应用架构与技术架构介绍相关概念以及构建基于服务的应用所用到的关键模式这类应用将利用新兴的 Web 服务技术。实现领域包含设计、开发、环境搭建、部署与管理工作尽管其在完整系统构建过程中至关重要但不属于本文档的讨论范围。Application Architecture如前文所述应用架构提供三类视图概念视图、逻辑视图与物理视图。架构师使用这些视图在组织内构建模型用以支撑并满足业务需求。理想情况下每种视图仅对应一套模型但在实际场景中由于组织与技术的发展演变同一种视图可能存在多套模型。不过将这些模型梳理整合为最小集合是打造高效且具备柔性的组织的关键。Conceptual view概念视图用于定义业务需求以及业务用户对应用的认知视图以此生成业务模型。用例分析、活动图、流程设计、业务实体建模等概念建模技术有助于对核心业务流程及其所使用的数据进行描述该描述以业务目标与业务需求为核心不涉及任何实现技术。Logical view架构师在确定如何实现业务目标与业务需求时会构建作为业务模型逻辑视图的应用模型。这些应用模型代表某一应用架构的逻辑视图。此时架构师关注应用的整体结构。他们确定数据管理与流程步骤之间的映射关系基于逻辑消息与执行序列设计模型各组成部分之间的交互并确定模型应当保存哪些数据与状态信息。Physical view应用模型中的每一项元素都需要映射到真实技术的元素上。通过这种方式应用模型被转化为实现模型。这项工作的一部分在常规开发阶段完成由程序员将详细业务逻辑编写为代码但大量实现活动可归类为框架补全这是一种开发方式分布式应用与数据管理的大部分基础设施由成熟框架承载再通过定制化应用逻辑和声明式控制结构对框架进行扩展。框架补全将开发人员从异步消息处理等复杂底层细节中隔离出来让能力中等的开发人员也能为项目做出有效贡献。在组织内不同层级上设计并构建上述各类模型显然需要投入大量工作与精力。此外模型的正确定义对组织至关重要。错误的架构模型几乎总会引发严重的设计或运维问题例如可扩展性不足、可靠性缺陷最坏情况下甚至会造成项目无法交付对业务产生负面影响。架构师需要框架与路线图辅助他们创建和落地这些模型并尽可能降低因使用错误模型带来的风险。可向架构师提供两大类架构指导与支撑用以加快模型构建并降低风险。第一类是一套架构概念集它可以实现统一认知支撑沟通交流指导特定概念的使用时机与使用方式并提供概念属性相关信息说明这些概念在何时可以落地与可用无论是作为指导规范还是以真实技术形态提供第二类是一组模式。这些模式从大量成功的分布式应用中提炼真实实践经验并基于上述基础架构概念构建而成。模式封装了分布式应用设计中的重要最佳实践通过提供经过验证、成熟可靠的架构模型能够降低项目失败的风险。Figure 4. Views of application architectureApplication Architecture: Conceptual View过去应用程序是通过集成本地系统服务例如文件系统、设备驱动程序构建的。该模型可以灵活地访问丰富的开发资源并对应用行为实现精细控制但这种方式极易出错、成本高昂且开发周期漫长。如今复杂的分布式应用可以集成网络中已有的各类应用与服务再基于业务实体、数据实体、外观façade等组件叠加独特业务价值。这让开发人员能够聚焦交付差异化业务价值最终缩短产品上市周期、提升开发人员生产力并产出质量更高的软件。多年来这一直是一套强大的架构模型但它会形成应用烟囱或称信息孤岛给架构复用带来严重问题。我们正迈入计算技术的下一阶段 —— 互联网与 Web 服务共同促成了这一阶段。借助 Web 服务我们能够构建强大的应用任何人在任意地点均可使用。它扩大了应用的覆盖范围支持软件的持续交付。在此背景下软件就是一种服务用户通过通信网络订阅并使用该服务。.NET 实现了这一构想它融合n 层计算高内聚、开发效率高的特性同时吸纳 Web 面向消息、松耦合的设计理念。这种计算模式被称为XML Web 服务。它代表应用开发的下一代演进方向也是概念层应用架构的实现基础。Web 服务是独立的应用逻辑单元对外暴露基于消息的接口支持跨网络访问。通常服务既提供业务逻辑也负责处理对应业务场景下的状态管理。设计服务时目标是有效封装现实业务流程对应的逻辑与数据同时要做出合理取舍判断哪些能力放在本服务内实现哪些需要拆分为独立服务。状态变更受业务规则约束。业务规则属于相对稳定的算法例如根据商品明细计算发票总金额的计算逻辑一般以应用逻辑的方式实现。服务由策略Policy管控。策略不像业务规则那样固定不变可能存在地域差异或客户定制化差异通常在运行时通过查询配置表来加载。由此可以得到一个更完整的服务定义“服务是具备网络访问能力的软件单元它实现业务逻辑、管理状态、通过消息完成通信并且受策略管控。”关于应用的概念视图可参考文档 Application Architecture: Conceptual View其中有更加详尽的介绍。Application Patterns模式是特定场景下某个问题的解决方案。模式将从领域实践经验中总结出的特定知识整理固化。应用模式属于架构级模式针对特定应用环境定义架构设计的最佳实践。模式存在多种不同类型与分类体系具体模式的定义与说明不在本文讨论范围内。现有的很多架构模式可以应用于基于 Web 服务的架构同时依托 Web 服务提供的新构造也衍生出若干全新的模式。Technology Architecture和应用架构一样技术架构同样包含三类视图概念视图、逻辑视图与物理视图。架构师利用这些视图在组织内构建模型用以支撑并满足运行需求。和应用架构的情形相同理想情况下组织应当仅有一套技术架构但现实中受组织与技术发展演变影响几乎总会存在多套技术架构。组织的一项核心诉求就是将这些彼此异构的技术架构整合为一套全局统一的架构实现现有应用复用并把多套技术架构梳理精简至最小集合。构建这套统一的公共架构对于打造高效、有力且具备柔性的组织至关重要。Conceptual view技术架构的概念视图用于将各类技术领域规划为一套结构与框架。它对这些技术领域进行定义、命名与定位使技术提供方与使用该技术的业务组织达成共识同时确保实现组织运行需求或称非功能需求所需的全部技术领域都已明确定义可供组织使用。Logical view技术架构的逻辑视图定义支撑企业级运行需求的主要功能组件及其相互关系。数据库、邮件系统、事务支撑、可靠消息等企业技术组件都在逻辑视图中给出。该层级所描述的技术通常由企业软件厂商打包封装为各类服务器产品对外提供。Physical view技术架构中的每一项组件都需要映射到真实软硬件技术组件上。通过这种方式技术架构落地为由网络、服务器、操作系统等构成的完整系统。该层级会展示实际物理位置、服务器产品型号以及网络连接关系。架构师期望 IT 厂商提供技术框架与路线图以协助搭建满足组织运行需求的系统并保证本组织的技术架构与 IT 厂商的技术架构保持对齐。Technology Architecture: Conceptual View技术概念架构是组织内部实现企业级 Web 服务的技术基础。技术概念架构的高层示意图展示了一组通用层级这些层级为 Web 服务的构建提供企业级服务能力。这些层级包含所有 Web 服务应用或系统都必需的公共组件。Figure 5. Conceptual view of technology architecture示意图的最底层是服务平台Service Platform为整套系统提供操作系统、硬件、存储、网络以及安全可信服务与管理服务。**服务框架Service Framework**承载基于 Web 服务的应用所需的流程、业务逻辑、功能与状态管理它是完整的企业应用服务器并针对 Web 服务提供专门支持。**服务交付Service Delivery**包含门户与客户端服务专注于展现层相关问题与技术支持各类终端设备。**服务集成Service Integration**实现服务与现有业务系统之间的集成和互操作涵盖遗留应用、商用软件、数据库以及其他 Web 服务。这通常被称为企业应用集成EAI。最后**服务创建Service Creation**提供设计、开发、组装、管理、部署和测试 Web 服务所需的工具、流程、方法学与架构模式。关于技术架构的这一概念视图在《技术架构概念视图》文档中有更详尽的阐述。Technology Patterns技术模式是一种架构级模式定义特定技术环境下架构设计的最佳实践。企业架构师希望在以下关键领域获取指导与最佳实践用于本组织的架构建设安全、身份与可信体系与未来系统及现有运行遗留系统的集成和互操作部署、运维与管理用于实现可扩展性与性能目标的分布式技术架构保障可靠性与可用性的技术架构附录A IEEE对于软件架构的定义原文参见这里。Software architecture is the fundamental organization of a software system, expressed through its components, the relationships among those components, and the principles governing their design and evolution. It constitutes the earliest and most consequential set of design decisions in a software project, establishing constraints that later implementation choices must respect. The field emerged as a recognized discipline in the 1990s, as system complexity outgrew the capacity of individual design documents, and has since been formalized through ISO/IEC/IEEE 42010:2011, which provides a standard vocabulary and conceptual framework for describing system and software architectures.软件架构是软件系统的基本组织通过其组件、组件之间的关系以及支配组件设计与演进的原则来表达。它构成软件项目中最早、影响最为深远的一组设计决策所确立的约束是后续实现方案必须遵守的。随着系统复杂度超出单一设计文档所能承载的范围该领域在 20 世纪 90 年代发展成为一门公认学科此后 ISO/IEC/IEEE 42010:2011 对其进行规范化该标准为描述系统架构与软件架构提供了标准术语集和概念框架。Architecture differs from detailed design in scope: where detailed design specifies the internals of individual modules, architecture defines the module boundaries, the communication mechanisms between them, and the mapping of functionality to structural elements. A key contribution of the IEEE 1471 standard for software-intensive systems was distinguishing an architecture from its description, recognizing that the same architectural decisions can be documented from multiple viewpoints such as logical, deployment, and process perspectives.架构与详细设计在作用范围上有所区别详细设计规定各个模块的内部实现而架构定义模块边界、模块间的通信机制以及功能到结构元素的映射关系。IEEE 1471 标准针对软件密集型系统的一项核心贡献就是区分架构本身和架构描述该标准认识到同一套架构决策可从多个视角如逻辑视角、部署视角与流程视角进行文档化表达。参考Microsoft 体系结构概述应用程序概念视图 系统架构概述
本文是文章Microsoft Architecture Overview的翻译和阅读笔记。这是2002年7月的文章作者为Michael Platt。本文档面向希望了解微软企业、应用和技术架构方法的业务、软件和基础设施架构师。它涵盖了架构术语、模式、概念和定义以一系列架构视图或层级呈现。Enterprise ArchitectureANSI/IEEE Std 1471-2000 中对架构的定义为“系统的基本组织体现于系统的组件、组件之间以及组件与环境之间的关系以及支配系统设计与演进的原则。” ANSI/IEEE Std 1471-2000 中对architecture的定义原文为the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. 架构前面是有很多定语的如系统软件企业等。在以上定义中由于其指明了是of a system所以这里的架构指的就是系统架构。最新的系统架构的定义参见这里System architecture is the fundamental organization of a system, embodied in its components, their relationships to one another and to the environment, and the principles guiding the system’s design and evolution. The formal definition originates with IEEE Standard 1471:2000 and its successor ISO/IEC/IEEE 42010:2011, which standardized the vocabulary and framework for architectural description across systems and software engineering. A system architecture encompasses both structural decisions (what components exist and how they connect) and behavioral decisions (what each component does and how the system responds to stimuli), with the explicit goal of satisfying stakeholder concerns regarding function, performance, safety, and evolvability.系统架构是系统的基本组织体现于系统的组件、组件之间以及组件与环境之间的关系以及指导系统设计和演进的原则。该正式定义源自 IEEE 1471:2000 标准及其继任标准 ISO/IEC/IEEE 42010:2011后者为系统工程与软件工程领域的架构描述统一了术语体系与框架。系统架构同时涵盖结构性决策存在哪些组件、组件如何互连和行为性决策每个组件承担什么功能、系统如何响应外部刺激其明确目标是满足利益相关方在功能、性能、安全性和可演进性方面的关注。System architecture as a discipline draws on electrical engineering, computer science, control theory, and industrial engineering. It addresses both the hardware and software subsystems of a technical product as well as the interfaces between them, making it a bridge between high-level requirements and detailed design. A well-specified architecture constrains the implementation space sufficiently to allow distributed teams to work concurrently while ensuring the integrated system will satisfy its intended function.系统架构作为一门学科借鉴电气工程、计算机科学、控制理论以及工业工程的知识体系。它既研究技术产品的硬件子系统与软件子系统也研究各子系统之间的接口是连接高层需求与详细设计的桥梁。一份定义完备的架构能够对实现空间做出充分约束使得分布式团队可以并行开展工作同时保证集成后的系统能够实现预期功能。企业架构EA是一种概念化工具用于帮助组织理解自身结构与运作方式。它提供企业全景视图也是业务与技术变革的规划向导。 架构的目的在于沟通架构师大部分的工作也是在沟通以在众多的干系人之间做出平衡。企业架构通常由一套完整且相互关联的模型构成用以描述企业的结构与功能。其核心用途包括系统化信息技术规划与架构设计以及辅助优化决策。企业架构中的各个模型按逻辑层次组织由粗到细逐层展示企业信息涵盖企业目标与愿景业务流程与组织架构信息系统与数据所采用的技术 上面4点其实就是TOGAF中的战略业务架构信息系统架构应用数据技术架构。Microsoft Architectural Perspective企业架构中的信息可从多个视角进行查看能够满足多样化需求。架构使用者包括业务经理与业务分析师、系统架构师与设计人员、工作流及流程分析师、物流专员、组织分析师等。这些人员既需要高层汇总信息也需要详细数据以及介于两者之间各级粒度的信息。可通过构建概念视图、逻辑分析与物理实现来满足上述各类需求。在微软我们认为有四类通用视角十分重要且被广泛使用分别是业务视角、应用视角、信息视角和技术视角。The business perspective业务视角描述业务的运作方式。它涵盖宏观业务战略以及将组织从当前状态过渡到设想的未来状态的各类规划。业务视角通常包含以下内容企业的高层目标与愿景整个企业或企业重要组成部分所执行的业务流程所承担的业务功能主要组织结构上述各要素之间的相互关系The application perspective应用视角以应用系统为核心定义企业的应用资产组合。该视图通常包含支撑业务流程的自动化服务说明组织内各应用系统之间交互与依赖关系接口说明根据企业目标以及不断演进的技术平台制定新应用开发与旧应用改造计划应用视角可体现跨组织的服务、信息与功能将具备不同技能、不同岗位职能的用户关联起来以达成共同的业务目标。The information perspective信息视角描述组织为执行业务流程与运营活动所需掌握的信息内容。它包含标准数据模型数据管理策略组织内部信息产生与消费模式说明信息视角同时描述数据如何融入业务工作流涵盖数据库这类结构化数据存储以及散布在整个组织中的文档、电子表格、演示文稿等非结构化数据存储。The technology perspective技术视角列出支撑组织运转的硬件与软件包含但不限于桌面端与服务器硬件操作系统网络连通组件打印机调制解调器技术视角对支撑应用视角与信息视角所必需的基础设施和系统组件进行与厂商无关的逻辑描述。它定义执行业务使命所需的一套技术标准与技术服务。尽管可以存在众多视角但所有视角所观察的企业架构只有一个。企业架构的价值不在于任何单一视角而在于各个视角之间的关联、交互与依赖关系。虽然所有视角都是企业架构的核心要素但本文档将重点关注应用视角与技术视角。Application and Technology Architecture软件系统的功能需求描述软件所能提供的业务价值。以气象服务为例一条功能需求可表述为“若输入格式合法的消息 A该服务将返回消息 B消息 B 的内容与消息 A 中指定的时间段和地理位置匹配。”应用架构是支撑并实现上述功能需求的各类自动化服务的架构包含面向业务以及对接其他应用的接口。它描述应用的结构以及该结构如何实现组织的功能需求。理想情况下一个组织应当只有一套应用架构但在实际场景中通常会存在多套不同的应用架构。软件系统的运行需求定义软件在可靠性、可管理性、性能、安全性、互操作性等方面的要求此处仅列举部分。典型例子该服务仅对授权订阅用户开放服务可用率达到 99.999%。技术架构是支撑组织、实现**运行需求或称非功能需求**的软硬件基础设施的架构重点支撑组织的应用架构与信息架构。它描述所使用各项技术的结构与相互关系以及这些技术如何满足组织的运行需求。良好的技术架构能够提供安全能力、可用性与可靠性并可支撑各类其他运行需求。但如果应用的设计未能利用技术架构本身的特性应用仍然可能性能不佳或是难以部署与运维。同理一套精心设计、完全契合业务流程需求并且基于可复用软件组件、采用最新技术构建的应用结构也有可能无法很好地映射到实际技术配置上服务器配置无法适配应用组件网络硬件参数不能支撑信息流转。这体现出应用架构与技术架构之间存在依存关系优秀的技术架构是为支撑对组织至关重要的特定应用而构建优秀的应用架构则充分利用技术架构在各项运行需求下稳定输出一致的性能。Figure 1. Relationships between architecturesConceptual, Logical, and Physical Views对于所有架构视角架构都存在多种视图通常划分为概念视图、逻辑视图和物理视图。概念视图抽象程度最高其描述方式一般采用系统使用者非 IT 专业人员最容易理解的语言。概念视图用于定义功能需求以及业务用户对应用的认知视图以此构建业务模型。逻辑视图展示系统内部主要功能组件及其相互关系不考虑功能实现的技术细节。架构师在确定如何满足业务目标与需求时会构建应用模型 —— 即业务模型对应的逻辑视图。这些应用模型代表应用架构的逻辑视图。物理视图的抽象程度最低展示具体的实现组件及其相互关系。物理视图中的每一项元素通常经由设计与开发流程落地实现为软件或硬件系统。该实现视图一般由组织内部的开发或运维团队负责因此不在本文档讨论范围之内。Figure 2. Architectural views在每一个架构层级上都可以存在实际上通常也确实存在多个架构视图例如一般每个应用都会对应一份逻辑应用架构视图。这类视图由多组需求驱动产生反过来又为设计、开发、部署与运维流程及系统提供输入依据。Figure 3. Architectural views and patterns本指南后续内容将聚焦应用架构与技术架构介绍相关概念以及构建基于服务的应用所用到的关键模式这类应用将利用新兴的 Web 服务技术。实现领域包含设计、开发、环境搭建、部署与管理工作尽管其在完整系统构建过程中至关重要但不属于本文档的讨论范围。Application Architecture如前文所述应用架构提供三类视图概念视图、逻辑视图与物理视图。架构师使用这些视图在组织内构建模型用以支撑并满足业务需求。理想情况下每种视图仅对应一套模型但在实际场景中由于组织与技术的发展演变同一种视图可能存在多套模型。不过将这些模型梳理整合为最小集合是打造高效且具备柔性的组织的关键。Conceptual view概念视图用于定义业务需求以及业务用户对应用的认知视图以此生成业务模型。用例分析、活动图、流程设计、业务实体建模等概念建模技术有助于对核心业务流程及其所使用的数据进行描述该描述以业务目标与业务需求为核心不涉及任何实现技术。Logical view架构师在确定如何实现业务目标与业务需求时会构建作为业务模型逻辑视图的应用模型。这些应用模型代表某一应用架构的逻辑视图。此时架构师关注应用的整体结构。他们确定数据管理与流程步骤之间的映射关系基于逻辑消息与执行序列设计模型各组成部分之间的交互并确定模型应当保存哪些数据与状态信息。Physical view应用模型中的每一项元素都需要映射到真实技术的元素上。通过这种方式应用模型被转化为实现模型。这项工作的一部分在常规开发阶段完成由程序员将详细业务逻辑编写为代码但大量实现活动可归类为框架补全这是一种开发方式分布式应用与数据管理的大部分基础设施由成熟框架承载再通过定制化应用逻辑和声明式控制结构对框架进行扩展。框架补全将开发人员从异步消息处理等复杂底层细节中隔离出来让能力中等的开发人员也能为项目做出有效贡献。在组织内不同层级上设计并构建上述各类模型显然需要投入大量工作与精力。此外模型的正确定义对组织至关重要。错误的架构模型几乎总会引发严重的设计或运维问题例如可扩展性不足、可靠性缺陷最坏情况下甚至会造成项目无法交付对业务产生负面影响。架构师需要框架与路线图辅助他们创建和落地这些模型并尽可能降低因使用错误模型带来的风险。可向架构师提供两大类架构指导与支撑用以加快模型构建并降低风险。第一类是一套架构概念集它可以实现统一认知支撑沟通交流指导特定概念的使用时机与使用方式并提供概念属性相关信息说明这些概念在何时可以落地与可用无论是作为指导规范还是以真实技术形态提供第二类是一组模式。这些模式从大量成功的分布式应用中提炼真实实践经验并基于上述基础架构概念构建而成。模式封装了分布式应用设计中的重要最佳实践通过提供经过验证、成熟可靠的架构模型能够降低项目失败的风险。Figure 4. Views of application architectureApplication Architecture: Conceptual View过去应用程序是通过集成本地系统服务例如文件系统、设备驱动程序构建的。该模型可以灵活地访问丰富的开发资源并对应用行为实现精细控制但这种方式极易出错、成本高昂且开发周期漫长。如今复杂的分布式应用可以集成网络中已有的各类应用与服务再基于业务实体、数据实体、外观façade等组件叠加独特业务价值。这让开发人员能够聚焦交付差异化业务价值最终缩短产品上市周期、提升开发人员生产力并产出质量更高的软件。多年来这一直是一套强大的架构模型但它会形成应用烟囱或称信息孤岛给架构复用带来严重问题。我们正迈入计算技术的下一阶段 —— 互联网与 Web 服务共同促成了这一阶段。借助 Web 服务我们能够构建强大的应用任何人在任意地点均可使用。它扩大了应用的覆盖范围支持软件的持续交付。在此背景下软件就是一种服务用户通过通信网络订阅并使用该服务。.NET 实现了这一构想它融合n 层计算高内聚、开发效率高的特性同时吸纳 Web 面向消息、松耦合的设计理念。这种计算模式被称为XML Web 服务。它代表应用开发的下一代演进方向也是概念层应用架构的实现基础。Web 服务是独立的应用逻辑单元对外暴露基于消息的接口支持跨网络访问。通常服务既提供业务逻辑也负责处理对应业务场景下的状态管理。设计服务时目标是有效封装现实业务流程对应的逻辑与数据同时要做出合理取舍判断哪些能力放在本服务内实现哪些需要拆分为独立服务。状态变更受业务规则约束。业务规则属于相对稳定的算法例如根据商品明细计算发票总金额的计算逻辑一般以应用逻辑的方式实现。服务由策略Policy管控。策略不像业务规则那样固定不变可能存在地域差异或客户定制化差异通常在运行时通过查询配置表来加载。由此可以得到一个更完整的服务定义“服务是具备网络访问能力的软件单元它实现业务逻辑、管理状态、通过消息完成通信并且受策略管控。”关于应用的概念视图可参考文档 Application Architecture: Conceptual View其中有更加详尽的介绍。Application Patterns模式是特定场景下某个问题的解决方案。模式将从领域实践经验中总结出的特定知识整理固化。应用模式属于架构级模式针对特定应用环境定义架构设计的最佳实践。模式存在多种不同类型与分类体系具体模式的定义与说明不在本文讨论范围内。现有的很多架构模式可以应用于基于 Web 服务的架构同时依托 Web 服务提供的新构造也衍生出若干全新的模式。Technology Architecture和应用架构一样技术架构同样包含三类视图概念视图、逻辑视图与物理视图。架构师利用这些视图在组织内构建模型用以支撑并满足运行需求。和应用架构的情形相同理想情况下组织应当仅有一套技术架构但现实中受组织与技术发展演变影响几乎总会存在多套技术架构。组织的一项核心诉求就是将这些彼此异构的技术架构整合为一套全局统一的架构实现现有应用复用并把多套技术架构梳理精简至最小集合。构建这套统一的公共架构对于打造高效、有力且具备柔性的组织至关重要。Conceptual view技术架构的概念视图用于将各类技术领域规划为一套结构与框架。它对这些技术领域进行定义、命名与定位使技术提供方与使用该技术的业务组织达成共识同时确保实现组织运行需求或称非功能需求所需的全部技术领域都已明确定义可供组织使用。Logical view技术架构的逻辑视图定义支撑企业级运行需求的主要功能组件及其相互关系。数据库、邮件系统、事务支撑、可靠消息等企业技术组件都在逻辑视图中给出。该层级所描述的技术通常由企业软件厂商打包封装为各类服务器产品对外提供。Physical view技术架构中的每一项组件都需要映射到真实软硬件技术组件上。通过这种方式技术架构落地为由网络、服务器、操作系统等构成的完整系统。该层级会展示实际物理位置、服务器产品型号以及网络连接关系。架构师期望 IT 厂商提供技术框架与路线图以协助搭建满足组织运行需求的系统并保证本组织的技术架构与 IT 厂商的技术架构保持对齐。Technology Architecture: Conceptual View技术概念架构是组织内部实现企业级 Web 服务的技术基础。技术概念架构的高层示意图展示了一组通用层级这些层级为 Web 服务的构建提供企业级服务能力。这些层级包含所有 Web 服务应用或系统都必需的公共组件。Figure 5. Conceptual view of technology architecture示意图的最底层是服务平台Service Platform为整套系统提供操作系统、硬件、存储、网络以及安全可信服务与管理服务。**服务框架Service Framework**承载基于 Web 服务的应用所需的流程、业务逻辑、功能与状态管理它是完整的企业应用服务器并针对 Web 服务提供专门支持。**服务交付Service Delivery**包含门户与客户端服务专注于展现层相关问题与技术支持各类终端设备。**服务集成Service Integration**实现服务与现有业务系统之间的集成和互操作涵盖遗留应用、商用软件、数据库以及其他 Web 服务。这通常被称为企业应用集成EAI。最后**服务创建Service Creation**提供设计、开发、组装、管理、部署和测试 Web 服务所需的工具、流程、方法学与架构模式。关于技术架构的这一概念视图在《技术架构概念视图》文档中有更详尽的阐述。Technology Patterns技术模式是一种架构级模式定义特定技术环境下架构设计的最佳实践。企业架构师希望在以下关键领域获取指导与最佳实践用于本组织的架构建设安全、身份与可信体系与未来系统及现有运行遗留系统的集成和互操作部署、运维与管理用于实现可扩展性与性能目标的分布式技术架构保障可靠性与可用性的技术架构附录A IEEE对于软件架构的定义原文参见这里。Software architecture is the fundamental organization of a software system, expressed through its components, the relationships among those components, and the principles governing their design and evolution. It constitutes the earliest and most consequential set of design decisions in a software project, establishing constraints that later implementation choices must respect. The field emerged as a recognized discipline in the 1990s, as system complexity outgrew the capacity of individual design documents, and has since been formalized through ISO/IEC/IEEE 42010:2011, which provides a standard vocabulary and conceptual framework for describing system and software architectures.软件架构是软件系统的基本组织通过其组件、组件之间的关系以及支配组件设计与演进的原则来表达。它构成软件项目中最早、影响最为深远的一组设计决策所确立的约束是后续实现方案必须遵守的。随着系统复杂度超出单一设计文档所能承载的范围该领域在 20 世纪 90 年代发展成为一门公认学科此后 ISO/IEC/IEEE 42010:2011 对其进行规范化该标准为描述系统架构与软件架构提供了标准术语集和概念框架。Architecture differs from detailed design in scope: where detailed design specifies the internals of individual modules, architecture defines the module boundaries, the communication mechanisms between them, and the mapping of functionality to structural elements. A key contribution of the IEEE 1471 standard for software-intensive systems was distinguishing an architecture from its description, recognizing that the same architectural decisions can be documented from multiple viewpoints such as logical, deployment, and process perspectives.架构与详细设计在作用范围上有所区别详细设计规定各个模块的内部实现而架构定义模块边界、模块间的通信机制以及功能到结构元素的映射关系。IEEE 1471 标准针对软件密集型系统的一项核心贡献就是区分架构本身和架构描述该标准认识到同一套架构决策可从多个视角如逻辑视角、部署视角与流程视角进行文档化表达。参考Microsoft 体系结构概述应用程序概念视图