架构设计的核心问题

 

架构设计的核心问题

架构设计是一项综合且抽象的工作，当需要把架构展示给别人时，如何表现架构设计、如何让别人快速而准确的理解进而实现架构就成为架构师的考虑点之一。通常，架构师会面临类似如下的疑问。

• 架构能实现那些功能？
• 架构主要构成元素有哪些？
• 架构中需要管理、存储和展示的信息有哪些？
• 架构需要提供怎么样的开发、测试和部署环境？

面对这些疑问，我们的思路是避免使用单个面面俱到的模型回答所有问题。在本课程中，我们将通过使用三个核心概念回答上述问题，即层次、维度和视图。

架构设计的层次

架构设计被认为是从问题领域到解决方案的一种桥梁（见下图），我们在上一篇中已经提到过这张图，从图中我们可以看到架构设计活动与代表问题域的需求分析活动和代表解决域的软件开发活动都有直接的交集，连接着两个软件开发的核心领域。从下图我们可以看到架构设计的两个层次，即面向问题领域的业务架构（Business Architecture）和面向解决方案的技术架构（Technical Architecture）。

业务架构设计涵盖应用功能的划分、应用功能集成和部署，主要关注点在于复杂的业务逻辑、多方面的数据来源、系统的独立性和集成性。

技术架构则提供技术的分层描述以及关键技术的方案，主要关注点在于系统运行时的各种设计要素，如高并发场景下的性能、可用性以及数据的安全性。

架构设计本质是满足业务需求，在现实中绝大多数场景下，业务架构驱动着技术架构，而不是反其道而行。

架构设计的维度

对于架构设计，存在几个最重要的设计维度，这些维度关注于架构设计最终的质量和结果。关于架构设计的维度或要素的划分，业界也有很多不同的说法，在本课程中，我们认为下图中展示的五个维度对于架构设计而言至关重要。

可扩展性维度

所谓可扩展性，扩展的是什么？扩展的是业务。在现有系统功能基础上，对新功能有持续扩展和提升的能力，并对现有功能影响最小。可扩展性在表现形式上体现在基础设施稳定不需要经常变更、应用之间耦合度小依赖管理简单、满足开闭原则等方面。如下图所示，现有系统 SystemA 中存在 SubSystem1、SubSystem2 和 SubSystem3 三个子系统，当我们往 SystemA 再加入一个 NewSubSystem 时，如果不需要改变原有的各个子系统而只需把新业务封闭在一个新的子系统中就能完成整体业务的升级，我们就可以认为系统具有较好的可扩展性。显然，传统的单块系统不具备良好的可扩展性，因为对系统业务进行任何一处的修改，都需要重新构建整个系统并进行发布。单块系统内部没有根据业务结构进行合理的业务拆分是导致其可扩展性低下的主要原因。

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

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

可伸缩性维度

可伸缩性和可扩展性非常容易混淆，但实际上两者完全不一样。所谓可伸缩，伸缩的是性能，即当系统性能出现问题时，如果我们只需要简单添加应用服务器等硬件设备就能避免系统出现性能瓶颈，那么该系统无疑具备较高的可伸缩性。如果资源的增加和系统能力提升是线性的，就是线性伸缩性。通常，我们会考虑采用水平伸缩的方法实现可伸缩性。当考虑水平伸缩时，一般的做法是建立一个集群，通过在集群中不断的添加新节点，然后借助前端的负载均衡器，将用户的请求按照某种算法分配到不同的节点上。

参考下图中的单块系统，某个系统的组件 A 的负载已经达到了 80%，也就是到了不得不对系统运行能力进行扩容的时候。但同一系统的其它两个组件 B 和 C 的负载还没有到其处理能力的 20%。由于该系统中的各个组件是打包在同一个 WAR 包中的，因此通过添加一个额外的系统运行实例虽然可以将需要扩容组件的负载降低一半，但是显然其他组件的利用率变得更为低下，造成资源浪费。另一方面，对于那些需要保持类似会话（Session）数据的需求而言，扩容之后的运行机制在如何保持各个服务器之间数据的一致性也存在较大的实现难度。所以对于可伸缩而言，首先要做的事情也是对系统进行合理拆分，这点与可扩展性是一致的，这也是为什么可伸缩性和可扩展性非常容易产生混淆的一大原因。

性能维度

性能的要求体现在系统在其指定的性能状况下执行，以及将来需要时提供增长的处理能力。我们可以从核心功能响应时间、系统吞吐量、部署架构的可伸缩性、性能问题的可预测性和峰值负载等方向判断系统是否存在性能问题并找到相应的解决方案。

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

可用性维度

可用性保证系统在需要时能够完整的提供服务，并有效处理影响系统可用性故障的能力。可用性的规划和实现需要先明确服务的类型，对不同类型的服务其可用性要求不尽相同。系统升级、停机和维修时间、系统备份、灾难恢复等也都需要有对应的实施计划。

架构设计策略上，一方面使用容错硬件和容错软件、确保采用主流的集群和负载均衡机制、加强日志管理和分析、采用组件复制策略、建立完整的备份和灾难恢复解决方案都属于这个维度的考虑范围之内。另一方面，我们也需要从服务之间的依赖关系入手，防止单个服务失败所引起的“雪崩效应”，超时和重试、集群容错、服务隔离、服务降级和服务限流等都是常见的实现手段。

