一软件架构的概述

1.1 软件架构的定义

从需求分析到软件设计之间的过渡过程。

只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。

架构设计就是需求分配，将满足需求的职责分配到组件上。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用 (连接件)、指导构件集成的模式以及这些模式的约束组成。

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

软件架构设计包括提出架构模型，产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。

1.2 软件架构作用

软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。
软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件,决定了开发和维护组织的组织结构，制约着系统的质量属性。
软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

1.3 五大模型

结构模型：以架构的构件、连接件和其他概念来刻画结构;并试图以结构模型来反应整个系统的配置、内在逻辑等。
框架模型：不太侧重描述结构的细节而更侧重于整体的结构;主要是针对具体的问题为目标，来设计适应这个问题的模型。
动态模型：系统的大颗粒的行为性质;对结构模型和框架模型的补充，描述系统的演化。
过程模型：构建系统的步骤和过程。
功能模型：由一组功能构件按层次组成，下层向上层提供服务。

1.4 4+1视图

逻辑视图。主要支持系统的功能需求，即系统提供给最终用户的服务。用类图来描述。
开发视图。也称为模块视图，在UML中被称为实现视图，它主要侧重于软件模块的组织和管理。通过系统/IO关系的模型图和子系统图来描述。
进程视图。侧重于系统的运行特性，主要关注一些非功能性需求，例如系统的性能和可用性等。强调并发性、分布性、系统集成性和容错能力。定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
物理视图。在UML中被称为部署视图，它主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。
场景。可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。对于于UML中的用例视图。

二软件架构风格

2.1 基本架构风格8问？

设计词汇表是什么？
构件和连接件的类型是什么？
可容许的结构模式是什么？
基本的计算模型是什么？
风格的计算不变性是什么？
其使用的常见例子是什么？
使用此风格的优缺点是什么？
其常见的特例是什么？

2.2 数据流风格

面向数据流，按照一定的顺序从前向后执行程序，代表的风格有批处理序列、管道.过滤器

2.2.1 批处理序列

a 典型应用场景

经典数据开发
程序开发
Windows下的BAT程序就是这种应用的典型实例

2.2.2 管道.过滤器

在管道/过滤器风格的软件架构中，每个构件都有一组输入和输出。构件读取输入的数据流，经过内部处理，然后产生输出数据流。
a 典型应用场景

传统的编译器（先词法分析、语法分析、语义分析）
以UNIX shell编写的程序 b 特点

使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;
允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成
支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来:
系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来:旧的可以被改进的过滤器替换掉;
允许对一些如吞吐量、死锁等属性的分析;
支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行。 c 弊端
通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换;
不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重;
因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

2.3 调用/返回风格

构件之间存在互相调用的关系，一般是显式的调用，代表的风格有

主程序/子程序

面向对象

层次结构

b 应用场景：

OSI 7层分层通信协议

2.4 独立构件风格

构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行。

进程通信架构风格

构件是独立的进程，连接件是消息传递。消息传递的方式可以是点到点，异步和同步方式及远过程调用。

事件驱动系统风格

也称隐式调用风格

2.5 虚拟机风格

自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台配，代表的风格有

解释器

解释器风格的软件中会包含一个虚拟机，可以仿真硬件的执行过程和一些关键作用。
被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。

规则系统

