1.3 架构师的视图和视角

架构设计是一项包含需求分析、质量管理和过程改进的系统工程，也需要跨团队的协作和交互。当需要把架构展示给别人时，如何表现架构设计、如何让别人快速而准确地理解进而实现架构就成为架构师的考虑点之一。通常，架构师会面临类似如下的疑问。

●架构能实现哪些功能？

●架构主要构成元素有哪些？

●架构中需要管理、存储和展示的信息有哪些？

●架构需要提供怎么样的开发、测试和部署环境？

面对这些疑问，我们的思路是避免用单个“面面俱到”的模型回答所有问题。这时候架构师手上应该有两项武器，一项是视图，一项是视角。视图和视角的分类业界也有几种不同的说法，我们站在前人的基础上[1]做出自己的阐述。

要想清晰、明确地展示系统架构的视图和视角，首先需要对视图和视角进行建模，即通过统一的表述方式和模型来展示不同的视图和视角。在本书中，每一个视图和视角将包含以下3部分内容。

（1）定义

对视图和视角的简短描述，用于给出其一般定义。

（2）切入点

描述某一个视图或视角特定的关注点，并提供切入该视图或视角的方向。任何一个视图或视角都应该具备若干与其他视图或视角不一样的切入点，以便在系统设计过程中能够找到问题所对应的切入点并进行优化和管控。

（3）架构设计

包括架构设计过程中的模型和策略，对于视图和视角之间可能存在的相关关系也将属于架构设计讨论范畴。

1.3.1 架构师的视图

架构视图面向需求，主要回答“有没有”这个问题。架构设计是一项综合性的活动，要完整展示架构包含的内容实属不易。架构视图为我们提供了六大视图，图1-12展示了这六大视图及架构设计与这些视图之间的关系，所有视图都是围绕架构设计展开，但又各自具备侧重点。通过完备的架构视图，系统架构就从一种抽象的概念转变成能够供干系人触碰的软件实体。

我们基于定义、切入点和架构设计这一建模方式对每个视图进行展开。

1.上下文视图

所谓上下文（Context）指的就是一种环境。上下文视图描述系统与环境之间的关系、依赖和交互，包含了各种当前环境中数据及其操作。通常，上下文包含在特定的场景中，所以有时候我们也可以把场景（Scenario）这个词视同系统的上下文。

基于环境和交互，上下文视图的切入点往往同时关注于系统的内部和外部，系统的范围、系统之间的界限和外部系统的划分、组件和模块之间的依赖关系及如何进行系统有效集成等是上下文视图的主要展示内容。

架构设计方面，上下文视图总结我们所设计的架构背后究竟是怎么样的一个系统，包括系统本身、外部实体和相关接口。图1-13所展示的就是一个基于电商系统业务的上下文视图示例。可以看到，一个电商系统的内部包含账户系统、支付系统、物流系统等核心功能子系统，同时也需要和各种第三方系统进行集成。这时，相关数据都存储在本地数据库中，用户通过电商系统门户可以获取各个内部和外部子系统所提供的服务，从而提供了一幅完整的系统功能范围、外部系统集成和用户交互的上下文视图。

2.功能视图

功能视图描述系统运行时功能元素及其职责、接口和交互关系。从定义上看，功能视图和上下文视图有一定的重合之处，但功能视图脱离环境，描述的是系统组件定义及各个组件之间的交互关系而不是业务场景分析，所以对于功能视图而言，我们结合组件设计思想进行理解。图1-14就是图1-13中上下文视图所对应的功能视图，采用UML （Unified Modeling Language，统一建模语言）中组件图进行绘制，可以进一步看到组件之间的接口和依赖关系。

功能视图的切入点比较明确，就是从功能出发，包括系统的内部结构和外部接口，推导出该系统所需的各个组件及其依赖关系。内部结构取决于系统建模和架构分析的结果，而外部接口受系统集成模式和实现技术的约束。

功能视图的架构设计包括确定功能元素、接口、连接器和外部实体。这些在基于组件的设计方法中均有固定的表现形式。

3.数据视图

业务系统软件通过数据来承载结果，大多数实现过程都是围绕数据展开。数据视图描述系统存储、操作、管理和分发数据的方式，是系统中核心业务数据的一种载体和表现形式。

数据视图对数据的处理包括几个主要方面，首要的是数据结构。数据结构作为表示数据的元数据，是系统内部最核心的数据模型。同时，为了能够在系统内部各模块及与外部系统之间进行有效交互和集成，数据标识符和映射关系同样成为数据设计的基本要求。数据一般都需要进行持久化管理，建立以传统关系型数据库、No SQL（Not Only SQL，非关系型数据库）亦或大数据平台为代表的数据存储模型是数据视图最后需要考虑的切入点。

数据架构建模有几种典型方式，包括静态数据建模、数据流建模和数据状态建模。这些数据模型代表着数据在不同场景下的不同表现形式以及发挥的作用。在UML中，类图、流程图和状态图分别可以作为静态数据模型、数据流模型和数据模型的建模工具，图1-15代表一个移动医疗行业中“病人”这一数据载体所展现的类图，而图1-16是围绕电商行业“订单”之一概念所做的数据状态图。两个示例都能在特定场景下为系统架构提供所需的数据视图。