安全性维度

安全性体现的是控制、监控和审计对资源的访问性和执行能力，以及从安全漏洞中恢复的能力。需要进行安全性控制的内容通常称之为资源（Resource），能访问资源的人或系统称为访问主体（Subject），控制安全性就是根据不同的访问主体对不同的资源进行精细化控制，包含建立完善的用户权限管理系统并提供相应安全策略。

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

综合考虑架构设计的层次和维度，我们不难发现，系统的可扩展性偏向于业务架构，而其余的伸缩性、性能、可用性和安全性则更多偏向于技术架构。但是在具体设计和实现过程中，有些设计思路和理念对业务架构和技术架构设计同样有效。在本课程中，我们分别会从业务架构和技术架构这两个主要层次出发，把架构设计的各个维度穿插在各个主题中。

架构设计的视图

架构视图是对从某一视角或某一切入点上看到的系统所做的简化描述，描述中涵盖系统的某一特定方面，而省略了与此方面无关的实体。系统架构视图代表性的有 4+1 架构视图和六维架构视图。这两种视图实际上是对同一事物的不同理解和表述方式，其本质是一致的，我们从下面的描述中也不难看到它们两者之间的共性。

4+1架构视图

Philippe Kruchten 在其著作《Rational 统一过程引论》提出了一个"4+1"视图模型，从逻辑视图、进程视图、物理视图、开发视图、场景视图等 5 个不同的视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5 个视图结合在一起才能反映系统的软件体系结构的全部内容。

• 逻辑视图

逻辑视图（Logic View）用来描述系统的功能需求，即在为实现用户服务方面系统所应该提供的功能。在逻辑视图中，系统分解成一系列的功能抽象和功能分析，这些主要来自问题领域。

在面向对象技术中，逻辑视图表现为一系列经过抽象、封装和继承的对象。基于对象模型，可以用 UML 中的类图来描述逻辑视图。类图用来显示一个类的集合以及它们之间的关联、使用、组合、继承等逻辑关系。

• 进程视图

进程视图（Process View）考虑一些非功能性的需求，如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图中的主要抽象如何与进程结构相配合在一起，即定义逻辑视图中的各个类的具体操作是在哪一个线程中被执行。所以进程视图侧重系统的运行特性并服务于系统集成人员，方便后续开展性能测试。

• 物理视图

物理视图（Physical View）主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。物理架构主要关注系统非功能性的需求，如可用性、可靠性、容错性、吞吐量和可伸缩性。

• 开发视图

开发视图（Development View）描述了在开发环境中软件的静态组织结构，即关注软件开发环境下实际模块的组织，服务于软件编程人员。将软件打包成一系列组件或子系统，这些组件和子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。

• 场景视图

场景视图（Scenarios View）综合所有的视图，用于刻画组件或子系统之间的相互关系，将四个视图有机地联系起来。该视图可以描述一个特定的视图内的组件或子系统关系，也可以将这些关系延伸到不同视图间的组件或子系统。

四种视图的元素通过一组重要场景进行无缝协同工作，在某种意义上场景是最重要的需求抽象。4+1 架构中各个视图的关系见下图，可以看到场景视图是其他视图的冗余（名称中 +1 的由来），但它起到了两个作用：作为一项驱动因素来发现架构设计过程中的架构元素；作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明，又作为架构原型测试的出发点。

如果我们用 UML 来表示 4+1 视图，则场景视图往往对应用例图，逻辑视图对应类图和对象图，开发视图对应类图和组件图，进程视图对应顺序图、协作图、状态图、活动图和组件图，部署视图对应部署图。

六维架构视图

六维架构视图为我们提供了六大视图，分别是上下文视图、功能视图、数据视图、开发视图、部署视图和运维视图。

• 上下文视图

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

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

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

• 功能视图

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

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

• 数据视图

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

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

数据架构建模有几种典型方式，包括静态数据建模、数据流建模和数据状态建模。这些数据模型代表着数据在不同场景下的不同表现形式以及发挥的作用。在 UML 中，类图、流程图和状态图分别可以作为静态数据模型、数据流模型和数据模型的建模工具。

• 开发视图

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

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

上述切入点需要结合具体的业务需求并采用特定的架构设计模型方能展现成开发视图，模块结构模型是开发视图中比较容易实现且易于展示的一种模型，在架构设计和系统开发中时常需要考虑的一些设计模式，如系统分层（领域层、业务逻辑层和表现层）以及这些层次之间的依赖关系。当然，开发视图中也可以包含一些通用的设计模型。

• 部署视图

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

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

部署架构上，运行时平台模型、网络组成模型和技术依赖关系模型需要通过部署视图展示给相关的服务发布和运维人员，特别是现在服务化架构大行其道的背景下，系统服务之间的调用关系远比传统意义上单块模式复杂，部署视图的重要性得到显著提升。UML 中，我们可以使用部署图对系统部署架构进行建模。

• 运维视图

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

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

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