浅谈企业应用架构（一）

作者：Anders小明
2009年5月5日
 

一、什么是架构

在牛津高阶词典（第7版）中，架构（architecture）一词的解释是：the design an structure of a computer system，而架构师（architect）一词的解释是：a person who is responsible for planning or creating an idea, an event or a situation。

针对于企业应用，依据不同的关注点，架构可以分为如下几类：

业务架构（Business Architecture）：关注于业务及其流程；

应用架构（Application Architecture）：关注于应用系统设计；

基础架构（Infrastructure Architecture）：关注于基础技术；

数据架构（Data Architecture）：关注于数据存储及其规划；

这里所说的企业应用架构，即属于应用架构，包括如下几个部分：

1.目标和愿景。即应用系统所面临的问题域。

2.评价指标。从哪些纬度和指标来评价和度量解决方案。

3.原则和方法论。为解决这些问题，所采用的原则及其方法论。

4.技术架构。架构的技术层面，给出相应的设计以及结构，描述应用系统。

5.组织因素。架构的组织层面，组织的各个部分如何参与。

 

二、架构的目标和愿景

1. 架构的问题来源

1.     外部，客户要求包括了业务和技术上。

2.     内部，组织管理、项目管理和技术发展上。

特别的，架构需要解决的非业务问题包括如下：

A.系统目标：系统性能，稳定性等。

B.项目目标：开发成本，项目质量等

C.项目过程：需求的不确定性和开发过程的团队协作性，即所谓的开发管理。

2. 架构的核心问题

问题可分解为两种类型，业务上和技术上。

1. 业务上。问题域分解为，逻辑的纵向抽象层次，以及逻辑的横向模块分解和集成。

2. 技术上。问题域分解为，纵向的技术主题，以及横向的技术职责的分解和集成。

A.领域化

传统的架构模式是三层或者四层模式，虽然从技术上有效的横向分解系统结构，但对业务模型如何建立，如何进行层次间传递，模型间关联关系，以及与服务逻辑耦合等问题没有给出进一步的细化，也带来了很多问题。

此外，在传统设计方法下，分析模型和设计模型的转换也是一个大的问题。

B.组件化

实施组件化或者说模块化，其需求分为两个层面。

1.内部管理，可以帮助开发过程中进行业务切分，帮助控制进度，降低风险，以及财务分析；对于大型复杂的项目，也有利于知识的传递和积累。

2.销售需要，All in one的系统因不符合发展趋势而不利于销售；组件化有助于产品销售，可以针对客户，将若干组件打包销售，同时减少集成的风险。

C.产品化

C.1 定制化问题

定制化问题的由来：1.面向行业的应用通常没有标准，或者完备的标准；2.通常产品的开发是针对于通用或者公共需求，不针对于特定客户；3.而一个确定的客户，其自身的业务差异和管理差异导致需求的差异性。

这种现象尤其在缺乏标准的行业应用中，以及系统的产品化过程中。

传统的简单的解决方式是为每个客户单独维护一个系统分支，在此情况下提供维护和升级，则维护成本巨大；因此如何解决领域的定制化就成为一个重大问题。   

C.2 升级问题

领域需求每次进一步的挖掘和实现，都意味着领域的升级。但升级面临的诸多问题:数据迁移,旧版本的兼容问题，依赖关联等等，在组件化和定制化情况下，还面临定制化兼容和冲突检测。

C.3 国际化问题

1.文本消息国际化

国际化消息没有直接呈现，而是中间存储后呈现；

2.布局国际化

阿拉伯人是从右到左；

3.业务时间，跨时区；

4.计量单位，多币种；

D.平台化

应用系统可以分为两个内容：应用程序和基础设施。应用程序处理业务问题，而基础设施处理技术问题。

来自客户的要求是包含业务和技术两个方面。其中技术上包括两种“定型和定性”，其所需的知识和技能是不同于业务上的；

此外，内部管理也提出相应的要求。由于技术的发展和业务发展之间的不同步，对于一个产品而言，同时存在技术升级和业务升级两个需求。而同时升级存在较大的成本和风险。

同时对于一个产品来说，技术方面需要较强的适应性，能够低成本上的适应客户的特别要求。

因此有效解藕技术和业务两个部分成为必然。

3. 架构的应用问题

A.事务管理

数据一致性问题出现的原因通常是开发过程中，由于错误的并发和事务控制导致的；而在业务过程中也存在错误的业务操作情况。