4.开发视图

开发视图描述支持软件开发过程的架构。在所有架构视图中，该视图最接近于系统设计和具体实现方案，是架构设计中面向技术的核心视图。

系统设计和开发包含通用的体系结构和设计模式，其中系统模块的合理组织、软件复用技术的应用、使用设计和测试的标准化及如何进行代码组织都是开发视图常见的切入点。

上述切入点需要结合具体的业务需求并采用特定的架构设计模型方能展现成开发视图。模块结构模型是开发视图中比较容易实现且易于展示的一种模型。图1-17就是一个涉及用户和商品管理的电商系统中所展示出来的模块结构图，采用了UML中的包图作为特定展示媒介。从图中我们可以看到在架构设计和系统开发中时常需要考虑的一些设计模式，如系统分层（领域层、业务逻辑层和表现层）及这些层次之间的依赖关系。当然，开发视图中也可以包含一些通用的设计模型。

5.部署视图

部署视图描述系统部署的环境及系统与其中元素的依赖关系。通常，架构设计的结果会对系统部署有特定的约束条件；反过来，系统部署条件也会影响架构设计方案。这也是为什么要把部署作为单独一项架构设计视图的原因。

部署视图的切入点一般都比较程式化。系统部署时所需的运行平台、硬件设备和软件服务、第三方软件需求和网络需求是该视图的主要考虑点。通常这些考虑点已经包含了常见业务系统部署的各个方面。

部署架构上，平台模型、网络组成模型和技术依赖关系模型等在运行时需要通过部署视图展示给相关的服务发布和运维人员。特别是现在服务化架构大行其道的背景下，系统服务之间的调用关系远比传统意义上单块模式复杂，部署视图的重要性得到显著提升。UML中，我们可以使用部署视图对系统部署架构进行建模。图1-18就是一个典型的系统部署视图，包含了若干个服务提供者和消费者，这些服务通过Zookeeper进行分布式环境的集中式协调和管理。

6.运维视图

运维视图描述当系统运行在生产环境时如何进行运维、管理和支持。运维视图并不属于系统架构设计的核心视图。该视图也通常由专业的运维人员进行开发和维护。

运维视图和部署视图一样，切入点通常都比较程式化，如建立隔离的生产环境、运行时的功能/数据迁移、状态/性能监控、集中式或分布式的配置管理、数据和系统的备份和还原及提供各项技术支持等都是常见的运维要求。

架构设计上，运维视图的目的是为了保证服务的稳定性和可用性，并在系统出现运行故障时能够进行容错和快速恢复。这其中包括安装、迁移、管理和支持活动，并且希望这些活动能够尽量做到自动化。

六大视图之间虽然各自表现架构的某个方面，但也存在依赖关系，图1-19描述的是视图之间的依赖关系。从图中可以看到，开发视图作为唯一没有被依赖的视图处于架构设计的低端，正如同编码开发处于软件系统工程的下游一样；上下文视图顾名思义处于中间位置，为多个视图提供上下文环境信息；功能和数据视图之间耦合度较高，分别构成了独立的视图系统，因此往往共同存在和发展，类似的还有部署和运维视图。

不同的系统往往对架构视图具有不同的展示要求。对上下文视图而言，主流的信息化系统、互联网系统、面向服务和中间件系统，重要性依次降低。因为信息化系统往往涉及较多的系统集成，而互联网站点则主要关注于系统内部的完备性，面向服务和中间件系统则更加专注于技术体系和指标，很少会关注业务及业务对应的交互方式。除了上下文视图，互联网系统对其他功能、数据、开发、部署和运维5个视图的要求都是最高的。面向服务和中间件系统因为系统特性一般不大关注数据和开发，而重点在于功能、部署和运维。信息化系统则对开发和部署具有较高要求，但不重视运维视图。

1.3.2 架构师的视角

架构视角面向质量，主要回答“好不好”这个问题。架构视角并不像架构视图比较容易抽象，因为一个系统的质量属性包含很多内容。我们从中筛选出4个通用而又重要的架构视角，分别是安全性、性能、可用性和可扩展性，并采用与架构视图同样的建模方式对每个视角进行展开。

1.安全性视角

安全性体现的是控制、监控和审计对资源的访问性和执行能力，以及从安全漏洞中恢复的能力。在主流的信息化系统、面向服务和中间件系统中通常要求不高，但对于互联网系统而言，安全性是一项核心非功能性需求。

从产生安全性问题的源头出发，我们可以找到常见的安全性视角切入点。需要进行安全性控制的内容通常称之为资源（Resource）。能访问资源的人或系统称为访问主体（Subject）。控制安全性就是根据不同的访问主体对不同的资源进行精细化控制，包含建立完善的用户权限管理系统并提供相应安全策略。

找到安全性切入点，架构设计上就可以对症下药。对用户进行身份认证（Authentication）、授权（Authorization）访问、通过加密解密等确保信息保密性和完整性、提供类似单点登录（Single Sign On，SSO）的安全性管理平台、使用第三方安全性基础框架等都是安全性架构设计的常见手段。

