作者: Anders小明  


一、            
架构是什么

通常关于架构的第一个问题是架构是什么,很自然也很正常,本文也不能免俗。然而关于这个问题却没有一致性答案,同时也要注意到不同应用的架构实质上存在不同差异性。

(一) 架构的定义

架构,虽然人们一直在讨论它,甚至于每天都在同其工作,然而这个词并没有一个被业界广泛认可的定义。

大致而言,架构的定义分为三类:

类别

定义

结构论

牛津高阶词典: The design an structure of a computer system

韦氏大辞典: The way in which the parts of a computer are organized

IEEE: The fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment,and the principle guiding its design and evolution

关键论

架构是系统中最关键的20%,关注在系统非功能性需求

文化论

架构是关于系统一些的决策

 

(二) 架构的分类

架构由于应用的不同而存在不同。大体而言,我们可以将当前的应用分为如下四种:互联网应用、企业应用、桌面/移动应用和游戏。

需要一提的是,虽然几种应用的存在一定的模糊性,某种技术为多种应用所共用,例如很多的企业应用基于互联网技术SaaS,以及移动设备的支持。但依然存在很大的不同。

 

特别的,对于企业架构,大体存在如下几种流派:

1.       TOGAF, OpenGroup组织提出,围绕业务、应用、技术和数据四个方面描述架构;

2.       DoDAF/MoDAF,美国和英国国防部提出的架构方案;

3.       Zachman Framework, 根据不同角色的5W1H来审视架构;

4.       4+1视图,由Philippe Kruchten提出,并被RUP采纳;

 

(三) 架构的关键非功能指标

通常来讲,架构所关注的非功能需求可以分为三个角度5个特性,如下:

角度

特性

说明

运营角度

伸缩性

主要为水平扩展能力

可靠性

包括容错性、可用性和安全性等;

开发角度

维护性

 

扩展性

能否快速应对业务的变化

应用角度

易用性

对最终用户是否友好

非功能性指标当然不止这些,如下是一些参考:

1.         ISO 9126提出的质量特性:

        

2.         或者通过如下三个视图来进行:

                               i.        业务视角

Time To MarketCost and BenefitsProjected life timeTargeted MarketIntegration with Legacy SystemRoll back Schedule

                             ii.        最终用户视角

PerformanceAvailabilityUsabilitySecurity

                            iii.        开发视角

MaintainabilityPortabilityReusabilityTestability

3.         也可以通过诸如:简洁性、清晰和一致性等指标。

 

不同类型的应用关注点会有很大不同,例如:互联网应用由于面临大量的最终用户,会特别关注于伸缩性、可靠性和易用性,这并不是说互联网应用不关注维护性和扩展性,只是会更加强调另外三个特性;而企业应用由于关注于数据、流程以及业务的适应性,会更多得强调维护性和扩展性,而其他特性如易用性相对弱化(面对内部用户,强制使用),伸缩性(内部用户访问量少,大部分情况下通过现有硬件即可支持)。同时,企业应用对数据一致性和准确性要求非常高,而互联网应用相对可以容忍一定的不一致性和错误。因此,一个企业应用的架构师可能无法设计互联网应用的架构。

 

二、             架构有什么

架构有什么,通常会来一张或者一堆好看的图画。既然本篇不讨论具体应用,故而也拿不出啥图了,也不想讨论这些。因为不同的应用存在的差异,非本文所能涵盖。这里就想讨论下形形色色架构图的背后的内容,以及隶属架构但未在架构图表达的内容。

 

《易经·系辞》有云:“形而上者谓之道,形而下者谓之器”,将架构分为“形而上”和“形而下”两个部分,如下图:

      

(一) 形而上

形而上体系中,除去前置内容,分为文化和支撑两大块。

其中,文化部分里最重要的就是原则方法论,例如:关注点分离原则(SoC),面向对象分析设计和领域驱动设计等等。在此之下,就是架构模式算法,常见架构模式为:结构化(分层、管道流、黑板)、分布式(代理和管道流)、交互系统(MVCPAC)和适配系统(微内核、元数据)。当然还有更低一层次的设计模式(创建、结构和行为)。

(二) 形而下

形而下分为三个部分,运行时、工具和文档。

其中,运行时的内容按照重要性依次为:语言、平台/中间件、框架、类库和工具,具体在企业应用中就是:Java/C#Windows/LinuxApplication Server/DatabaseSpring/Hibernate等等。

如果说运行时决定最终能力,则工具就事关效率。工具中最常见的是集成开发环境了,此外还有配置、部署和测试工具。

文档部分是另一个重要的内容,应包括:视图(从不同角色出发,可以参考4+1),范例和各种指导参考文档。

 

三、             架构如何设计

如果把“形而下”当成架构设计的产出,那么架构设计往前追溯,就有输入和加工过程。

(一) 架构的输入

架构的输入包括三个部分:目标、需求和相应约束。其中:目标是大方向内容,需求关注在细节,而约束对目标的达成提供了限定。特别的,关注在非功能性指标上。

(二) 架构的设计过程

架构的设计从需求分析开始,结合参考模型或者已有架构体系,结合原则、方法论等等作料。其主要活动有:技术选型、脚手架/框架/平台搭建等等。

       关于具体过程的描述,可见《如何定义和建立架构》。

 

四、             架构如何评估

架构设计出后一个重要的工作是对架构(形而下部分)进行评估,进行架构评估的必要性在:使得架构设计工作形成闭环,确保当前架构是合适和正确的。

大体上,架构评估有三种方法:

·           ATAM: Architecture Tradeoff Analysis Method

·           SAAM: Software Architecture Analysis Method

·           ARID: Active Reviews for Intermediate Designs

在进行架构评估工作时,首先要确定架构评估的参与人,包括相应的干系人和独立的评估队伍;然后是确定评估的时机:早期(在架构设计期间就参与评估)和晚期(传动的,在架构设计完成后)。

评估内容包括如下:

1.         首先是要满足其输入:目标、需求和约束;

2.         各项的非功能性指标;

 

五、             小结

以如下思维导图作为本文的小结: