系统架构师—软件架构设计（二）CS/BS/SOA/DSSA/ABSD

1.层次架构风格

1.1.两层C/S架构

客户端和服务器都有处理功能，相比较于传统的集中式软件架构,还是有不少优点的,但是现在已经不常用,原因有:开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。

1.2.三层C/S结构

将处理功能独立出来,表示层和数据层都变得简单。即将两层C/S架构中的数据从服务器中独立出来了。

1. 表示层在客户机上
2. 功能层在应用服务器上
3. 数据层在数据库服务器上
   
   其优点下面四点:
4. 各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性;
5. 允许灵活有效的选用相应的乎台和硬件系统，其符食好的可升级性和开放性;
6. 各层可以并行开发，各层也可以选择各自最适答的并发语言;
7. 功能层有效的隔离于表示层与数据层，为严格的安全奠定坚实的基础，整个系统的管理层次也更加合理和可控制

三层C/S架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频率和数据量,，否则即便分配给各层的硬件能力在强，性能也不高。

1.3.三层B/S架构

1. 是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为0客户端架构，虽然不用开发客户端，但有很多缺点，主要是数据处理能力差;
2. B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能;安全性难以控制;
3. 在数据查询等响应速度上，要远远低于C/S架构;
4. 数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

1.4.混合架构风格

1. 内外有别模型:企业内部使用C/S
2. 外部人员访问使用B/S
3. 查改有别模型:采用B/s查询，采用C/S修改
4. 混合架构实现困难，且成本高

1.5.富互联网应用RIA

弥补三层B/S架构存在的问题，RIA是一种用户接口，比用HTML实现的接口更加健壮，且有可视化内容，本质还是网站模式，其优点如下:

1. RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性;
2. RIA简化并改进了B/S架构的用户交互;
3. 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面;
4. 本质还是0客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支持能力，典型的如小程序。

2.面向服务的架构风格(SOA)

2.1.SOA概述

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。

在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理，如下:

实施SOA的关键目标是实现企业IT资产重用的最大化，在实施SOA过程中要牢记以下特征:

1. 可从企业外部访问
2. 随时可用(服务请求能被及时响应)
3. 粗粒度接口（粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法)
4. 服务分级
5. 松散耦合（服务提供者和服务使用者分离)
6. 可重用的服务及服务接口设计管理
7. 标准化的接口(wSDL、SOAP、XML是核心）
8. 支持各种消息模式
9. 精确定义的服务接口

从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。
基于服务的构件与传统构件的区别有四点:

1. 服务构件粗粒度，传统构件细粒度居多;
2. 服务构件的接口是标准的，主要是WSDL接口，而传统构件常以具体API形式出现;
3. 服务构件的实现与语言是无关的,而传统构件常绑定某种特定的语言;
4. 服务构件可以通过构件容器提供QoS(Quality of Service是服务质量)的服务，而传统构件完全由程序代码直接控制。

2.2.关键技术

SOA中应用的关键技术如下表

1. 服务发现
   UDDI
   用于web服务注册和服务查找，描述了服务的概念，定义了编程的接口，供其他企业来调用。
   DISCO
   发现公开服务的功能及交互协议。
2. 描述服务
   WSDL (WEB服务描述语言）协议:用于描述Web服务的接口和操作功能，描述网络服务。
3. 消息格式层
   SOAP为建立Web服务和服务请求之间的通信提供支持。
   REST(Representational State Transfer，表述性状态转移）是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性,提高系统的可伸缩性。
4. 编码格式层
   扩展标记语言（Extensible Markup Language, XML)，用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。

2.3.SOA实现方式

web service
服务提供者、服务注册中心(（中介，提供交易平台，可有可无)、服务请求者。服务提供者将服务描述发布到服务注册中心，供服务请求者查找，查找到后，服务请求者将绑定查找结果。如下图:

服务注册表

1. 服务注册
   应用开发者（服务提供者）在注册表中公布服务的功能。
2. 服务位置
   服务使用者（服务应用开发者)，帮助他们查询注册服务，寻找符合自身要求的服务。
3. 服务绑定
   服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动。

本质与WEB Service类似，只是使用一个注册表来代替服务注册中心。

企业服务总线ESB
客户端（服务请求者)、基础架构服务（中间件)、核心集成服务（提供服务）。
本质也是通过网络，有下列六点功能:

1. 提供位置透明性的消息路由和寻址服务;
2. 提供服务注册和命名的管理功能;
3. 支持多种的消息传递范型;
4. 支持多种可以广泛使用的传输协议;
5. 支持多种数据格式及其相互转换;
6. 提供日志和监控功能。

3.特定领域软件架构DSSA

DSSA就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。

DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础,其目标就是支持在一个特定领域中多个应用的生成。

垂直域:在一个特定领域中的通用的软件架构，是一个完整的架构。

水平域:在多个不同的特定领域之间的相同的部分的小工具（(如购物和教育都有收费系统，收费系统即是水平域)。

3.1.DSSA的三个基本活动

1. 领域分析
   这个阶段的主要目标是获得领域模型（领域需求)。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的从而建立领域模型。
2. 领域设计
   这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。
3. 领域实现
   这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

3.2.DSSA的四种角色人员

1. 领域专家
   包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。提供关于领域中系统的需求规约和实现的知识,帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品,等等。
2. 领域分析人员
   由具有知识工程背景的有经验的系统分析员来担任。控制整个领域分析过程,进行知识获取,将获取的知识组织到领域模型中。
3. 领域设计人员
   由有经验的软件设计人员来担任。根据领域模型和现有系统开发出DSSA,并对DSSA的准确性和一致性进行验证。
4. 领域实现人员
   由有经验的程序设计人员来担任。根据领域模型和DSSA，开发构件。

3.3.建立DSSA的过程

1. 定义领域范围
   领域中的应用要满足用户一系列的需求。
2. 定义领域特定的元素
   建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素。
3. 定义领域特定的设计和实现需求的约束
   识别领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。
4. 定义领域模型和架构
   产生一般的架构，并描述其构件说明。
5. 产生、搜集可复用的产品单元
   为DSSA增加复用构件，使可用于新的系统。

以上过程是并发的、递归的、反复的、螺旋型的。

3.4.领域三层次模型

1. 领域开发环境
   领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。
2. 领域特定的应用开发环境
   应用工程师根据具体环境来将核心架构实例化.
3. 应用执行环境
   操作员实现实例化后的架构。
   

4.基于架构的软件开发ABSD

ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求（或侧重于非功能需求）。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成,就开始了软件设计。
ABSD方法有三个基础。第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术;第二个基础是通过选择架构风格来实现质量和业务需求;第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的,有助于降低架构设计的随意性。

架构设计是在需求分析之后，概要设计之前,是为了解决需求分析和软件设计之间的鸿沟问题。基于架构的软件开发过程可分为下列六步:

架构需求:重在掌握标识构件的三步，如下左图。
架构设计:将需求阶段的标识构件映射成构件，进行分析,如下右图。

架构（体系结构）文档化:主要产出两种文档，即架构（体系结构）规格说明，测试架构（体系结构）需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。
架构复审:由外部人员(独立于开发组织之外的人，如用户代表和领域专家等）参加的复审,复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化,再复审。

架构实现:用实体来显示出架构。实现构件，构件组装成系统,如下左图:
架构演化:对架构进行改变，按需求增删构件，使架构可复用,如下右图: