1.1 架构设计基本概念

当下，业务需求层出不穷、技术发展日新月异、团队规模快速扩张，因此，软件系统复杂度及系统共性和特殊性问题在很大程度上决定了软件开发的成败。而软件架构设计（Software Architecture Design）的目的就是对系统进行高度抽象，通过一系列设计原则在最大程度上降低系统复杂度，解决系统中存在的各种共性和特殊性问题。在深入探讨架构设计过程和架构师角色之前，我们先来理解架构的基本含义。

1.1.1 架构的基本定义

我们想要成为一名架构师，有如下两个问题首先需要进行明确。

●软件架构是什么？

●软件架构设计是怎么样一种工作内容？

围绕着这两个问题，业界有一些通用的说法，这些说法形成了具有代表性的两大理论体系，分别是架构组成理论和架构决策理论。

1.架构组成理论

国际标准化组织（International Orgranization for Standardization，ISO）系统和软件工程标准认为，系统的架构是一系列基本概念或者系统在其环境中表现出来的属性，体现在它的元素、关系及设计和发展的原则中。根据ISO给出的这一架构定义，系统架构包括系统元素、基本系统属性、设计和发展原则3个主要方面。

（1）系统元素

架构的系统元素包括模块、组件、接口、子系统等日常开发中的内容。系统元素之间是有关系的，元素加上它们之间的关系就构成了基本的系统结构。通常，架构师感兴趣的结构类型包括静态结构和动态结构。所谓静态结构体现在设计时，描述系统内部设计时元素及其组合方式；而动态结构则关注运行时的元素及其交互方式。

（2）基本系统属性

架构的基本系统属性一方面包含功能属性，用于说明系统行为属性，回答系统能做什么这一问题，如系统的输入、输出模型。另一方面，系统也关注质量属性，即外部可见非功能性属性，如系统的性能、安全性等属性。

（3）设计和发展原则

架构的设计和发展原则应该能够可度量、可测试和可跟踪，常见的原则如用户操作响应时间在1s之内、用户信息需要进行安全性处理、系统可以快速集成第三方服务等。同时，对于架构的设计和发展，每个团队及架构师都可以根据需要制定适合于当前架构发展需要的自定义原则。

组成派的架构设计往往首先关注系统的主要构成部分及它们相互之间的关系，然后进一步挖掘每个构成部分的细节，以便确定模块、组件、接口等元素，并确保这些元素满足既定的架构设计原则。Web开发中常见的MVC（Model View Controller，模型—视图—控制器）模式实际上就是架构组成理论在架构风格上的体现，通过Model、View和Controller等3种基本元素及它们之间的不同交互方式构成了系统的基本架构，如图1-1所示。

2.架构决策理论

架构决策理论的典型倡导者是RUP（Rational Unified Process，统一软件过程）。该理论关注架构实践的主体—人，以人的决策为描述对象。架构决策不仅包括软件系统的组织、元素、子系统和架构风格等，还包括众多非功能性需求的决策。当架构设计过程无法顺利进行，如碰到模块如何划分、模块之间交互方式是什么、开发技术如何选型、如何适应可能发生的变化等常见问题时，通过架构师团队根据场景和问题作出相应的决策。不断决策的过程就是问题得到不断解决、架构得到不断发展的过程。通过一系列的决策最终形成完整的系统架构。

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

以上两个派别的理论体系也只是对架构定义问题的一种诠释，业界还有很多相关的说法，很难给出一个标准化的答案。每个架构师基于自身的意识形态和经历也可能会有自己的理解，通常开发人员从日常的开发过程中提炼出对架构设计的理解，被称之为架构演进理论。

1.1.2 架构演进理论

在过去软件开发过程发展的很长一段时间内，软件架构表现为一种集中式的单块（Monolithic）模式，即先对系统进行分层，然后通过单个进程进行部署和维护。典型的分层体系包括界面交互层、业务逻辑层和数据访问层。直至今日，这种单块模式在部分系统构建过程中仍然是最基本的架构模式。

随着业务功能的不断发展及性能、数据存储等系统瓶颈问题的出现，单块模块逐渐不适合系统的维护和扩展。这时，分布式架构应运而生。通过把系统业务进行服务化及完善服务治理功能，系统架构就可以如同搭建积木一样构建成高度可集成、高内聚松耦合的业务系统，图1-3所示的系统主体由Frontend-Service（前端服务）和Core-Service（核心服务）两层服务化构成，为Web层提供网关和核心业务服务。

服务化架构为系统提供了扩展性和伸缩性，然而随着系统用户体量的增加及分布式系统固有的网络通信机制，性能问题在业务关键链路逐渐成为系统运行的瓶颈。解决性能问题的切入点有很多，一方面可以从硬件设备和软件服务器入手，但对系统架构而言，更多的场合需要我们分析系统实现方案，并使用以缓存为代表的架构设计手段重构业务关键链路，图1-4即为在Frontend-Service和Core-Service两层服务中分别添加分布式缓存（Distributed Cache）之后所得到的系统部署图。