规则集、规则解释器
规则 / 数据选择器及工作内存
动物识别专家系统。（执行效率较低）
人工智能
某公司拟开发一个地面清洁机器人。机器人的控制者首先定义清洁任务和任务之间的关系，机器人接受任务后，需要响应外界环境中触发的一些突发事件，根据自身状态进行动态调整,最终自动完成任务。针对上述需求，该机器人应该采用(规则系统）架构风格最为合适。

2.6 仓库（数据共享）风格

数据库系统

构件主要有两大类

中央共享数据源（中央数据结构），保存当前系统的数据状态。
多个独立处理元素（独立构件），处理元素对数据元素进行操作。

超文本系统

a 应用场景

早期的静态网页

黑板风格

应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。就好像多位不同的专家在同一黑板上交流思想，每个专家都可以获得别的专家写在黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其它专家。

黑板模式的优点：可用于非确定性问题求解，启发式解决过程，可维护性，可重用
不足：不能确保期望结果，效率低下，回退，不支持并行，共享空间的访问需要同步 a 应用场景
语音和模式识别
松耦合代理数据共享存取

2.6 层次结构风格

两层C/S架构

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

三层C/S架构

将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上,功能层在应用服务器上,数据层在数据库服务器上。即将两层C/S架构中的数据从服务器中独立出来了。其优点下面四点:

各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性;
允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性;.各层可以并行开发，各层也可以选择各自最适合的开发语言:
功能层有效的隔离表示层与数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制。
三层C/S架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频度和数据量，否则即使分配给各层的硬件能力很强，性能也不高。

三架构描述语言ADL

3.1 定义

ADL是一种形式化语言，在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持。

3.2 ADL的基本构成要素

构件和构件接口：计算单元或数据存储单元，是计算与状态存储的场所。
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。
架构配置：描述架构的构件与连接件的连接图。

3.3 主要的架构描述语言

Aesop:支持体系结构风格的应用。
MetaH:为设计者提供了关于实时电子控制软件系统的设计指导。
C2:支持基于消息传递风格的用户界面系统的描述。
Rapide:支持体系结构设计的模拟并提供了分析模拟结果的工具。
SADL:提供了关于体系结构加细的形式化基础。
Unicon:支持异构的构件和连接类型并提供了关于体系结构的高层编译器。
Wright:支持体系结构构件之间交互的说明和分析。

四 DSSA特定领域软件架构

4.1 定义

domain-specific software architecture

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

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

垂直域:在一个特定领域中的通用的软件架构，是一个完整的架构。
水平域:在多个不同的特定领域之间的相同的部分的小工具(如购物和教育都有收费系统，收费系统即是水平域)。

4.2 DSSA的三个基本活动

领域分析：这个阶段的主要目标是获得领域模型(领域需求)。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。

领域设计:这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。

领域实现:这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤,对以前的步骤得到的结果进行修改和完善,再回到当前步骤，在新的基础上进行本阶段的活动。

4.3 参与DSSA的四种角色人员

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

4.4 建立DSSA的过程

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

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

4.5 三层次模型

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

五基于架构的软件开发方法

5.1 描述

ABSD = 基于架构的软件设计 = Architecture-Based Software Design

5.1 ABSD基于架构的软件开发方法

ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。

ABSD方法有三个基础。
第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术;
第二个基础是通过选择架构风格来实现质量和业务需求;
第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。

ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。

在ABSD中，架构设计、文档化、复审，是一个迭代过程。一般由用户代表和领域专家进行复审。

5.2 开发过程

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

架构需求：重在掌握标识构件的三步。

架构设计:将需求阶段的标识构件映射成构件，进行分析。

架构(体系结构)文档化:主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。

架构复审:由外部人员(独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。
架构实现:用实体来显示出架构。实现构件，构件组装成系统。
架构演化:对架构进行改变，按需求增删构件，使架构可复用。

六软件架构评估

6.1 质量属性

性能:指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略:优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。”
可靠性:是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF。设计策略:心跳、Ping/Echo、冗余、选举。
可用性:是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略:心跳、Ping/Echo、冗余、选举。
安全性:是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。设计策略:入侵检测、用户认证、用户授权、追踪审计。
可修改性:指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。设计策略:接口-实现分类、抽象、信息隐藏。
功能性：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
可变性:指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
互操作性:作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。
易用性，软件开发工具应有十分友好的用户界面，用户乐于使用；工具应能裁剪和定制，以适应特定用户的需求；工具应能提示用户的交互操作，提供简单有效的执行方式；工具还应能检查用户的操作错误，尽可能自动改正错误。

6.2 架构评估方式

敏感点: 是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点: 是影响多个质量属性的特性，是多个质量属性的敏感点。风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念,即可能引起风险的因素,可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点;而如果某件事是可行的可接受的，则为非风险点。

三种常用的评估方式

基于调查问卷(检查表)的方式:类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
基于度量的方式:制定一些定量来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。
基于场景的方式:主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景(即4+1视图中的场景),最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。

从三个方面对场景进行设计:
刺激(事件);
环境(事件发生的环境);
响应(架构响应刺激的过程)。
三种评估方式的比较:

由上表可知，场景最不通用，度量要求对构架精确了解，调查问卷实施阶段最早，度量最客观。其中，基于场景的方式是主流，其有三种具体评估方法:

6.3 基于场景的评估方式

确定应用领域的功能和软件架构的结构之间的映射。
设计用于体现待评估质量属性的场景(即4+1视图中的场景)。
分析软件架构对场景的支持程度。

6.4 SAAM基于场景的架构分析方法

SAAM是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。
SAAM的主要输入是问题描述、需求说明和架构描述。有下列六个步骤:

场景分为直接场景(直接可以实现的)和间接场景(该做哪些修改才能实现)。形成了场景之后，也可以对场景进行分类和单个评估，六个步骤有交叉点。

若要比较多个架构，就要形成权值，对多个架构的功能和数量进行比较。

6.5 ATAM架构权衡分析法

Architecture Tradeoff Analysis Method 是在SAAM的基础上发展起来的，让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。

ATAM被分为四个主要的活动领域，分别是

场景和 需求收集
体系结构视图 和 场景实现
属性模型构造
分析和折中 整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

6.6 CBAM成本效益分析法

用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看做对ATAM的补充，在ATAM确定质量合理的基础上，再对效益进行分析。有下列步骤:

整理场景(确定场景，并确定优先级，选择三分之-优先级最高的场景进行分析);
对场最进行细化(对每个场景详细分析，确定最好、最坏的情况);
确定场景的优先级(项目干系人对场景投票，根据投票结果确定优先级);
分配效用(对场景响应级别确定效用表，建立策略、场景、响应级别的表格);
形成“策略-场景-响应级别的对应关系”;
确定期望的质量属性响应级别的效用(根据效用表确定所对应的具体场景的效用表);
计算各架构策略的总收益; 根据受成本限制影响的投资报酬率选择架构策略(估算成本，用上-步的收益减去成本，得出收益，并选择收益最高的架构策略)。

七软件产品线

7.1 概念

软件产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足特定领域的特定需求。软件产品线是-个十分适合专业的开发组织的软件开发方法，能有效的提高软件生产率和质量，缩短开发时间，降低总开发成本。

核心资源:包括所有产品所共用的软件架构，通用的构件、文档等。

产品集合:产品线中的各种产品。

软件复用是将己有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的- -种重要技术。早起的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。

7.2 过程模型

7.2.1 双生命周期模型

领域工程：领域分析-一领域设计一一领域实现 (类似于DSSA)。
应用工程：需求分析(划分出领域公共的需求和独特的需求)--系统设计--系统实现(用领域可复用构件实现公共需求，用定制开发服务实现独特需求)。

应用工程会将系统独特的需求反馈给领域工程，由领域工程来确定该需求是否是大部分产品共有的需求，建立成可复用的构件，归于核心资源中，领域工程和应用工程间是一个循环的过程，不分先后。

7.2.2 三生命周期模型

除了已有的领域工程、应用工程外，还添加了企业工程(针对企业资源的生命线)和资源管理(双向交互，便于管理核心资源)，另外，还对领域工程和应用工程的实现步骤都增加了第一步(与市场相关)。

7.3 建立方式

企业要建立软件产品线，要建立两个小组，第一-组是核心资源小组，第二组是产品应用小组。建立产品线有两个依据，即是基于现有产品还是全新产品( 企业进入到一个全新的领域)，采用演化方式还是革命方式(循序渐进还是直接全部完成)，可以分为四种建立方式:

将现有产品演化为产品线:慢慢演化，总周期和总投资大。
用软件产品线替代现有产品集:基于现有产品，革命方式，即基于现有需求直接开发出软件产品线，投资少，但是当需求发生变化时，会造成无用功。

全新软件产品线的演化:企业进入到一个全新的领域，已有产品线资源会影响新需求，使投资增大。

全新软件产品线的开发:首先开发人员要得到所有且准确的需求，才能全部开发完，一旦完成产品线的开发，新产品的开发就相当快,降低投资,缺点就是当新产品需求改变大时,核心资源库不够，就十分麻烦。

综上:革命方式比演化方式更节省投资，更省时间，但只适用于需求明确且变动不大，不然风险很大。

7.3.1 成功因素

下列四个方面决定企业建立产品线是否成功:
对该领域具备长期和深厚的经验; -一个用于构件产品的好的核心资源库;好的产品线架构;好的管理(软件资源、人员组织、过程)支持。

八中间件技术

中间件是一种独立的系统软件或服务程序,可以帮助分布式应用软件在不同的技术之间共享资源。

8.1 中间件特点

负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。
提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发。
屏蔽硬件、操作系统、网络和数据库的差异。
提供应用的负载均衡和高可用性、安全机制与管理功能,以及交易管理机制,保证交易的一-致性。
提供--组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。

8.2 中间件技术

8.2.1 主要的中间件有五类:

远程过程调用: RPC，分布式应用程序处理方法，客户进程向服务器进程提出调用请求，客户端和服务器都有存根，客户端和服务器直接通信，是同步的。
对象请求代理: ORB，两个对象之间的通信是通过代理总线来进行的，对象A先将消息发送到ORB，对象B再从ORB中取到数据，所以是个代理模式，是异步的，这种模式下客户和服务器之间互不相关，都是通过ORB来通信。
远程方法调用: RMI，也有服务器和客户端，服务器创建一系列远程对象的方法，由客户端来远.程调用这些方法。
面向消息的中间件: MON，利用消息通信来完成与应用无关的操作，用于扩展通信手段，消息传递与排队算法。
事务处理监控器:TPM,也称为交易中间件，应用广泛，能支持数以万计的客户端对服务器的访问，高效率，高可靠性，支持负载均衡等;介于客户端与服务器之间，处理失败返回、负载均衡等中间操作的中间件。

8.2.2 CORBA (公共对象请求代理体系结构)

OMG组织制订了0MA(Object Management Architecture,对象管理体系结构)参考模型，该模型描述了OMG规范所遵循的概念化的基础结构。OMA由对象请求代理ORB、对象服务、公共设施、域接口和应用接口这几个部分组成，其核心部分是对象请求代理ORB (Object Request Broker)。

对象管理组织(OMG)基于CORBA基础设施定义了四种构件标准。

实体(Entity) 构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。
加工(Process) 构件同样需要容器管理其持久化，但没有客户端可访问的键。
会话(Session)构件不需要容器管理其持久化，其状态信息必须由构件自已管理。
服务(Service) 构件是无状态的。

CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的，是因为并没有硬性规定CORBA对象的实现机制一一个CORBA对象的引用又称可互操作的对象引用(Interoperable Object Reference)。从客户程序的角度看，IOR 中包含了对象的标识、接口类型及其他.信息以查找对象实现。

对象标识(ObjectID)是-一个用于在POA中标识一个CORBA对象的字符串。它既可由程序员指派，也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适配器中必须具有唯一性。

POA (便携式对象适配器)是对象实现与ORB其它组件之间的中介，支持由Object ld标识的对象的名称空间，它将客户请求传送到伺服对象，按需创建子POA，提供管理伺服对象的策略。

伺服对象(servant) 是指具体程序设计语言的对象或实体，通常存在于- -个服务程序进程之中。客户程序通过对象引用发出的请求经过ORB担当中介角色，转换为对特定的伺服对象的调用。在一个CORBA对象的生命期中，它可能与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺服对象。

8.3 典型的应用架构-J2EE

8.3.1 分布式多层应用程序

客户层(客户应用或WEB浏览器动态网页)对应客户机;
WEB层(可省略，是WEB浏览器)和业务层(业务处理逻辑，包括会话Bean，实体Bean和消息驱动Bean)对应J2EE服务器;
企业信息系统层对应数据存储服务器。

8.3.2 JAVA企业应用框架

Structs框架:是一个基于J2EE平台的MVC (模型、视图、控制器)框架，采用Servelet 和JSP技术实现。M由实现业务逻辑的javaBean构成，C由ActionServlet和Action来实现，V由一组JSP文件构成。
Spring框架:通过RMI或Web Servic远程访问业务逻辑，允许自由选择和组装各部分功能，还提供和其他软件集成的接口。Spring 本身是个容器，管理构件的生命周期、构件的组态、依赖注入等,并可以控制构件在创建时是以原型或单例模式来创建。
Hibernate框架:是- - 个对象关系映射框架，提供了java 对象到数据库表之间的直接映射，它对JDBC进行了非常轻量级的对象封装，使得java 程序员可以使用对象编程思维来操作数据库。在Hibernate中，ORM机制的核心是一个XML文件，该文件描述了数据库模式是怎么与一组java类绑定在一起的。

表示层由Structs实现，管理用户请求;业务层由Spring实现，处理业务逻辑中的业务处理情况，提供一个控制器的代码;数据库层由Hibernate实现，通过面向对象的查询语言HQL来实现数据的增删改查。这样组合可以搭建一个轻量级的J2EE架构。

8.3.3 重量级与轻量级之争

重量级框架占用资源过多，在开发的过程中效率很低;大部分时间花在配置、运行的过程上，修改复杂;单元测试也比较麻烦。但在大量运行过程中会表现出优异的效果，也即开发麻烦，运行性能高。

轻量级框架提高了开发的速度;立即可以看到结果;做单元测试非常简单;大量线程可供参考的开源代码。开发简单，但运行性能低。

8.4 典型的应用架构-.NET

.NET框架处于操作系统和.NET应用语言之间，只适用于微软系统，而J2EE支持跨平台，任何安装了JVM的平台。

8.4.1 .NET和J2EE之争

JVM (将所有JAVA代码都编译为字节码，由JVM解释执行)和CLR (.NET核心技术，类似于JVM，生成中间代码CLR，编译执行)。

对多层分布式应用的支持，二者都支持多层分布式应用程序的开发:在表示层的平台支持上，J2EE客户端支持多个平台，.NET 只能在微软系统上运行，也正是因此，.NET 会对微软系统上的应用进行优化;在业务层，J2EE 占优势，因为有许多开源的项目和代码供参考，开发就变得简单;在数据层，二者都支持多种数据库，都非常优秀。

安全性，由于JAVA在.NET之后出来，借鉴了.NET优点，JAVA在运行时动态验证，.NET 是静态全面验证，二者都非常优秀，不分上下。
应用程序的部署，J2EE的部署相对来说较复杂，针对不同的系统要特别布置。
可移植性，显然J2EE占优势，一次开发，到处运行。
外部支持: J2EE 占优势，得到了很多厂家的支持，.NET 只是微软一家。

九 Web架构设计

9.1 Web技术与演变

9.1.1 Web应用技术分类

从架构来看: MVC, MVP, MVVM, REST, Webservice，微服务。
从缓存来看: MemCache, Redis, Squid.
从并发分流来看:集群(负载均衡)、CDN。
从数据库来看:主从库(主从复制)，内存数据库，反规范化技术，NoSQL,分区(分表)技术，视图与物化视图。
从持久化来看: Hibernate, Mybatis。
从分布存储来看: Hadoop, FastDFS，区块链。
从数据编码看: XML，JSON。
从Web应用服务器来看: Apache, WebSphere, Weblogic, Tomcat, JBOSS, IIS。
其它:静态化，有状态与无状态，响应式Web设计。

9.1.2 单台机器到数据库与Web服务器分离

9.1.3 应用服务器集群

系统演变到这里，将会出现问题:
用户的请求由谁来转发到具体的应用服务器;
用户如果每次访问到的服务器不-一样，那么如何维护session的一致性。

9.2 负载均衡技术

9.2.1 应用层负载均衡技术

http重定向。HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务嚣，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群。

特点:实现简单，但性能较差。

反向代理服务器。在用户的请求到这反向代理服务器时（已经到达网站机房)，由反向代理服务器根据算法转发到具体的服务器。常用的apache, nginx都可以充当反向代理服务器。

特点:部署简单，但代理服务器可能成为性能的瓶颈。

9.2.2 传输层负载均衡技术

DNS域名解析负载均衡。DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。

特点:效率比HTTP重定向高，减少维护负载均衡服务器成本。但一个应用服务器故障，不能及时通知 DNS，而且 DNS负载均衡的控制权在域名服务商那里，网站无法做更多的改善和更强大的管理。

基于NAT的负载均衡。基于NAT的负载均衡将一个外部IP地址映射为多个IP地址，对每次连接请求动态地转换为一个内部节点的地址。

特点:技术较为成熟，一般在网关位置，可以通过硬件实现。像四层交换机一般就采用了这种技术。

9.2.3 数据库读写分离化

9.2.4 用缓存缓解库读取压力

MemCached是一个自由开源的,高性能,分布式内存对象缓存系统。简洁的 key-value存储系统。通过缓存数据库查询结果，减少数据库访问次数，以提高动态web应用的速度、提高可扩展性。

9.2.5 有状态和无状态

无状态服务(stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到(比如说数据库)，服务器本身不存储任何信息。
有状态服务(stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的。

9.3 CDN

CDN的全称是Content Delivery Network，即内容分发网络。

CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

CDN的基本原理是广泛采用各种缓存服务器,将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时,利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

九 软件架构设计1｜8月更文挑战

一 软件架构的概述