技术开发 频道

浅谈企业应用架构

【IT168 技术文章】

    一、什么是架构

    在牛津高阶词典(第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%)。而开发实现需不断重构代码,采用约定和框架能力等技术手段解决开发的实际问题,解决程序级别的健壮性,可读性,可维护性以及可测试性。

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

0
相关文章