1.软件架构

1.1.架构风格（6个）

软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

1.1.1. 数据流风格

数据流风格的软件架构是一种最常见，结构最为简单的软件架构。这样的架构下，所有的数据按照流的形式在执行过程中前进，不存在结构的反复和重构。在流动过程中，数据经过序列间的数据处理组件进行处理，然后将处理结果向后传送，最后进行输出。

1.1.1.1批处理序列

批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据传送在步与步之间作为一个整体。

1.1.1.2.管道—过滤器

每个构件都有一组输入和输出，构件读输入的数据流经过内部处理,然后产生输出数据流,这个过程通常是通过对输入数据流的变换或计算来完成的。这里的构件称为过滤器,连接件就是数据传输的管道，将—个过滤器的输出传到另一个过滤器的输入。

1.1.2. 调用/返回风格

调用返回风格顾名思义，就是指在系统中采用了调用与返回机制。利用调用-返回实际上是一种分治策略，其主要思想是将一个复杂的大系统分解为一些子系统，以便降低复杂度，并且增加可修改性。程序从其执行起点开始执行该构件的代码，程序执行结束，将控制返回给程序调用构件。

1.1.2.1主程序/子程序

主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性，取决于它调用的子程序的正确性。

1.1.2.2.面向对象

抽象数据类型概念对软件系统有着重要作用。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在对象中。这种风格的构件是对象。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。

1.1.2.3.层次结构

构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层。

1.1.3. 独立构建风格

独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。独立构件风格主要包括：进程通讯和事件系统子风格。

1.1.3.1.进程通信

构件是独立的过程，连接件是消息传递，构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程调用等。

1.1.3.2.事件驱动系统/隐式调用

构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册,当某个事件被触发时,系统自动调用这个事件注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程,它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持,为构件的维护和演化带来了方便;其缺点是构件放弃对系统计算的控制。

1.1.4. 虚拟机风格

虚拟机风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性，虚拟机风格主要包括解释器和规则为中心两种架构风格。

1.1.4.1.解释器

解释器通常包括一个完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构，具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。其缺点是执行效率比较低。

1.1.4.2.基于规则的系统

基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和决策支持系统中。

1.1.5. 仓库风格

在仓库（repository）风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化。

1.1.5.1.数据库系统

构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。

1.1.5.2.黑板系统

包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元,提供解决向题的知识。知识源响应黑板的变化,也只修改黑板；黑板是一个全局数据库,包含问题域解空间的全部状态,是知识源相互作用的唯一媒介;知识源响应是通过黑板状态的变化来控制。

1.1.5.3.超文本系统

构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件，超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。

1.2.典型层次结构

1.2.1.MVC

Model 是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型。Model 接受Controller 的请求并完成相应的业务处理，在状态改变的时候向View 发出相应的通知。

View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。

View 捕获到用户交互操作后会直接转发给Controller，后者完成相应的UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用Model。在完成UI 处理后，Controller会根据需要控制原View 或者创建新的View 对用户交互操作予以响应。

1.2.2.MVP

MVP 的全称为Model-View-Presenter，Model 提供数据，View 负责显示，Controller/Presenter 负责逻辑的处理。MVP 是从经典的模式MVC 演变而来。MVP 与MVC 也有一些显著的区别，MVC 模式中元素之间“混乱”的交互主要体现在允许 View 和Model 直接进行“交流”，这在 MVP 模式中是不允许的。在MVP 中View 并不直接使用Model，它们之间的通信是通过Presenter来进行的，所有的交互都发生在Presenter 内部，而在MVC 中View 会直接从Model 中读取数据而不是通过Controller。

1.1. 面向服务的架构

1.2.0.什么是SOA

面向服务的架构（Service-Oriented Architecture,SOA）是一种组件模型，把应用程序中的不同功能单元（即服务）通过这些服务之间定义良好的接口和契约联系起来，使得这些系统中的服务能够以-种统一和通用的方式进行交互。从应用角度看，SOA 是一种应用框架，它关注企业日常的业务应用，将其划分为单独的业务功能和流程，并抽象为服务，用户和系统开发人员可以构建、部署和整合这些服务，无需依赖特定的应用程序及应用平台，从而提高企业业务流程的灵活性。SOA有助于实现更多的信息资产重用、更轻松地管理和更快地应用开发与部署。

1.1.1. SOA关键技术

1.2.1.1.UDDI

UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI 规范描述了服务的概念，同时也定义了一种编程接口。通过UDDI 提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。

1.2.1.2.WSDL

WSDL（Web ServiceDescription Language，Web 服务描述语言）用于描述Web 服务的接口和操作功能。WSDL 描述的重点是服务，它包含服务实现定义和服务接口定义。

服务接口定义就是一种抽象的、可重用的定义，行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型，服务实现者可以根据这些标准定义来实现具体的服务。