2.性能视角

性能视角的质量要求体现在系统在其指定的性能状况下执行，以及将来需要时提供增长的处理能力。性能要求对于信息化系统而言，不一定会成为一项核心质量指标，因为一般的信息化系统偏重于业务模型而不大容易形成性能瓶颈。但对于互联网应用和中间件系统，很多时候是最核心的一项系统构建目标。

性能的切入点通常也有一套完整的方法论和工程实践。比如，我们可以从核心功能响应时间、系统吞吐量、部署架构的可伸缩性、性能问题的可预测性和峰值负载等方向判断系统是否存在性能问题并找到相应的解决方案。

架构策略上，也有很多针对性能问题掉设计方案，比如，对核心业务链路和活动进行分解并把串行操作转变成并行化流程、对需要重复执行的处理过程进行优化、重用资源和结果、使用异步处理、放松事务一致性、转换数据强一致性为弱一致性等都可以在一定程度上提升系统的性能。同时，在设计解决性问题时，也需要把握一定的平衡性，避免为了提升性能而提升性能。

3.可用性视角

可用性视角提供系统在需要时能够完整地提供服务，并有效处理影响系统可用性故障的能力。和性能视角一样，可用性对于普通的信息化系统而言重要性居中，但对于互联网应用和中间件系统却是非常重要的。

可用性的规划和实现需要先明确服务的类型，对不同类型的服务其可用性要求不尽相同。系统升级、停机和维修时间、系统备份、灾难恢复等也都需要有对应的实施计划。

架构设计策略上，使用容错硬件和容错软件、确保采用主流的集群和负载均衡机制、加强日志管理和分析、采用组件复制策略、建立完整的备份和灾难恢复解决方案都属于这个视角的考虑范围之内。

4.可扩展性视角

可扩展性视角是指系统在经历不可避免地变更时足够灵活，是针对提供这样的灵活性所要付出的成本进行平衡的能力。可扩展性对于信息化系统而言就有最高的重要性，对于面向服务和中间件系统具有最低的重要性，对于互联网应用而言，其重要性视具体系统而定。目前很多互联网应用，如移动医疗行业，因为核心数据都是存放在医院，业务系统需要通过各种技术手段对接医院内部的 HIS（Hospital Information System，医院信息系统）、LIS（Laboratory Information Management System，实验室信息管理系统）等，所以也具有较高的可扩展性要求。而对于电商行业而言，核心数据都属于内部系统可控范围之内，相对而言具备较低的可扩展性要求。

可扩展性（Extensibility）通常容易与可伸缩性（Scalability）混淆。所谓可扩展，扩展的是业务。所谓可伸缩，伸缩的是性能。图1-20上半部分代表可扩展性，当往系统A中添加新业务时，不需要改变原有的各个子系统而只需把新业务封闭在一个新的子系统中就能完成整体业务的升级，我们认为系统具有较好的可扩展性；而该图下半部分表示可伸缩性，即当系统B的性能出现问题时，我们只需要简单添加一个应用服务器就能避免系统出现性能瓶颈，那么该系统无疑具备可伸缩性。实际上，我们在前文的性能视角中已经提到过部署架构的可伸缩性概念。

明确了可扩展性的概念之后，我们明白实现可扩展性的一个切入点是加强产品管理，从业务需求的源头把控变化，把部分业务在进入开发流程之前进行梳理，以避免不需要的变化的引入。对于已经进入开发流程的变化，同样需要把握变化的维度和量级，并从变化交付、开发复杂度等角度出发找到提升可扩展性的方法。

对于可扩展性视角，架构设计上的重点在于梳理系统的变化并把它们抽象成扩展点，并通过对这些扩展点创建可扩展的接口、应用促进变更的设计技术，以及尽量使用基于业务标准的扩展点技术等手段确保系统具有较高的可扩展性。

易用性视角、开发资源和效率视角、国际化视角等也属于系统架构的视角，但不属于架构设计的核心视角，故本书中不做展开。

1.3.3 视图视角与系统工程

架构视图和架构视角垂直构成完整架构描述。我们可以在明确架构视图的前提下，往各个架构视图中添加架构视角，使视图和视角在完成各自目标的同时能够紧密整合。系统的可扩展性视角与功能、数据和开发视图关系密切，因为可扩展性面向业务需求，系统的功能和数据设计方案及具体采用的开发模式会很大程度上决定系统的可扩展性。而可用性对这3个视图关系不大。部署视图对系统的安全性、性能和可用性影响巨大，部署视图是系统得以实现的基本前提，部署方案成功与否从架构上决定了能够实现成功的安全性、性能和可用性。

回到系统工程，架构视图和架构视角也是系统工程的组成部分。图1-21展示视图视角与系统工程之间的关系。视图关联视角，两者构成了架构描述的一部分；同时视图从业务需求角度，视角从质量需求角度解决了干系人所提出的各种关注点。这些关注点实际上就是需要架构师去捕获的架构设计的输入。