软件架构师：分析和设计软件系统及管理其研发过程。需要具备专业的知识、丰富的实践经验及良好的个人综合能力。

1.1架构设计基本概念

软件架构设计（Software Architecture Design）的目的：对系统进行高度抽象，通过一系列设计原则在最大程度上降低系统复杂度，解决系统中存在的各种共性和特殊性问题。

1.1.1架构的基本定义

1.架构组成理论

国际标准化组织（International Orgranization for Standardization， ISO）认为任务系统的架构是一系列基本概念或者系统在其环境中表现出来的属性，体现在它的元素、关系及设计和发展的原则中。

（1）系统属性

架构的系统元素包括模块、组件、接口、子系统等日常开发中的内容。系统元素之间是有关系的。

基本的系统架构是由元素加上它们之间的关系构成的。

静态结构体现在设计时，描述系统内部设计时元素及其组合方式。

动态结构则关注运行时的元素及其交互方式。

（2）基本系统属性

功能属性：用于说明系统行为属性，回答系统能做什么这一问题，如系统的输入输出模型。

质量属性：即外部可见非功能性属性，如系统的性能、安全性等属性。

（3）设计和发展原则

架构的设计和发展应该是能够可度量、可测试和可跟踪。（类似于质量属性：性能、可靠性、可用性、安全性、可修改性、功能性、可变性、互操作性）

对于架构的设计和发展，每个团队及架构师都可以根据需要制定适合于当前架构发展需要的自定义原则。

（4）总结：组成派的架构设计

组成派的架构设计往往

首先关注系统的主要构成部分及他们相互之间的关系，

然后进一步挖掘每个构成部分的细节，以便确定模块、组件、接口等元素，并确保这些元素满足既定的架构设计原则。

常见的MVC（Model View Controll，模型-视图-控制器）就是架构组成理论在架构风格上的体现。

2.架构决策理论

RUP（Rational Unified Process，统一软件过程）。

该理论关注架构实践的主体-人，以人的决策为描述对象。

架构决策不仅包括软件系统的组织、元素、子系统和架构风格等，还包括众多非功能性需求的决策。当架构设计过程无法顺利进行，如碰到模块如何划分、模块之间交互方式是什么、开发技术如何选型、如何适应可能发生的变化等常见问题时，通过架构师团队根据场景和问题做出响应的决策。不断的决策过程就是问题不断得到解决、架构得到不断发展的过程。通过一系列的决策最终形成完整的系统架构。

决策类的架构设计过程往往可以从系统切分出发，如把系统分成客户端和服务器端两大部分，然后基于服务器端，可以在拆分成服务适配层、业务逻辑层和数据访问层，而业务逻辑层再可以分成多个模块，如图1-2所示。每一个切分的过程实际上就是一个决策的过程，通过合理而有效的决策促进系统架构由高层次到较低层次再到实现层次的不断演进。

3.总结：架构演进理论

架构定义的问题很难给出一个标准化的答案。每个架构师基于自身的意识形态和经历也可能会有自己的理解，通常开发人员从日常的开发过程中提炼出对架构设计的理解，被称之为架构演进理论。

1.1.2架构演进理论

（1）集中式的单块模式

在过去很长一段时间内，软件架构表现为一种集中式的单块(Monolithic)模式，即先对系统进行分层，然后通过单个进程进行部署和维护。

典型的分层体系包括界面交互层业务逻辑层和数据访问层。直至今日，这种单块模式在部分系统构建过程中仍然是最基本的架构模式。

（2）分布式服务化架构

随着业务功能的不断发展及性能、数据存储等系统瓶颈问题的出现，单块模块逐渐不适合系统的维护和扩展。

这时，分布式架构应运而生。通过把系统业务进行服务化及完善服务治理功能系统架构就可以如同搭建积木一样构建成高度可集成、高内聚松耦合的业务系统。

图1-3所示的系统主体由Frontend-Service(前端服务)和Core-Service(核心服务)两层服务化构成，为 Web层提供网关和核心业务服务。

（3）分布式缓存

服务化架构为系统提供了扩展性和伸缩性，然而随着系统用户体量的增加及分布式系统固有的网络通信机制,性能问题在业务关键链路逐渐成为系统运行的瓶颈。

解决性能问题的切入点有很多：

一方面可以从硬件设备和软件服务器入手，

但对系统架构而言，更多的场合需要我们分析系统实现方案，并使用以缓存为代表的架构设计手段重构业务关键链路。

