《浅谈企业应用架构》由会员分享，可在线阅读，更多相关《浅谈企业应用架构（32页珍藏版）》请在金锄头文库上搜索。
1、浅谈企业应用架构一、什么是架构在牛津高阶词典（第 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 Architectu
2、re）：关注于应用系统设计；基础架构（Infrastructure Architecture）：关注于基础技术；数据架构（Data Architecture）：关注于数据存储及其规划；这里所说的企业应用架构，即属于应用架构，包括如下几个部分：1.目标和愿景。即应用系统所面临的问题域。2.评价指标。从哪些纬度和指标来评价和度量解决方案。3.原则和方法论。为解决这些问题，所采用的原则及其方法论。4.技术架构。架构的技术层面，给出相应的设计以及结构，描述应用系统。5.组织因素。架构的组织层面，组织的各个部分如何参与。二、架构的目标和愿景1. 架构的问题来源A. 外部，客户要求包括了业务和技术上。B
3、内部，组织管理、项目管理和技术发展上。特别的，架构需要解决的非业务问题包括如下：a系统目标：系统性能，稳定性等。b.项目目标：开发成本，项目质量等c.项目过程：需求的不确定性和开发过程的团队协作性，即所谓的开发管理。2. 架构的核心问题问题可分解为两种类型，业务上和技术上。A 业务上。问题域分解为，逻辑的纵向抽象层次，以及逻辑的横向模块分解和集成。B 技术上。问题域分解为，纵向的技术主题，以及横向的技术职责的分解和集成。a领域化传统的架构模式是三层或者四层模式，虽然从技术上有效的横向分解系统结构，但对业务模型如何建立，如何进行层次间传递，模型间关联关系，以及与服务逻辑耦合等问题没有给出进一步的
4、细化，也带来了很多问题。此外，在传统设计方法下，分析模型和设计模型的转换也是一个大的问题。b组件化实施组件化或者说模块化，其需求分为两个层面。b1.内部管理，可以帮助开发过程中进行业务切分，帮助控制进度，降低风险，以及财务分析；对于大型复杂的项目，也有利于知识的传递和积累。b2.销售需要，All in one的系统因不符合发展趋势而不利于销售；组件化有助于产品销售，可以针对客户，将若干组件打包销售，同时减少集成的风险。c.产品化c1 定制化问题定制化问题的由来：1.面向行业的应用通常没有标准，或者完备的标准；2.通常产品的开发是针对于通用或者公共需求，不针对于特定客户；3.而一个确定的客户，其
5、自身的业务差异和管理差异导致需求的差异性。这种现象尤其在缺乏标准的行业应用中，以及系统的产品化过程中。传统的简单的解决方式是为每个客户单独维护一个系统分支，在此情况下提供维护和升级，则维护成本巨大；因此如何解决领域的定制化就成为一个重大问题。 c2 升级问题领域需求每次进一步的挖掘和实现，都意味着领域的升级。但升级面临的诸多问题:数据迁移,旧版本的兼容问题，依赖关联等等，在组件化和定制化情况下，还面临定制化兼容和冲突检测。c3 国际化问题1.文本消息国际化国际化消息没有直接呈现，而是中间存储后呈现；2.布局国际化阿拉伯人是从右到左；3.业务时间，跨时区；4.计量单位，多币种；d.平台化应用系统
6、可以分为两个内容：应用程序和基础设施。应用程序处理业务问题，而基础设施处理技术问题。来自客户的要求是包含业务和技术两个方面。其中技术上包括两种“定型和定性”，其所需的知识和技能是不同于业务上的；此外，内部管理也提出相应的要求。由于技术的发展和业务发展之间的不同步，对于一个产品而言，同时存在技术升级和业务升级两个需求。而同时升级存在较大的成本和风险。同时对于一个产品来说，技术方面需要较强的适应性，能够低成本上的适应客户的特别要求。因此有效解藕技术和业务两个部分成为必然。3.架构的应用问题A.事务管理数据一致性问题出现的原因通常是开发过程中，由于错误的并发和事务控制导致的；而在业务过程中也存在错误
7、的业务操作情况。B.并发处理不同的业务应用存在不同的并发场景（并发度以及存在的业务依赖），因此业务上需要明确原则和方案；而不同平台所支持的并发方式和能力也不相同，则采用一定框架支持有助于简化问题。C.集成能力业务应用所面临的集成问题不同，包括不同的集成环境：外部系统，内部系统，遗留系统等；不同的集成模式：基于文件，基于数据库表，基于消息等，导致所需的集成方法及其能力也不同。4. 架构的设计问题分析设计和开发实现存在着一定的差异性：分析设计属于知识级，而开发实现属于操作级的。分析设计是需求和实现的中间桥梁，因而设计必须解决系统边界的合法性，内部逻辑解藕的合理性和实现的可达性（设计的类方法为实现的
8、 30%-70%）。而开发实现需不断重构代码，采用约定和框架能力等技术手段解决开发的实际问题，解决程序级别的健壮性，可读性，可维护性以及可测试性。传统的方式，分析设计存在于文档中，而开发实现存在于代码中。两者的割裂导致沟通的困难，也导致了开发工程中具大的风险分析设计和最终开发实现的不一致性。三、架构的评价指标1. 财务角度在传统的财务核算机制中，系统或者产品的开发通常属于成本中心，对于 IT企业来说，电脑设备，办公室等属于沉没成本，而 IT人员的工资属于可变成本，是成本的核心部分，为了控制成本，就需要减少项目的开发时间。因此架构一个重要的关注点在于控制开发成本和维护成本，通常讲维护成本是开发成
9、本的 3倍。降低开发成本核心，在于提高效率、提高适应需求变化的能力。2. 技术角度技术角度评估架构很难说一个架构行或者不行。技术角度需要给出的最大指标是风险性。而风险性和各个指标因数有很大相关，但还需要结合相应实际情况判断。例如：如果决定了不可能换数据库，那么即便强绑定 oracle也没有特别的风险。以下指标参考了架构的质量特性，但进行了裁减。A.内部指标1.侵入性。或者说是可迁移性，即系统与外部资源的关联关系，以及系统内部的关联关系。例如，如果架构决定使用 pl/sql，那么就意味着架构和 Oracle数据库是强绑定。2.重复性。虽然我们都知道关于重复的两个原则（1.不要重复，2.不要自己重
10、复），但是有时重复看上去无法避免，那么就是判断这个重复性带来的问题有多大。3.扩展性。即架构提供何种条件下的何种扩展和变化能力，及其成本。4.平稳性。在业务或技术扩展时的，架构所呈现的发展态性。5.抽象性。即可视性，并包括了概念完整性。系统是否完整以及层次化的反映应用问题，能否明确的呈现和表达。6.修改性。包括了可重构性，代码级别的侵入性以及单元测试能力。7.诊断性。系统提供的实时观测能力。B.外部指标1.性能。2.可靠度。3.可用度。3. 组织角度组织角度涉及两个方面：人和流程。人的方面，架构需要组织的角色参与（业务专家，技术专家）及其参与度，以及涉及到人力资源匹配情况。若架构所需的技术如果
11、太新或者太窄，将面临人力资源的困境。流程上，要看架构是否与流程匹配。架构原则指导下不同角色在不同阶段关注点不同，而工程实践中，不同流程阶段需要提交的产出物也不同，此时就可能存在二者不匹配的情况。四、架构的原则和方法论1. 原则总原则是：关注点隔离。在解决各类问题都应以此原则为指导。但针对于不同层面该原则的变化不同。针对于高层设计（概要设计）：合理划分逻辑边界；针对于详细设计层面是：任何改动最多涉及一个接口和一个实现类（简单类职责的变体）。2. 方法论方法论有两个：自上而下，由内而外。其对应的完整理论体系为：面向对象/面向方面，领域驱动设计以及测试驱动设计。3. 发展与演化A.总结归纳型这个方式
12、最常见。程序员所需要面对的问题是：在有限的时间、资源，面对有限的需求，在容错范围内的做出一定的产品。在这种有限条件下反复训练出来的决策机制，使得程序员对归纳法有着特殊的偏好。它对于程序员开发的大部分工作都是行之有效的。B. 技术思辨型通过更广泛的分析，获取深刻的理解和普遍的关联，以创造新颖的技术。所谓大牛们正是如此。例如 GC 算法，例如 AOP 技术。五、架构的技术层面（一）基础手段提高开发效率和品质的基本手段是分解即充分的分离系统中不同的关注点，好处不用说了，可以并发的工作，每个人面对的问题都简单而容易操作。而与分解对应的集成，只有提供了好的集成能力，分解才成为现实，而只有分解了，才能清晰
13、的提供业务更多适应性。分解和集成的手段分为编程语言和技术框架两个层面。所谓语言就是强框架，而框架就是弱语言。A. 开发语言现代面向对象的语言提供如下能力：抽象和派生能力，以及接口隔离能力。实际提供两种分解和集成能力：A1. 把逻辑分解在两个层次中，而通过继承的方式把两个部分集成在一起。A2. 把逻辑的外观和实现分解在两个地方，而通过接口实现的方式把两部分集成在一起。另一种语言 AspectJ或者 C#语言 2.0之后提供的特性：把流程逻辑，分解在不同的地方，而通过签名匹配，利用代码生成的方式来把几部分集成在一起。B. 应用框架然而语言提供的集成能力，毕竟底层，而且有限，扩展起来也格外小心。因而
14、技术框架提供另外的集成能力就格外重要：B1. 对象关联关系的分解和集成，如 Spring提供容器管理能力依赖注入对于依赖关系是适合的，对于服务间，技术层次间都是适合的（因为无状态）；但对于聚合（整体和部分）的关系主要是领域模型（有状态的）则不合适；B2. 模块间关联关系的分解和集成，如 OSGi，ESB 等B3. 流程逻辑的分解和集成，如 Spring Web Flow以及jBPM。B4. 不同系统的类型分解和集成，如 Spring利用动态代理提供的 Exporter模式。B5. 模式的封装集成，设计应当是面向服务的设计，但是服务的暴露方式以及模式可以有很多种，比如 API，Web Servi
15、ce，RMI，以及 Command模式，Event 模式等，框架应该利用动态代理等技术对于这些服务暴露方式，模式进行封装。C. 分析设计设计中涉及到的组合方式，包括类（接口）组合，继承组合以及产生组合三种。三种组合各有优缺点，设计时适应不同场合。这就涉及到现有面向对象的设计粒度：类（第一公民）和方法（二等公民）。类（接口）组合实际上复用的是类一级粒度的设计，而继承组合本质上是一种有方向的组合，复用的方法一级粒度的设计，提供与或非的逻辑操作。而产生组合，例如AspectJ，也是在方法一级粒度的设计复用。因为继承组合复用在方法一级的粒度上，因而其更适合存在嵌入式，最低粒度的差异性的设计中，借助于虚
16、拟机的支持，无需额外工作。而类（接口）在类一级上，更适合在更高一级的逻辑复用上；其实不一定需要接口，普通的类也可以，但是在这一级粒度的差异性替换，采用接口优于类，因此称为类（接口）组合；接口是类（接口）组合的编码需要；对于接口一级，需要通过框架的集成和适配来提供差异性的设计。产生组合其实也是在方法一级，不过更关注于广泛的横切面，同时由于现有的语言对它的支持不同，Java 需要额外的编译器，而.Net 则是在内置编译器上支持。更高一级的组合是组件组合。对于组件边界的设计，遵从两点：严格把关设计和代码优先。接口优先的设计通常导致成本太高，实践中会导致开发人员在项目的进度压力下把代码写在不合适的地方。D. 开发方式常见的开发方式可以归结为 3类：开发式编程（Programmatic programming），声明式编程（Declarative programming）和产生式编程（Generative prog