服务实现定义描述了给定服务提供者如何实现特定的服务接口。服务实现定义中包含服务和端口描述。一个服务往往会包含多个服务访问入口，而每个访问入口都会使用一个端口元素来描述，端口描述的是一个服务访问入口的部署细节，例如，通过哪个地址来访问，应当使用怎样的消息调用模式来访问等。

1.2.1.3.SOAP

SOAP（Simple ObjectAccess Protocol，简单对象访问协议）为建立Web 服务和服务请求之间的通信提供支持。SOAP 用XML 来格式化消息，用HTTP 来承载消息。

1.2.1.4.REST

REST 从资源的角度来定义整个网络系统结构，分布在各处的资源由统一资源标识符（URI）确定，客户端应用程序通过 URI 获取资源的表现，并通过获得资源表现使得其状态发生改变。REST 提出了如下一些设计概念和准则：

（1）网络上的所有事物都被抽象为资源。

（2）每个资源对应一个唯一的资源标识。

（3）通过通用的连接件接口对资源进行操作。

（4）对资源的各种操作不会改变资源标识。

（5）所有的操作都是无状态的

1.2.1.5.BPEL

BPEL（Business Process Execution Language For Web Services）面向Web 服务的业务流程执行语言。BPEL 可将多个Web 服务组合到一个新的复合服务（称作业务流程）中。

1.1.2. SOA实现

SOA 只是一种概念和思想，需要借助于具体的技术和方法来实现它。从本质上来看，SOA 是用本地计算模型来实现一个分布式的计算应用，也有人称这种方法为“本地化设计，分布式工作”模型。CORBA、DCOM 和EJB 等都属于这种解决方式，也就是说，SOA 最终可以基于这些标准来实现。

1.1.2.1. WebService

在Web Service（Web 服务）的解决方案中，一共有三种工作角色，其中服务提供者和服务请求者是必需的，服务注册中心是一个可选的角色。它们之间的交互和操作构成了SOA 的一种实现架构。

（1）服务提供者。服务提供者是服务的所有者，该角色负责定义并实现服务，使用WSDL 对服务进行详细、准确、规范地描述，并将该描述发布到服务注册中心，供服务请求者查找并绑定使用。

（2）服务请求者。服务请求者是服务的使用者，虽然服务面向的是程序，但程序的最终使用者仍然是用户。从架构的角度看，服务请求者是查找、绑定并调用服务，或与服务进行交互的应用程序。服务请求者角色可以由浏览器来担当，由人或程序（例如，另外一个服

务）来控制。

（3）服务注册中心。服务注册中心是连接服务提供者和服务请求者的纽带，服务提供者在此发布他们的服务描述，而服务请求者在服务注册中心查找他们需要的服务。不过，在某些情况下，服务注册中心是整个模型中的可选角色。例如，如果使用静态绑定的服务，服务提供者则可以把描述直接发送给服务请求者。

1.1.2.2. 企业服务总线

ESB 是传统中间件技术与 XML、Web 服务等技术结合的产物，主要支持异构系统集成。在一个复杂的企业计算环境中，如果服务提供者和服务请求者之间采用直接的端到端的交互，那么随着企业信息系统的增加和复杂度的提高，系统之间的关联会逐渐变得非常复杂，这将带来昂贵的系统维护费用。ESB消除了服务请求者与服务提供者之间的直接连接，使得服务请求者与服务提供者之间进一步解耦。

ESB的主要功能：

（1）服务位置透明性；

（2）传输协议转换；

（3）消息格式转换；

（4）消息路由；

（5）消息增强；

（6）安全性；

（7）监控与管理。

1.2.3.微服务

微服务顾名思义，就是很小的服务，所以它属于面向服务架构的一种。通俗一点来说，微服务类似于古代著名的发明，活字印刷术，每个服务都是一个组件，通过编排组合的方式来使用，从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达

到提高交付质量、缩短交付周期的效果。

从专业的角度来看，微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

1.1.3. 对比

微服务可以讲是SOA 的一种，但仔细分析与推敲，我们又能发现他们的一些差异。这种差异表现在多个方面。

实现差异

2.1.软件质量属性

性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。代表参数：响应时间、吞吐量 设计策略：优先级队列、资源调度。

可靠性（reliability）是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持系统的功能特性。基本能力代表参数：MTTF、MTBF 设计策略：冗余、心跳线。

可用性（availability）是系统能够正常运行的时间比例。经常用两次故障直接的时间长度或在出现故障时系统能够恢复正常的速度来表示。 代表参数：故障间隔时间 设计策略：冗余、心跳线。

安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。设计策略：追踪审计、信息隐藏

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

功能性（functionality）是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

可变性（changeability）是指系统结构经扩充或变更而成为新体系结构的能力。这种新体系结构 应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列产品（例如，软件产品线）的基础时，可变性是很重要的。

互操作性（interoperation）作为系统组成部分的软件不是独立存在的，经常与其他系统的自身环境相互作用。为了支持互操作性（interoperation），软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。

2.2. 3个点

风险点

系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

敏感点

敏感点是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

权衡点

权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。