图1-4即为在Frontend-Service 和Core-Service两层服务中分别添加分布式缓存(Distributed Cache)之后所得到的系统部署图。

（4）中间件系统

当系统中分布式服务数量和种类增多，而这些服务又分别属于不同业务层次时，如何合理地管理这些服务之间的调用关系，进一步确保系统的健壮性和扩展性成为系统架构设计的又一大难题。

分布式服务的自身特征决定了其在时间、空间和技术上都具有一定程度的系统耦合性。在使用分布式服务时需要谨慎处理服务调用的时序、所使用的服务定义及技术平台的差异性等问题。这些问题为开展快速架构重构和扩展、进行高效分布式团队协作带来了挑战。

以各种消息传递组件为代表的中间件系统为降低系统耦合性、屏蔽技术平台差异性带来了新的思路。当不同的服务需要进行交互、但又不需要直接进行服务的定位、调用和管理时,消息中间件( Middleware)能显著降低系统的耦合程度。

如图1-5所示,在Frontend-Service和 Other-Service(其他服务)中添加了消息传递中间件，确保两个服务在并不需要意识到对方存在的前提下进行数据的有效传输。

（5）企业服务总线（Enterprise Service Bus，ESB）

试想这样一种场景，我们的系统需要跟外部的多个系统进行集成以形成关键业务链路闭环管理，而这些外部系统分别部署在其他供应商或客户环境，并且每个系统都可能基于完全不同的技术平台和体系构建，随着业务发展需求，这些外部需求还需要实现动态的注册和注销。对系统架构设计而言，一方面我们需要整合这些外部系统提供的服务进行数据的获取和操作，另一方面，我们又不希望我们的系统对它们产生强依赖。消息中间件在这种场景下已经失去系统解耦的价值,因为外部系统不在控制范围之内，我们对其内部实现原理一无所知。

如何在异构系统、分布式服务和基于租户的基本架构需求下实现有效的系统集成,企业服务总线(Enterprise Service Bus,ESB提供了相应的解决方案。通过在核心业务服务中引入ESB及对应的路由、过滤、转换、端点等系统集成模式，即可屏蔽由于技术差异性导致的各种系统集成问题，并动态管理 ESB上的第三方服务。图1-6中的ESB为内部的 Core-Service整合外部的 Thirdparty-Servicel和 Thirdparty-Service2提供了集成平台。

（6）批量数据处理架构

随着大数据时代的到来，许多业务系统也面临着对庞大业务数据进行管理和利用的难题。

近年来，以Hadoop生态圈为代表的大数据处理平台，以及以Lucene为内核的多种垂直化搜索引擎（Search Engine)系统，为业务发展提供了高效的批量数据处理和数据搜索功能。在系统架构设计维度，我们也可以引人如 Spring Batch、Spring Data等轻量级的批处理(Batch Job)和数据访问框架，以便与基于Spring的核心系统构建框架进行无缝整合，如图1-7所示。

（7）总结

在这个系统架构演进过程中，我们再来回答“什么是系统架构设计”这个问题时，我们就可以认为系统架构设计是在系统开发演化过程中，解决一系列问题的方法论和工程实践。

方法论和工程实践包含了系统构成的各种结构化元素，包含了系统交互的各种接口和相互协作方式，包含了通用的指导性架构风格。更为重要的是，通过引入方法论和工程实践进行系统架构演进是一个“原型一发现/改进一再发现/再改进”的过程。

1.1.3架构设计与系统工程

架构设计是一项系统工程，而系统工程本质上是一个多学科工程，涉及软件开发的技术和管理两方面。

一般而言，系统工程可以简单描述为一种人、工具、流程等基本构成元素的组合，图1-8即是对架构设计系统工程的一种描述方法。

1.人

架构设计中的人除了架构师本身主要指的是各种干系人(Stakeholder)。

所谓干系人，就是架构所需要满足的各种业务方、客户、市场、项目、产品等相关人员。这些干系人代表着功能需求的来源，同时拥有对系统架构是否成功的判断权利。

架构设计本质是满足业务需求，业务架构驱动着技术架构，而不是反其道而行。

系统工程的第一点核心思路就是我们从事任何架构设计相关的工作都是为了满足干系人的需求。

2.事

架构设计中的事主要包括描述架构和展示架构。

架构描述代表着使用特定的工具、特定的流程和特定的视图视角创建、记录和维护架构。

架构展示则把描述出来的架构在合适的时机和场合展示给相关干系人供其参考和判断。

