软件架构的艺术

1，架构与架构师

1.1 架构

架构这个词来源于建筑学。建筑学中把架构定义为：人们对一个结果内的元素及元素之间的关系的一种主观映射和各种技术的实现。同时，建筑学中也认为，架构最主要的是指系统架构，而系统架构的主要任务是界定系统级的功能和非功能需求、规划并设计实现系统级的各项要求，用时利用各种科学技术来实现各个子系统的结构构建。

由此引申而来，一般认为软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

关于软件架构的定义，一直没有一个统一的说法，这里摘录一些比较主流的定义：

软件体系结构是由具有特定形式的体系结构元素或设计元素构成，包括处理元素、数据元素和连接元素。 

软件体系结构包括组件、组件的外部可见性以及相互的关系。其中软件组件的外部可见性是指软件组件提供的服务、性能、特性、共享资源使用等。该定义强调体系结构分析需要从系统中抽象出用于分析、决策的信息。

软件架构包含了关于以下问题的重要决策： 软件系统的组织、选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为、如何组合这些元素，使它们逐渐合成为更大的子系统、用于指导这个系统组织的架构风格

从这些定义中我们可以发现架构关注的东西：元素、关系、决策。

架构也有其生命周期，一般可分为：初步构建阶段、逐步优化阶段、成熟阶段、老化阶段、消亡阶段。

1.2 架构师

架构师就是去完成架构的那个人。软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。

本书中对软件架构师的主要职责做出了定义：

平衡：持续不断的在各个维度和不同的需求之间进行平衡。平衡各个stakeholder的要求；平衡时间、成本、特征、质量等各个点。

Trade-Off是一种现实，也是架构师最需要修炼的能力。

一致：保持各个stakeholder需求的一致性、保持产品和系统概念的一致性。

人月神话中提到为了保证系统概念的一致性，需要一定的专制。我想架构师就是这个专制者。

分解：将大规模系统的复杂性分解，最常规的办法是将大系统分解成许多子系统，从而降低复杂度。

软件设计的根本问题就是分解复杂性。

集成：将分解后的系统集成。从而保证各个子系统能够有效的沟通协作，有机的成为一个整体。

纵览：纵观整个系统及其存在的商业背景以便于制定出重要的设计指导规则和控制规则。委负责具体部分的设计人员提供全方位的视角和商业情节。

简洁和优美：尽量保持整个设计的见解和优美，这是架构的最大艺术。

保持完整：保持系统的要求能够平衡均匀的、有侧重的、逐步的、完整的得到实施。

吻合：在产品或项目启动、设计、开发、运行维护、服务等完整的生命周期内，架构师的工作要吻合各个stakeholder的要求

由此引申出架构师应该具备的一些能力：专业技能、商业经验、沟通能力、平衡决策能力、多任务处理能力、规划能力、驱动能力。

2，主要的架构问题

2.1  架构师的主要工作

本书中概括了架构师的主要工作如下：

（1）平衡功能与性能要求、分析软件系统质量要求和其他系统特征。

（2）控制和处理有关系统粒度、范围、包含、连接和耦合的问题。

（3）澄清接口策略，制定接口架构约束原则。

（4）计划系统资源的分配与调度原则。

（5）文档业务关系模型。

（6）定系统身份识别、认证、命名。存取控制的策略。

（7）规划系统静态特征和动态行为转化模型。

（8）确立系统的基础框架组成，稳定架构基线。

（9）按照外在环境和内在制约因素选择相应开发流程，规划开发环境、开发工具、测试工具版本控制工具等。

（10）确定监控与报告流程，选择有效汇总、统计、分析、报告的工具。

（11）为软件设计与开发制定架构约束及架构原则，并确保后续开发遵循相关原则。

（12）软件系统的部署、初始化、装载顺序、卸载顺序、运行监控等系统运行时规则。

（13）软件系统测试、交付的原则以及计划。

（14）按照外在环境和内在制约因素选择开发技术。

（15）规划软件系统哪些部分自主研发，哪些部分外包开发或外购产品。

我觉得把上面的工作概括起来，可以分为四大类的事情：确认需求、系统分解、技术选型、制定技术规格说明书。

2.2  架构的主要问题与解决模式

架构问题一般包括商业问题、系统架构问题、设计问题以及编码实施问题，由于架构的最终目的是完成一个产品去满足客户的需求，所以商业问题是所有问题的核心。可以说商业问题的解决好坏直接决定了产品或项目的成败。

商业问题的解决一般有以下的一些模式：业务容错模型（业务错误的累积、报警、触发处理的方式）、责任关系模型（明确组织结构的层次与责任）、度量和观察模型、企业财务模型、对象的引用模型、库存与记账模型、应用财务模型、商业计划模型、商业交易模型、衍生合同模型、业务分解模型 。

系统架构的问题可以由系统架构模式来解决。架构模式是指一个架构模式表达了一个软件系统基本的组织结构方式或系统的构成方式。盖家沟模式帮助界定了子系统的组成，指定了各个子系统的职责，并且制定了组织各个子系统间关联关系的规则或指南。可以认为它是子系统与组件级的设计，主要关注以下问题：

子系统内部如何组成、如何工作的设计；

各个子系统是如何进行交互或通信的设计；

每个构件内部是如何组成、如何工作的设计；

各个构件是如何进行交互或通信的设计。

主要的模式有：客户端-服务器架构风格

分布式计算风格

对等计算架构风格

黑板架构风格

隐式调用架构风格

Pipes and filters架构风格

插件架构风格

整体化架构风格

分层架构风格

结构化风格（基于模块化）

系统组件化风格

面向服务的架构风格

面向搜索架构风格

基于空间的架构风格

SharedNothing架构风格（应用程序没有自己的数据缓存，完全依赖于对数据库的存取）

设计的问题一般可以由各种设计模式来解决。设计问题包括：

商业设计模式：用来识别商业参与者，帮助界定在不同商业场景下他们之间的交互关系。

集成设计模式：将各个商业模式集成为一体，形成统一的商业解决方案，并且识别了商业问题、 商业流程和规则。

组合设计模式：帮助准确的识别商业模式和集成模式的选用条件与组合形式。

应用设计模式：一个商业或继承模式可以由多个应用模式来实现。一个应用设计模式代表了应用的粗粒度结构，如主要构件的组成、处理功能的分布、数据的部署等。

运行时设计模式：应用设计模式可以被很多运行时设计模式来实现，但这些运行时设计模式主要用来保障质量方面的要求，如性能、容量、有效性等。

另外，还有我们经常提到和使用的23中设计模式。

编码实施问题的解决取决于程序员的经验和素质，但是也是有一些Idiom可以借鉴的。如内存管理、对象创建、接口应用、异常处理、并发处理等都一些被许多次实践证明有效的方法。

总而言之，商业概念模型与分析模型帮助架构师捕获商业结构、商业流程及商业规则；系统架构模式帮助架构师定义软件系统和各子系统的结构骨架；设计模式帮助人员构建构件结构及其联系；IDIOM设计模式这种底层经验能够确保编程实现的质量。

3，架构恢复与重构

3.1 架构恢复与重构的方法

对一些成熟的系统，要延缓其衰老的时间，必须对原系统做出一些改变。这种手段就是系统架构的恢复与重构。它的核心目的就是将含糊的 架构和设计梳理清晰，之后进行架构重构和优化，使系统重焕生机，以便以后的扩展和维护。

架构的恢复和重构可以从以下几个阶段依次展开：确立反向和正向工程的概念、架构和设计恢复、架构和设计重构、系统代码重构。

第一步便是，确立反向和正向工程的概念，这一步也可以叫做系统重组（Reengineering）。它包括反向工程和正向工程。其中反向工程（Reverse-engineering）包括：

系统分析和架构恢复：弄明白这是个什么样的系统。

SWOT分析：分析系统的优缺点、面临的威胁和改建的机会。

抉择：根据前两部分析的结果来决定是保留还是抛弃这个系统。

而正向工程（Forward-engineering）包括：

建立新的架构远景：包含了以往可用的架构组成部分及计划添加、修改、替换的部分。

建立新的架构基线：将新的架构部分逐渐装进系统架构中，然后立即重构。逐渐的提炼和优化形成新的架构基线。

代码重构：将新的代码部分逐渐装进系统架构中，然后立即重构。逐渐的提炼和优化形成新的代码基线。

第二步就是系统架构的恢复，就是把系统还原成它最初设计的初衷和依据的原理。可以说架构恢复是建立在反向工程基础之上的。它主要包括以下部分：对底层结构的恢复、对高层概念的恢复、对程序部分结构组成的恢复、程序代码综合结构恢复、系统结构恢复、基于领域知识和模型的架构恢复、基于设计模式的架构恢复。

一般可将架构恢复划分为五个主要的流程阶段：

系统概念和需求恢复阶段：建立对系统概念和认知，包括业务领域、服务内容、行为轮廓、用户初始需求等，明确界定此次恢复的目标。

系统功能恢复阶段：完整恢复系统所覆盖的业务功能，使用户需求更丰满。

系统架构和设计恢复阶段：根据前面获得的信息，进行架构猜想的建立和验证。

系统编码恢复阶段：将系统代码的结构和关系进行恢复

汇总/对应和验证阶段：验证新的系统，汇总各种文档并使之系统化，以便以后的维护。

第三步是系统架构和设计的重构。它包括文档重构、流程重构、测试重构、数据库重构和组织结构的重构。架构和设计重构的核心任务是按照“不断地去否定以往的系统架构和设计”的原则，力图找到架构和设计中的“坏味道”，然后在不改变系统行为的基础上，调整系统的内部结构，最终使其达到优化的目的。

在这一步可以采用一些重构模式：实体重新命名、转移重复元素、利用抽象的层次结构、以适配方式代替中介方式、合并子系统、强化层间调用、以Message代替RPC、以Caching方式优化资源利用、避免构建Interface的膨胀、使用配置子系统/构件、保持架构和设计的对称。

最后一步就是系统代码重构。经过架构和设计的重构之后，需要在代码层进行重构，以最终完成整个系统的恢复与重构。在系统代码重构中需要注意以下点：

必须创建相应的大量测试用例和Test Suite；

代码重构要遵循小步调的工作规模（小计划、小构想、小改动、小测试）；

先拿问题最严重或最危险的部分开刀；

一定要利用测试进行验证，如果测试失败，就需要重复进行上述动作。

在这一步也有一些模式可以利用，如：方法抽取、方法上移（方法上移至父类）以及使用有语义的变量名等。