B.并发处理

不同的业务应用存在不同的并发场景（并发度以及存在的业务依赖），因此业务上需要明确原则和方案；而不同平台所支持的并发方式和能力也不相同，则采用一定框架支持有助于简化问题。

C.集成能力

业务应用所面临的集成问题不同，包括不同的集成环境：外部系统，内部系统，遗留系统等；不同的集成模式：基于文件，基于数据库表，基于消息等，导致所需的集成方法及其能力也不同。

4. 架构的设计问题

分析设计和开发实现存在着一定的差异性：分析设计属于知识级，而开发实现属于操作级的。

分析设计是需求和实现的中间桥梁，因而设计必须解决系统边界的合法性，内部逻辑解藕的合理性和实现的可达性（设计的类方法为实现的30%-70%）。而开发实现需不断重构代码，采用约定和框架能力等技术手段解决开发的实际问题，解决程序级别的健壮性，可读性，可维护性以及可测试性。

传统的方式，分析设计存在于文档中，而开发实现存在于代码中。两者的割裂导致沟通的困难，也导致了开发工程中具大的风险——分析设计和最终开发实现的不一致性。

三、架构的评价指标

1. 财务角度

在传统的财务核算机制中，系统或者产品的开发通常属于成本中心，对于IT企业来说，电脑设备，办公室等属于沉没成本，而IT人员的工资属于可变成本，是成本的核心部分，为了控制成本，就需要减少项目的开发时间。

因此架构一个重要的关注点在于控制开发成本和维护成本，通常讲维护成本是开发成本的3倍。降低开发成本核心，在于提高效率、提高适应需求变化的能力。

2. 技术角度

技术角度评估架构很难说一个架构行或者不行。技术角度需要给出的最大指标是风险性。而风险性和各个指标因数有很大相关，但还需要结合相应实际情况判断。例如：如果决定了不可能换数据库，那么即便强绑定oracle也没有特别的风险。

以下指标参考了架构的质量特性，但进行了裁减。

A.内部指标

1.侵入性。或者说是可迁移性，即系统与外部资源的关联关系，以及系统内部的关联关系。例如，如果架构决定使用pl/sql，那么就意味着架构和Oracle数据库是强绑定。

2.重复性。虽然我们都知道关于重复的两个原则（1.不要重复，2.不要自己重复），但是有时重复看上去无法避免，那么就是判断这个重复性带来的问题有多大。

3.扩展性。即架构提供何种条件下的何种扩展和变化能力，及其成本。

4.平稳性。在业务或技术扩展时的，架构所呈现的发展态性。

5.抽象性。即可视性，并包括了概念完整性。系统是否完整以及层次化的反映应用问题，能否明确的呈现和表达。

6.修改性。包括了可重构性，代码级别的侵入性以及单元测试能力。

7.诊断性。系统提供的实时观测能力。

B.外部指标

1.性能。

2.可靠度。

3.可用度。

3. 组织角度

组织角度涉及两个方面：人和流程。

人的方面，架构需要组织的角色参与（业务专家，技术专家）及其参与度，以及涉及到人力资源匹配情况。若架构所需的技术如果太新或者太窄，将面临人力资源的困境。

流程上，要看架构是否与流程匹配。架构原则指导下不同角色在不同阶段关注点不同，而工程实践中，不同流程阶段需要提交的产出物也不同，此时就可能存在二者不匹配的情况。

四、架构的原则和方法论

1. 原则

总原则是：关注点隔离。

在解决各类问题都应以此原则为指导。但针对于不同层面该原则的变化不同。针对于高层设计（概要设计）：合理划分逻辑边界；针对于详细设计层面是：任何改动最多涉及一个接口和一个实现类（简单类职责的变体）。

 

2. 方法论

方法论有两个：自上而下，由内而外。

其对应的完整理论体系为：面向对象/面向方面，领域驱动设计以及测试驱动设计。

 

3. 发展与演化

A.总结归纳型

这个方式最常见。程序员所需要面对的问题是：在有限的时间、资源，面对有限的需求，在容错范围内的做出一定的产品。在这种有限条件下反复训练出来的决策机制，使得程序员对归纳法有着特殊的偏好。它对于程序员开发的大部分工作都是行之有效的。

B. 技术思辨型

通过更广泛的分析，获取深刻的理解和普遍的关联，以创造新颖的技术。所谓大牛们正是如此。例如GC算法，例如AOP技术。