无论是架构描述还是架构展示都不是一步能够到位的，所以系统工程的第二个核心思路就是我们要站在过程管理的思维模式上去看待架构设计这件事情:架构设计本身也是一个过程，过程就需要通过计划、实施、监控、管理等方法确保其执行，并通过持续改进实现过程的高效性和正确性。

3.物

架构设计相关系统工程的物指的就是所设计的架构及对应的架构描述。

架构描述并不只是架构师的个人成果，而是架构师及相关干系人共同确认的成果，用于构建系统，以满足业务需求。

系统工程的第三个核心思路就是需要提供架构设计产物的可见性，同时确保具备较高设计质量使其能够接受来自内部和外部的评审和验证。

4.总结

综上所述，架构设计就是以干系人提出的业务需求为源头、以技术管理和过程改进体系为工作流程、以质量为重心的一项系统工程。

在系统工程中，业务需求需要进行分析和抽象、过程需要进行管理和改进、设计质量需要进行保障，完成包含这些活动在内的整个系统架构设计工作的角色就是架构师。

1.2剖析架构师角色

架构设计被认为是从问题领域到解决方案的一种桥梁。

如图1-9所示。从图中我们可以看到架构设计活动与代表问题域的需求分析活动和代表解决域的软件开发活动都有直接交集，连接着两个软件开发的核心领域。

架构师是架构设计的执行者。架构师需要能够从问题领域出发推导出满足业务需求的架构体系，同时又能够从实现方法入手设计出能够满足业务架构需求的技术架构体系，最终实现业务架构和技术架构的统一。

1.2.1架构师角色

1.架构师的活动与系统工程

架构师是负责设计、记录和领导能够满足所有干系人需求的系统构建过程的人。通常，这个角色需要完成以下4项工作。

(1)识别干系人并让他们参与进来

(2)理解和记录系统功能和非功能相关的关注点

(3)创建并拥有应对这些关注点的架构定义

(4)在把架构实现为具体系统的过程中起主要作用

从系统工程维度：

架构师根据干系人的业务需求捕获系统功能和非功能相关的关注点，并创建架构描述。

架构师对架构描述这一架构设计产物具有拥有权，意味着架构师有权力更有责任维护架构描述并管理其实时性和有效性。

同时,架构设计表现在系统过程中是一系列架构定义过程架构过程的正确性决定着架构结果的正确性，架构师需要跟踪并验证架构定义过程的时机、参与者、技术评审和各项阶段性成果。

架构师角色及其职责的系统工程如图1-11所示。

2.架构师的分类

狭义上的架构师往往偏重于技术架构设计。

但从广义上讲，业界对架构师的划分有一定的体系：

(1)根据作用

根据所发挥的核心作用，可以把架构师划分成设计型、救火型、布道型、极客型等类型。

相较于传统意义上的设计型架构师，救火型、布道型、极客型等类型的架构师更加偏重于执行某一项特定的架构任务，并不一定会完整参与系统开发生命周期，更不一定会从系统工程的角度去看问题。
(2)根据职责

产品型、基础设施型和应用型等架构师是从其所处的业务和职责出发进行分类的结果。

产品型架构师偏重于进行业务架构设计，往往在系统开发前期会重点参与;

基础设施型架构师偏重于进行技术基础框架设计，一般采用独立于系统开发生命周期的特有开发模式;

常见的系统架构师指的是应用型架构师，正如前文所述，负责将问题领域进行建模并转变成解决方案。
(3)根据关注层次
架构师关注的层次有很多，不同的架构师关注的层次会有所不同，包括但不限于功能、非功能、团队组织和管理、产品运营等方面。

3.架构师的技能和职责

针对应用设计型架构师，所需的技能不仅仅限于了解和掌握技术体系，也需要从另外两个层面进行技能拓展。

(1)业务领域知识：架构师应该具备跨领域的技能。

(2)软技能：架构师应该具备跨团队的技能。

技术-业务-团队

架构师的基本职责有3点。

（1）作为技术负责人，从问题领域出发进行抽象和建模并提供系统解决方案。

（2）与项目经理合作，制定计划、分配资源、组建团队。

（3）通过自身影响力和协作能力，保证项目按既定计划和成本完成。

1.2.2当程序员遇到架构师

对比：思维模式、沟通、学习、协作、推动力、全局高度、方法论、业务、时间管理、系统化、产品交付、实用主义

1.3架构师的视图和视角

1.3.1架构师的视图

架构视图面向需求，主要回答“有没有”这个问题。

每一个视图包含以下三部分：定义、切入点、架构设计。

所有的视图都是围绕架构设计展开的，但又各自有侧重点。

1.上下文视图

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

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

架构设计：上下文视图总结我们所设计的架构背后究竟是怎么样的一个系统，包括系统本身、外部实体和相关接口。

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

2.功能视图

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

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

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

图1-14就是图1-13 中上下文视图所对应的功能视图，采用 UML(Unified Modeling Language，统一建模语言)中组件图进行绘制，可以进一步看到组件之间的接口和依赖关系。

3.数据视图

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

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

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

图 1-15 代表一个移动医疗行业中“病人”这一数据载体所展现的类图，而图1-16是围绕电商行业“订单”之一概念所做的数据状态图。两个示例都能在特定场景下为系统架构提供所需的数据视图。

4.开发视图

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

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

架构设计：上述切人点需要结合具体的业务需求并采用特定的架构设计模型方能展现成开发视图。模块结构模型是开发视图中比较容易实现且易于展示的一种模型。

图1-17就是一个涉及用户和商品管理的电商系统中所展示出来的模块结构图，采用了UML中的包图作为特定展示媒介。从图中我们可以看到在架构设计和系统开发中时常需要考虑的一些设计模式，如系统分层(领域层、业务逻辑层和表现层)及这些层次之间的依赖关系。当然，开发视图中也可以包含一些通用的设计模型。

5.部署视图

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

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

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

图1-18就是一个典型的系统部署视图,包含了若干个服务提供者和消费者，这些服务通过Zookeeper进行分布式环境的集中式协调和管理。

6.运维视图

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

切入点：运维视图和部署视图一样，切入点通常都比较程式化，如建立隔离的生产环境、运行时的功能/数据迁移、状态/性能监控、集中式或分布式的配置管理、数据和系统的备份和还原及提供各项技术支持等都是常见的运维要求。
架构设计：架构设计上，运维视图的目的是为了保证服务的稳定性和可用性，并在系统出现运行故障时能够进行容错和快速恢复。这其中包括安装、迁移、管理和支持活动，并且希望这些活动能够尽量做到自动化。

7.总结

六大视图之间虽然各自表现架构的某个方面，但也存在依赖关系，

1.3.2架构师的视角

架构视角面向质量，主要回答“好不好”这个问题。

类似质量属性。质量属性作为重要章节单独学习，这里提到的四个质量属性直接融合到八大质量属性中学习。

1.3.3视图视角与系统工程

视图视角的关系：架构视图和架构视角垂直构成完整架构描述。我们可以在明确架构视图的前提下，往各个架构视图中添加架构视角，使视图和视角在完成各自目标的同时能够紧密整合。
系统工程与视图视角的关系：回到系统工程，架构视图和架构视角也是系统工程的组成部分。

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

1.4 程序员如何向架构师成功转型

1.4.1转型成功的三段式模型

1.思路

架构师转型的想法受以下3个方面限制:意识形态(Mindset)、环境(Environment)和决心(Determination)。

2.方法论

3.工程实践

提倡使用各种最佳实践(BestPractice)。最佳实践是一个管理学既念，认为存在某种技术、方法、过程、活动或机制可以使生产或管理实践的结果达到最优，并咸少出错的可能性。把软件开发的最佳方式和开发人员个人做得最好的事项一一总结出来，就是组织的最佳实践。最佳实践包含在技术和非技术领域，包含在对人和事物的处理过程，也包含在梁构师所应具备的各项软、硬能力中。

1.4.2转型思维导图

架构师转型面临的巨大挑战来自于架构师的工作特性及康威定律。

康威定律(Conway's Law)指出设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。

康威定律给我们的指导是设计系统架构之前，先看清组织结构和组织文化，再根据情况设计并调整系统架构。要做到这一点，架构师应该具备较高的综合能力。

面对架构师转型所需要克服的各项挑战及康威定律给我们带来的启示,结合转型成功所需要的三段式模型，我们得出了图1-24的转型思维导图。

1.4.3 作为架构师开展工作

1.识别干系人

识别干系人的首要问题是明确谁是干系人。

2.确定原则

3.分析业务场景

业务场景分析需要先对场景进行分类，可以分为功能性场景和系统质量场景两大类，分别对应架构视图和架构视角。

4.使用架构模式

所谓架构模式就是解决问题通用的方法和结构。

5.构建系统模型

系统建模通常使用统一建模语言UML。

6.完成技术方案

对于系统架构设计，技术方案即架构描述，

7.评估与决策

评估是过程不是结果，评估的目的是与干系人达成一致。

8.管理过程事务

9.开发并学习