缓存能够提升性能，但不能解耦系统。当系统中分布式服务数量和种类增多，而这些服务又分别属于不同业务层次时，如何合理地管理这些服务之间的调用关系，进一步确保系统的健壮性和扩展性成为系统架构设计的又一大难题。分布式服务的自身特征决定了其在时间、空间和技术上都具有一定程度的系统耦合性。在使用分布式服务时需要谨慎处理服务调用的时序、所使用的服务定义及技术平台的差异性等问题。这些问题为开展快速架构重构和扩展、进行高效分布式团队协作带来了挑战。以各种消息传递组件为代表的中间件系统为降低系统耦合性、屏蔽技术平台差异性带来了新的思路。当不同的服务需要进行交互、但又不需要直接进行服务的定位、调用和管理时，消息中间件（Middleware）能显著降低系统的耦合程度，如图1-5所示，在Frontend-Service和Other-Service（其他服务）中添加了消息传递中间件，确保两个服务在并不需要意识到对方存在的前提下进行数据的有效传输。

试想这样一种场景，我们的系统需要跟外部的多个系统进行集成以形成关键业务链路闭环管理，而这些外部系统分别部署在其他供应商或客户环境，并且每个系统都可能基于完全不同的技术平台和体系构建，随着业务发展需求，这些外部需求还需要实现动态的注册和注销。对系统架构设计而言，一方面我们需要整合这些外部系统提供的服务进行数据的获取和操作，另一方面，我们又不希望我们的系统对它们产生强依赖。消息中间件在这种场景下已经失去系统解耦的价值，因为外部系统不在控制范围之内，我们对其内部实现原理一无所知。如何在异构系统、分布式服务和基于租户的基本架构需求下实现有效的系统集成，企业服务总线（Enterprise Service Bus，ESB）提供了相应的解决方案。通过在核心业务服务中引入ESB及对应的路由、过滤、转换、端点等系统集成模式，即可屏蔽由于技术差异性导致的各种系统集成问题，并动态管理ESB上的第三方服务。图1-6中的ESB为内部的Core-Service整合外部的Thirdparty-Service1和Thirdparty-Service2提供了集成平台。

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

上述系统架构演进过程在现有的互联网应用中具有一定的代表性，很多APP（Application，应用程序）后台就是从一个简单的单块模式开始，当面临系统架构设计问题时，通过引入各种技术系统逐步完善架构，直至具备庞大体量的大型集群系统。在这个系统架构演进过程中，我们再来回答“什么是系统架构设计”这个问题时，我们就可以认为系统架构设计是在系统开发演化过程中，解决一系列问题的方法论和工程实践。

方法论和工程实践包含了系统构成的各种结构化元素，包含了系统交互的各种接口和相互协作方式，包含了通用的指导性架构风格。更为重要的是，通过引入方法论和工程实践进行系统架构演进是一个“原型→发现/改进→再发现/再改进”的过程。这显然已经不是一个纯粹的技术问题，而是一项涉及多个软件开发维度的系统工程。

1.1.3 架构设计与系统工程

架构设计是一项系统工程，而系统工程本质上是一个多学科工程，涉及软件开发的技术和管理两方面。一般而言，系统工程可以简单描述为一种人、工具、流程等基本构成元素的组合，图1-8即是对架构设计系统工程的一种描述方法。

我们通过上图把架构设计通过系统工程的方法展开，可以清晰地看到以下几点核心思维。

1.人

架构设计中的人除了架构师本身主要指的是各种干系人（Stakeholder）。所谓干系人，就是架构所需要满足的各种业务方、客户、市场、项目、产品等相关人员。这些干系人代表着功能需求的来源，同时拥有对系统架构是否成功的判断权利。架构设计本质是满足业务需求，业务架构驱动着技术架构，而不是反其道而行。系统工程的第一点核心思路就是我们从事任何架构设计相关的工作都是为了满足干系人的需求。

2.事

架构设计中的事主要包括描述架构和展示架构。架构描述代表着使用特定的工具、特定的流程和特定的视图视角创建、记录和维护架构。架构展示则把描述出来的架构在合适的时机和场合展示给相关干系人供其参考和判断。无论是架构描述还是架构展示都不是一步能够到位的，所以系统工程的第二个核心思路就是我们要站在过程管理的思维模式上去看待架构设计这件事情：架构设计本身也是一个过程，过程就需要通过计划、实施、监控、管理等方法确保其执行，并通过持续改进实现过程的高效性和正确性。

3.物

架构设计相关系统工程的物指的就是所设计的架构及对应的架构描述。架构描述并不只是架构师的个人成果，而是架构师及相关干系人共同确认的成果，用于构建系统，以满足业务需求。系统工程的第三个核心思路就是需要提供架构设计产物的可见性，同时确保具备较高设计质量，使其能够接受来自内部和外部的评审和验证。

综上所述，架构设计就是以干系人提出的业务需求为源头、以技术管理和过程改进体系为工作流程、以质量为重心的一项系统工程。在系统工程中，业务需求需要进行分析和抽象、过程需要进行管理和改进、设计质量需要进行保障，完成包含这些活动在内的整个系统架构设计工作的角色就是架构师。