浅谈企业应用架构.docVIP

浅谈企业应用架构 在牛津高阶词典（第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. 架构的问题来源 A.???? 外部，客户要求包括了业务和技术上。 B???? 内部，组织管理、项目管理和技术发展上。 特别的，架构需要解决的非业务问题包括如下： a系统目标：系统性能，稳定性等。 b.项目目标：开发成本，项目质量等 c.项目过程：需求的不确定性和开发过程的团队协作性，即所谓的开发管理。 2. 架构的核心问题 问题可分解为两种类型，业务上和技术上。 A 业务上。问题域分解为，逻辑的纵向抽象层次，以及逻辑的横向模块分解和集成。 B 技术上。问题域分解为，纵向的技术主题，以及横向的技术职责的分解和集成。 a领域化 传统的架构模式是三层或者四层模式，虽然从技术上有效的横向分解系统结构，但对业务模型如何建立，如何进行层次间传递，模型间关联关系，以及与服务逻辑耦合等问题没有给出进一步的细化，也带来了很多问题。 此外，在传统设计方法下，分析模型和设计模型的转换也是一个大的问题。 b组件化 实施组件化或者说模块化，其需求分为两个层面。 b1.内部管理，可以帮助开发过程中进行业务切分，帮助控制进度，降低风险，以及财务分析；对于大型复杂的项目，也有利于知识的传递和积累。 b2.销售需要，All in one的系统因不符合发展趋势而不利于销售；组件化有助于产品销售，可以针对客户，将若干组件打包销售，同时减少集成的风险。 c.产品化 c1 定制化问题 定制化问题的由来：1.面向行业的应用通常没有标准，或者完备的标准；2.通常产品的开发是针对于通用或者公共需求，不针对于特定客户；3.而一个确定的客户，其自身的业务差异和管理差异导致需求的差异性。 这种现象尤其在缺乏标准的行业应用中，以及系统的产品化过程中。 传统的简单的解决方式是为每个客户单独维护一个系统分支，在此情况下提供维护和升级，则维护成本巨大；因此如何解决领域的定制化就成为一个重大问题。??? c2 升级问题 领域需求每次进一步的挖掘和实现，都意味着领域的升级。但升级面临的诸多问题:数据迁移,旧版本的兼容问题，依赖关联等等，在组件化和定制化情况下，还面临定制化兼容和冲突检测。 c3 国际化问题 1.文本消息国际化 国际化消息没有直接呈现，而是中间存储后呈现； 2.布局国际化 阿拉伯人是从右到左； 3.业务时间，跨时区； 4.计量单位，多币种； d.平台化 应用系统可以分为两个内容：应用程序和基础设施。应用程序处理业务问题，而基础设施处理技术问题。 来自客户的要求是包含业务和技术两个方面。其中技术上包括两种“定型和定性”，其所需的知识和技能是不同于业务上的； 此外，内部管理也提出相应的要求。由于技术的发展和业务发展之间的不同步，对于一个产品而言，同时存在技术升级和业务升级两个需求。而同时升级存在较大的成本和风险。 同时对于一个产品来说，技术方面需要较强的适应性，能够低成本上的适应客户的特别要求。 因此有效解藕技术和业务两个部分成为必然。 3.架构的应用问题 A.事务管理 数据一致性问题出现的原因通常是开发过程中，由于错误的并发和事务控制导致的；而在业务过程中也存在错误的业务操作情况。 B.并发处理 不同的业务应用存在不同的并发场景（并发度以及存在的业务依赖），因此业务上需要明确原则和方案；而不同平台所支持的并发方式和能力也不相同，则采用一定框架支持有助于简化问题。 C.集成能力 业务应用所面临的集成问题不同，包括不同的集成环境：外部系统，内部系统