talend 硬件架构硬件体系架构

转载

温柔一刀 2024-06-04 14:21:41

文章标签 talend 硬件架构系统架构数据 SOA 体系结构 文章分类 架构后端开发

架构设计生命周期

需求分析，根据需求模型构建软件架构模型，模型转换的可追踪性

设计阶段，组成元素，体系结构描述语言ADL，4+1视图

实现阶段，项目组织结构，配置管理，中间件，程序设计语言，逐步细化

构件组装阶段

部署阶段

后开发阶段，

4+1视图

5个不同的视角，包括逻辑视图，进程视图，物理视图，开发视图，场景视图来描述软件架构。

开发视图和场景视图来描述软件架构。

1、逻辑视图，最终用户：功能需求。在逻辑视图中，系统分解成一系列功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可以用做标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象，封装，继承，可以用对象模型来代表逻辑视图。
逻辑视图通常包括类图，对象图，状态图和协作图。是描述系统各部分的抽象描述。

2、开发视图：编程人员：软件管理，也叫做模块视图，主要侧重软件模块的组织和管理。开发要考虑软件内容的需求，如软件开发的容易些，软件的重用，和软件的通用性。要充分考虑由于具体开发工具不同带来的局限性。开发视图用系统输入输出关系的模型图和子系统图来描述，可以在确定了软件包含所有元素之后描述完整的开发角度，也可以正确的每个元素前列出开发视图原则。

该视图包含包图和组件图。

3、进程视图：也叫做过程视图，主要描述系统中的进程，系统集成人员：性能，可扩充性，吞吐量，侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性，进程视图强调并发性，发布性，系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构，他也定义逻辑视图中各个类的操作具体在哪个现场中执行.

该视图通常包括活动图

4、物理视图：系统工程人员：系统拓扑，按照，通信等, 主要考虑如何把软件映射到硬件上，通常要考虑到节级系统拓扑结构，系统安装，通信等问题。

包含了部署图

5、场景：可以看作是那些重要系统活动的抽象，它使4个视图有机的联系在一起，场景是最重要的需求抽象。在开发架构时，他可以帮助设计者找到架构的构件和他们之间的作用关系。

同时，也可以用场景来分析一个特定的视图，描述不同视图构件之间是如何相互左右的，场景可以用文本表示，也可以用图形表示。

场景视图也叫做用例视图，从外部世界的角度描述正在建模的系统的功能，需要使用此视图来描述系统应该执行的操作。所有其他视图都依靠用例视图指导谈，这就是将模型成为4+1的原因

该视图通常包括用例图，描述和概述图。

逻辑视图和开发视图描述系统的静态结构，进程视图和物理视图描述系统的动态结构，对应不同软件系统来说，侧重的角度有所不同，

基于架构的软件设计方法ABSD

ABSD方法是体系结构驱动，指构成体系结构的商业，质量和功能需求的组合驱动的。

在基于体系结构的软件设计方法中，采用视角和视图来描述软件架构，采用用例来描述功能需求，采用质量场景来描述质量需求。

ABSD有3个基础

1功能的分解，在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。

2通过选择体系结构风格来实现质量和商业需求

3软件模板的使用

体系结构开发模型：体系结构需求，体系结构设计，体系结构文档化，体系结构复审，体系结构演化

特定领域软件体系结构DSSA（DDD)

特定领域软件架构是在一个特定应用领域中，为一组应用提供组织结构参考的标准软件体系结构。DSSA通常是一个具有三个层次的系统模型，包括领域开发环境（领域架构师），领域特定应用开发环境（应用工程师）和应用执行环境（操作员）。

领域分析，获得领域模型，领域模型描述领域中系统之间的共同需求，即领域需求。

领域设计，获得特定的领域软件架构。DSSA描述领域模型中表述需求的解决方案。

领域实现，根据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。

参与角色：领域专家，领域分析人员，领域设计人员，领域实现人员。

软件架构风格

软件架构设计的一个核心问题是能否使用重复的软件架构模式，能否达到架构级别的软件重用。也就是说能否宗不通的软件系统中，使用同一架构。

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

1、数据流风格

数据流风格是最常见的软件架构，结构最简单，所有数据按照流的形式在执行过程中前进，不存在结构的反复和重构，就像工程中的汽车流水线一样。在流动过程中，数据经过序列健的数据，物理组件进行处理，然后将组件进行处理，结果向后传递，最终进行输出。

数据流风格包含批处理序列，管道-过滤器

a批处理风格每一步处理都是独立的，顺序执行的。数据传送在步于步之间作为一个整体。批处理的经典应用是1经典数据处理，2程序开发，3程序编译/CASE(computer aided software engineering)工具

b管道和过滤器，在管道中进行传输，过滤器可以理解为加工，处理后输出数据流。每一个构件都有一组输入和输出，构件读输入的数据流，通过过滤器产生输出数据流。每个过程都是前后依赖的，他有点类似于流水线模式，首先原始数据经过管道，再进行过滤，继续传递给下一个管道，再到下一个过滤器，最终进行输出。

最常见的应用是文字检索系统，命令处理系统，如要查询一组数据，在ADO.NET中，需要打开数据库连接，创建命令对象，创建数据适配器，填充数据集，关闭数据库连接，返回数据集。

优点

支持重用性，只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。

系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉。

·允许对一些如吞吐量、死锁等属性的分析。

·支持并行执行。每个过滤器作为一个单独的任务完成，因此可与其他任务并行执行。

功能变更性较强，

在算法变更方面实现比较简单，只需要修改过滤器的实现即可

缺点

因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

性能方面，由于整个系统是松耦合连接在一起的，因此性能不太高

2、调用和返回风格

a主程序和子程序，是结构化开发时期的经典价格风格，一般是采用单线程控制，把问题划分为若干处理步骤，构架就是主程序和子程序，子程序通常可以合成为模块，过程调用作为交互机制，充当连接件。

调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。

优点:

–有效地将一个较复杂的程序系统设计任务分解成许多易于控制和处理的子任务，便于开发和维护–已被证明是成功的设计方法，可以被用于较大程序，

由于整个程序处在一个紧耦合的状态，因此性能较高

缺点:

–规模：程序超过10万行，表现不好；程序太大，开发太慢，测试越来越困难

–可重用性差、数据安全性差，难以开发大型软件和图形界面的应用软件

–把数据和处理数据的过程分离为相互独立的实体，当数据结构改变时，所有相关的处理过程都要进行相应的修改

–图形用户界面的应用程序，很难用过程来描述和实现，开发和维护也都很困难。

在算法变更方面灵活性较差，

功能变更方面较差，

b面向对象的风格

这种风格的构件是对象，或者是抽象数据类型实例，对象是一种被称为管理者的构件，负责保持资源的完整性。对象是通过函数和过程来交互的。

构件是可以重复使用的，叫做构件

风格优点

复用和维护：利用封装和聚合提高生产力

–因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。

–某一组件的算法与数据结构的修改不会影响其他组件

–组件之间依赖性降低，提高了复用度

反映现实世界

容易分解一个系统

–设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合

OO风格缺点

§管理大量的对象：怎样确立大量对象的结构

§继承引起复杂度，关键系统中慎用

§必须知道对象的身份

c层次结构风格

层次系统组成一个层次结构，每一层为上一层服务，并作为下层客户，除了一些精心挑选的函数外，内部的曾只对相邻的曾可见，连接件通过决定曾之间如何交互的协议来定义，拓扑约束包括项链曾之间交互的约束。

经典应用

OSA7层协议，BS,CS,MVC

–集中式部署(Mainframe)

–分布式部署(Distributed)

层次结构风格

1二层cs架构，客户机和服务器，CS架构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，cs架构定义了工作站（客户应用程序）如何与服务器相连，以实现数据和应用分布到多台计算机上，服务器负责有效的管理系统资源，主要任务集中于的对DBMS的管理和控制，以及数据的备份于回复，客户应用程序的主要任务是提供用户于数据库交互的界面，向服务器提交用户请求并接收来自服务器的信息，对于在客户端的数据执行应用逻辑要求。

这是一种胖客户机，瘦服务器的架构.

2三层cs架构，包括客户机和服务器，并且增加了一个应用服务器，可以将应用逻辑驻留在应用服务器上，只有表示层存在于客户机上，这种客户机成为瘦客户机。三层cs架构将应用系统分为表示层，功能层，数据层三个部分。减轻了客户端的工作。

表示层，是系统用户接口部分，承担用户于系统的对话功能。

功能层，也叫业务逻辑层，将具体业务逻辑编入程序中。

数据层，对DBMS进行管理和控制。DBMS也叫做数据库管理系统。

3bs架构，在bs架构中，除了数据库服务器外，应用程序以网页形式存放在Web服务器上，用户运行某个应用程序时，只须在客户端的浏览器中键入相应的网址，调用Web服务器上的应用程序，并对数据库进行操作，完成相应的数据处理工作，最后将结果通过浏览器显示给用户。

基于bs架构的软件，系统的安装/修改，维护全部在服务端解决，用户在使用系统时，只需要一个浏览器就可以运行全部模块，达到零客户端的功能，系统升级方便。

缺点是浏览器同步请求和响应模式交互数据，每次请求服务器都需要刷新一次页面。

受HTTP协议“基于文本的数据交换”的限制，在数据查询等响应速度上，要远远低于C/S体系结构；

数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用；

受限于HTML的表达能力，难以支持复杂GUI(如报表等)。

优点：

–支持基于抽象程度递增的系统设计，有利于设计者对一个复杂系统进行分解；

–局部依赖性，因为每一层至多和相邻的上下层交互，因此功能的改变通常影响相邻的上下层；

–可复用性，如果某独立层保证了功能的完整性并且提供了文档化的接口，便可在多个语境中复用。

–可替换性，只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。

–对标准化的支持。清晰定义并且广泛接受的抽象层次能够促进实现标准化的任务和接口开发，同样接口的不同实现能够互换使用。

–可测试性。具有定义明确的层接口以及交换层接口的各个实现的能力提高了可测试性。

缺点：

并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；

§效率的降低：

–由分层风格构成的系统，运行效率往往低于整体结构。

–在上层中的服务如果有很多依赖于最底层，则相关的数据必须通过一些中间层的若干次转化，才能传到；

§很难找到合适的、正确的层次抽象方法：

–层数太少，分层不能完全发挥这种风格的可复用性、可更改性和可移植性上的潜力。

–层数过多，则引入不必要的复杂性和层间隔离冗余以及层间传输开销。

–目前，没有可行的广为人们所认可的层粒度的确定和层任务的分配方法。

独立构件风格

独立构件风格包括进程通信和事件驱动的系统。

1进程通信。构件是独立的过程，连接件是消息传递。这种风格的特点是，构件通常是命名过程，消息传递的方式可以是点对点，异步或同步方式，以及远程过程，方法的调用。

2事件驱动的系统，构件不直接调用一个过程，而是触发或者广播一个或多个事件，构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用这个事件中注册的所有过程。

优点是为了软件复用提供了强大的支持，为构件的维护和优化带了了便利，缺点是放弃了对系统计算的控制。

常用的是按钮点击事件。

虚拟机风格

虚拟机风格包括了解释器，和基于规则到系统

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

解释器是一种自定义的风格，比较灵活

基于规则的系统，基于规则到系统包括规则集，规则解释器，规则/数据选择器和工作内存，一般用在人工智能领取和DSS中，

仓库风格

仓库风格包括数据库系统，黑板系统，超文本系统

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

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

黑板系统通常应用在对应解决问题没有确定性的软件中，如信号处理，语音识别，问题规划，编译器优化等等

3超文本系统，超文本系统出现的构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。

超文本是一种非线性的网状信息组织方式，他以节点为基本单位，链作为节点之间的联想式关联。

超文本系统通常应用在互联网领域。

管道-过滤器与数据存储的对比优缺点。

1.交互方式，管道-过滤器，传统的数据流风格是人机不交互的，数据存储支持人机交互

2.扩展性，管道-过滤器虽然也支持扩展性，但是扩展较麻烦，数据存储为中心的架构风格，可以灵活定义功能之间的逻辑顺序。

3.数据管理，数据存储为中心架构支持多种数据格式。

闭环（过程）控制，发出并接收反馈，设定参数不断调整，空调调温系统，汽车巡航定速系统。

C2风格，连接件与构件都i有顶部和底部，绑定连接件按规则运作。

面向服务器的架构，SOA

在SOA模型中，所有的功能定义了独立的服务，服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或者流程管理器来连接，这种松散偶尔的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。

在SOA架构中，继承了来自对象和构件设计的各种原则，保证服务的灵活性，松散耦合和复用能力的设计原则，对SOA架构来说同样的非常重要的。

SOA中的系统架构图包含，

1业务层，业务集合

2注册中心层，bind（把业务绑定到UDDI中），UDDI（用于发布服务），publish(发布)，企业服务总线ESB，

3安全验证，质量管理

4然后到服务层，服务集合，

5应用系统

数据交互的安全性需求，列举3中可实现信息系统安全保障的措施：

1，加密技术对数据加密后传输

2，交易类敏感信息采用数字签名机制

3，加防火墙

4，网闸

5，引入https协议，

6，采用信息摘要技术对重要信息进行完整性验证

关于服务的设计原则如下：

1.明确定义的接口，接口必须长期稳定性，定义明确性，接口内部私有性。

2.子包含和模块化，服务封装了业务稳定，重复出现的活动和构件，实现服务的功能实体的完全独立的。

与SOA紧密相关的技术有UDDI,WSDL,SOAP,REST等等，这些技术都是以XML为基础发展起来的。

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

WSDL，是Web服务描述语言，是对服务进行描述的语言，它有一套基于XML的语法定义，WSDL描述的重点是服务，它包含服务实现定义和服务接口定义。

SOAP，是简单对象访问协议，定义了服务请求这和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息，通过SOAP应用程序可以在网络中进行数据交换和远程过程调用.（remote Rrocedure call）

REST表属性状态转移，是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性，它的简单性和缺少严格配置文件的特性，使它SOAP很好的隔离开来。

实现SOA的方法，主流方式 Web Service，企业服务总线和服务注册表。

1，web service 在解决方案中一共有三种角色，其中服务提供者和服务请求者是必须的。服务注册中心是一个可选的角色，他们之间的交互和操作构成了SOA的一种实现架构。

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

服务注册中心，是服务的描述，是连接服务提供者和服务请求者的纽带，服务提供者在此发布他们的服务描述，而服务请求者在服务注册中心查找他们需要的服务，但不是必须的，也可以跳过注册中心直接交互。

服务请求者，发起请求，是服务的使用者，从架构角度看，服务请求者是查找，绑定并调用服务，或与服务进行交互的应用程序，请求的角色可以由浏览器来担当，由人或者程序来控制。

2，服务注册表

虽然也具有运行时的功能，但是在SOA设计时使用，它提供一个策略执行点，在这个点上，服务可以在SOA中注册，从而可以被发现和使用。

3，企业服务总线

是一个具有标准接口，实现了互连，通信，服务路由，支持实现SOA。面向服务架构的企业级信息系统基础平台。它提供消息驱动，事件驱动，文本导向的处理模式，支持基于内容的服务路由。

支持分布式存储，分布式处理，异步处理。

为信息系统的松耦合提供架构保障

简化企业整个信息系统的复杂性

提高信息系统的架构灵活性，

降低企业内部的信息共享成本

REST，表述性状态转移，REST最大的几个特点为，资源，统一接口，URL和无状态。

REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲更加简洁，如亚马逊提供了接近REST风格的Web服务进行图书查找，雅虎提供了Rest风格的Web服务。

RESTful架构的经典应用是HTTP，它就因其可扩展性和简单性，受越来越多的架构师和开发者青睐，一方面随着云计算和移动计算的星期，很多企业愿意在互联网上共享自己的数据和功能。另一方面在企业中，RESTful API 也成为RESTful Web服务，逐渐超越SOAP，成为实现SOA的重要手段之一。

RESTful API可以用一句话来概括，用URI定位资源，用HTTP动词（GET,HEAD,POST,DELETE,PUT,PATCH）描述操作，用状态码表示操作结果。

REST提出了一些设计概念和准则：

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

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

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

4对资源的各种操作不好改变资源标识

5所有操作都是无状态的

资源

就是网络上的一个实体，或者网络是一个具体信息，它可以是一段文本，一张图片，一首歌曲，一种服务，总之就是一个具体的存在。

资源的表述

是一段对于资源在某个特定时刻的状态的描述。可以在客户端-服务器端之间转移（交换），资源的表述可以由多种个视，如HTML/XML/JSON/纯文本/图片/视频/音频。

资源的表述格式可以通过协商机制来缺点，请求-响应方向的表述通常使用不同的个格式。

URI

可以用一个URI（统一资源定位符）指向资源，即每一个URL都对应一个特定的资源，要获取这个资源，访问它的URI就可以了，因此URI就成了每个资源的地址或者识别符，一般的，每个资源至少由一个URI与之对应，最典型的URI就是URL。

与这个资源互动时，使用不同的HTTP方法，就是代表对这个资源不同的操作。

GET获取资源

HEAD 获取资源概况

POST新建资源

PUT更新资源

PATCH更新资源

DELETE删除资源

REST要求，必须通过统一的接口来对资源执行各种操作

GET/HEAD/PUT/DELETE方法是幂等方法，多次请求与一次效果相同

GET/HEAD方法是安全方法，不能对服务器上的资源做改变

无状态

对于客户端的资源请求，服务器不仅要返回所请求的资源，而且要根据请求返回用户所处的状态和可转移的状态。

客户端不需要提前知道应用由哪些状态，而是根据服务器端响应的可转移的状态，根据给用户选择，从而发生状态转移。如10086，由服务器端引导用户进行操作.

使用RESTful风格可以克服传统架构风格的4个缺陷：

1设计API工作量减少，因为功能需求一旦出来，需要操作的资源，操作的方式立刻就能分析出来，因此资源URI和API的使用方式都很容易得到

2没有了操作之间的依赖，资源之间虽然可能有关联，但是小得多。

3对资源的操作也就那么集中，API的一致性，自我描述性很强，不需要过多解释。

4对于GET请求，我们可以考虑使用缓存，因为在RESTful架构中，GET请求代表获取数据，必须是安全的，幂等的。

J2EE分层架构

1，客户层，Applet，HMLT，客户端的程序，它们可以直接嵌入网页或者其他特定的容器中，并产生特殊的效果

2，Web层，Serlet/jsp，JSP侧重于视图，相当于View，Serlet主要用于控制逻辑，类似于一个controller。

3，业务逻辑层，EJB容器，EJB中的Bean相当于MVC中的Model。Entity Bean, Session Bean, Message Bean

4，持久层，hibernate，mybatis

hibernate和mybatis的区别

1开发方面，在项目开发过程中，就速度而言，hibernate开发中sql语句以及被封装，可以直接使用，加快系统开发，mybatis属于半自动化，sql需要手动完成，稍微繁琐。

2sql优化方面，hibernate自动生成sql，有些语句较为繁琐，会多消耗一些性能，mybatis手动编写sql，可以避免不需要的查询，提高系统性能。

3对象管理方面，hibernate是完整的对象-关系的映射框架，开发工程中，无需过多关注底层的实现，只要去管理对象即可。mybatis需要自行管理映射关系。

4缓存方面，hibernate在使用二级缓存时如果出现脏数据，系统会报错错误并提示，mybatis脏读不报错。

多层架构的优点：

1开发人员可以只关注整个结构中的其中某一层。

2可以很容易的用新的实现来代替原有层次的实现。

3可以降低层与层之间的依赖。

4有利于标准化

5利于各逻辑的复用

6扩展性强，不同层负责不同的曾经。

7安全性高，用户端智能通过逻辑层访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。

8项目结构更清楚，分工更加明确，有利于后期的维护和升级。

多层架构的缺点：

1严格的分层可能导致性能问题，具体取决于层数

2建立清晰的分层架构并总是很容易。

ORM映射方式的优点

1降低了学习和开发成本

2程序员不要再写sql进行数据库操作

3减少了程序的代码量

4降低了由于sql代码质量差带来的影响。

ORM的缺点

1性能比之间用SQL差

2处理复杂的查询比较困难

MVC模式

M，model，模型，主要职责是处理业务逻辑，保存数据的状态，代表应用程序的状态，响应状态查询，处理业务流程，通知视图业务状态更新。

V，View，视图，主要职责是显示,JSP, 显示模型的状态，接受数据更新请求，把用户输入的数据传给控制器，

C，Controller，控制器，主要取得表单参数，使用业务逻辑，转向页面，serlet，接收用户请求，调用模型来响应请求，选择视图显示响应结果

视图-> 选择视图->控制器->业务处理->模型->状态查询->视图

mvc模式的来设计表现层的优点：

1运行多种用户界面的扩展

2易于维护

3功能强大的用户界面

MVP模式

View，Model，Presenter，

MVP中的P是Presenter，用于逻辑处理，与MVC不同的是，View并不直接使用Model，而是通过Presenter来进行，交互都在Presenter内部。在传统的MVC模式中，View是可以访问Model的，所以导致View中不可避免的存在一些业务逻辑.

MVP把Model与View进行分离，可以在需要变更View的时候，保存Presenter的不变，保持重用性。并且更好的增加了测试性，我们可以单独编写测试用的View，来模拟用户的各种操作。甚至在Model跟View没有开发完成时，就可以编写Mock Object来测试presenter的逻辑。

在MVP模式中，View应该只有最简单的Get、Set方法，用户输入和设置界面显示的内容，不允许直接访问Model。

J2EE与MVP是一种从属关系，

MVP模式的优点：

1低耦合, 模型与视图完成分离

2可以更高效地使用模型

3复用性好

4可测试性好

MVP模式的缺点

对视图的渲染都放在了presenter中，视图和presenter的交互会过于频繁。

presenter过多的渲染了视图，往往使它与特定的视图联系过于紧密，一旦视图变更presenter也需要变更。

MVVM模式（双向绑定）

View，View model， Model

MVVM是MVP进化而来，MVVM模式基本上与MVP相同，只是把MVP中的P变成了VM，即ViewModel，MVVM中的数据可以实现双向绑定，当Model变化时，View-Model会自动更新，View也会自动变化。很好的做好了数据的一致性。MVVM模式又叫做Model-View-Binder模式。

因此MVVM框架毕竟是和逻辑复杂的前端项目，比如一些管理系统。

微服务架构

SOA与微服务架构对比

1.服务粒度，SOA粗，微服务细

2.服务通信，SOA重量级,ESB，微服务是轻量级，如HTTP, RESTful

3.服务交付，SOA慢，微服务快

4.应用场景，SOA企业级，微服务互联网

5.模式，SOA是整个，微服务是拆分

微服务是一种架构风格，将单体应用划分成一组小的服务，服务之间相互协作，实现业务功能每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作，通常是HTTP/JSON，每个服务围绕业务能力进行构建，并能够通过自动化机制独立地部署。

微服务中很少有集中式的服务管理，每个服务可以使用不同的语言开发，使用不同的存储技术。

微服务架构总体技术体系

微服务目前没有固定的架构方式，由企业自己来制定架构的规则，通常的结构可能包括：

1接入层，包括外部，内部LB，

2网关层，API，

3业务服务层，聚会服务，基础服务

4支撑服务，注册发现，集中配置，容错限流，认证授权，日志聚合，监控告警，后台服务（DB,MQ,CACHE,JOB)

5平台服务，发布系统，集群资源调度，镜像治理，IAM

6基础设施层，计算，网络，存储，NOC监控，安全，IDC。

微服务的基础组件：

应用网关API的作用：

1.提供统一入口

2.可以进行权限身份认证等安全管理

3.可以根据流量进行限流

4.数据缓存

5.性能监控

6.异常重试

7.服务降级

微服务的基本组件：

1.服务描述，常用的服务描述方式由RESTful，API，XML配置，IDL文件

2.注册中心，服务者发布服务，消费者定远服务，返回服务列表，通知变更。

3.服务框架，通信协议，数据传输方式

4.服务监控，指标收集，数据展示

5.服务追踪，追踪服务经过的链路，进行追踪与故障定位。

6.服务治理。节点管理，负载均衡，制定服务路由规则，服务容错等。

负载均衡的算法：

负载均衡主要是对服务器资源分配的算法，

1、轮询法

　　将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

2、随机法

通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多，

其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。

3、源地址哈希法

源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

4、加权轮询法

　　不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

5、加权随机法

与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。

6、最小连接数法

最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前

积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

微服务中常用的基础组件包含，RPC, REST，

RPC是远程过程调用，

REST是前后台通信的方式，

RPC与REST的对比

1.耦合性，RPC是强耦合， REST是松散耦合

2.消息协议，RPC是二进制，thrift，protobuf，avro, REST是文本XML，JSON

3.通信协议，RPC是TCP， REST是HTTP/HTTP2

4.性能，RPC高，REST对比RPC相对较低，

5.接口契约IDL，thrift，protobuf idl ，REST主要是swagger

6.客户端，RPC是强类型客户端，一般自动生成，可以支持多种客户端，REST一般是HTTP client可以访问，也可以自动生成强类型客户端，支持多语言客户端

7.案例，Dubbo，motan，REST，Spring MVC/Boot,

8.开发者友好，客户端比较方便，但是二进制消息不可读，REST文本消息开发者可读，浏览器可以访问

9.对外开放，RPC对外一般需要转换成REST/文本协议，REST直接对外开放。

微服务的优点：

1.每个微服务都很小，主要能聚焦一个指定的业务功能或者业务需求

2.微服务能够被小团队单独开发，2-5人的开发人员组成

3.微服务是松耦合的，是由功能意义的服务，无论是开发阶段或者部署阶段都是独立的

4.微服务能使用不同的语言开发

5.去中心化，每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库。

微服务的缺点

1很难在不采用分布式事务的情况下跨服务实现功能

2.测试工作更加困难

3.跨服务实现要求团队之间紧密协作

4.部署复杂

架构评估

按照某种规则进行设计架构后，根据质量属性进行架构的评估。

架构风格的质量属性

1.非功能性需求，并不被功能所决定

2.不同的软件项目，关注不同的质量属性

3.质量属性质检可能相互抑制。

质量属性包含6大质量属性，27种特性

常用的质量属性包括：可用性，可修改性，性能，安全性

1、可用性

正常运行的时间比例。当用户使用系统时，系统可用的概率。

提升可用性的策略：

错误检测：心跳、Ping、Echo，异常

错误恢复：表决，主动冗余，被动冗余，重新同步、内测、检查点、回滚

错误避免：服务下线、事务、进程监控器

心跳：被监控组件定期向监控的组件发出心跳消息。如果连续未收到的心跳信号到了一定的数目，则认为相应的系统出现了故障。

Ping/Echo，监控组件不定期的向北监控的组件发出Ping消息，并根据收到的Echo消息作出响应。

异常：需要编程语言的支持。如抛出/捕获+处理

表决：多个冗余的组件，用同一或不同的算法来完成一个任务，如果计算结果不同，则由表决器安装算法（少数服从多数的原则）。

主动冗余：服务器A和B并行完成同样的运算，他们的状态时刻保持一致，平时只取A算出的结果，当A出现故障时，系统可用迅速切换到B。

被动冗余：服务器A完成运算后，在一定时间内通知服务器B进行更新。

重新同步：主动冗余和被动冗余都需要在重新上线前，做状态的重新同步。

内测：内部测试，提升可用性

被检查点/回滚，定期保存，便于回复

服务下线：避免错误的发生，可能需要服务下线

事务：多个操作连续完成。

进程监控器：任务管理器，可以查询与操作任务进程

2/性能：

处理任务所需要的时间或者单位时间内的处理量

提升性能的策略：

1.资源的需求，减少处理事件时对资源的占用，减少处理事件的数量，控制资源的使用

2.资源管理，并发机制，增加资源

3.资源仲裁，先来先服务，固定优先级，动态优先级，静态调度。

减少处理事件时对资源的占用

1改进算法

2减少计算开销

减少处理事件的数量

1控制事件到来的速率

2控制采样频率

控制资源的使用

1限制执行时间

2限制队列大小

并发机制

多核，多线程

增加资源

1.计算资源

2.存储资源

3.带宽资源

动态优先

1.时限时间最早优先

2.轮转调度

3/可修改性

修改的成本/时间/内容/人力

提升可修改性的策略：

局部化修改：高内聚低耦合，预测变更，使模块通用

防止连锁反映

信息隐藏，维持现有接口/限制通信路径

推迟绑定时间：

运行时注册，多态，配置文件

高内聚低耦合，将对程序的修改控制在一个模块内

预测变更，

使模块通用

信息隐藏：利用面向对象中的可访问性，publick,private, protected

维持现有接口：接口不变的情况下，双方都能独立变化。

限制通信的路径：外观模式，

中介技术

1数据中介：仓库，数据共享风格

2服务中介：工厂方法模式，代理模式

运行时注册

即插即用

动态，动态绑定，

配置文件，配置文件来避免来修改代码

4安全性

系统向合法用户提供服务并阻止非法用户的能力

提升可修改性的策略：

1抵抗攻击，用户身份验证，用户授权，维护数据机密性与完整性，限制暴露，限制访问

2检测攻击，入侵检测系统,追踪审计

3恢复状态，识别攻击者

用户身份验证：动态密码，一次性密码，生物识别

用户授权：对用户访问进行控制管理

维护数据的机密性：给数据和传输过程加密，如HTTPS

维护数据的完整性：MD5码校验

限制暴露

1关闭无用端口，自启用的服务，无线路由SSID等

2恢复状态，恢复检查点

3识别攻击者，用于预防或惩罚性目的

架构特性：

敏感点，权衡点，风险点

1.敏感点，为了实现某种特定的质量属性，一个或多个系统组件所具有的特性。

举例：对查询请求处理时间的要求，将影响系统的数据传输协议和处理过程的设计，查询请求处理时间，一般是要求性能，影响设计，是系统的特性。

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

举例：如更改系统加密的级别，将对安全性和性能产生影响，对2个质量属性进行了影响，所以是权衡点

3.风险点，不以标准术语出现，风险点的某些做法有一些隐患可能导致一些问题。没有达成共识都属于风险点

非风险点，是某些做法是可行的，可接受的。

举例：如果养护报告生成，业务逻辑的描述尚未达成共识，可能导致部分业务功能模块规则的矛盾，影响系统的可修改性，按照公式没有达成共识都属于风险点

架构评估方法

从技术手段分，分为三类：

1/基于调查问卷或检查表的方式，

2/基于场景的方式

3/基于度量的方式

基于调查问卷或检查表的方式，

该方式的关键是要设计好问卷或检查表，它充分利用系统相关人员的经验和知识，获得对架构的评估，缺点是在很大程度上依赖于评估人员的主观判断，

基础场景的方式：

1/基于场景的方式包括架构权衡分析法,ATAM， architecture tradeoff analysis method

2/软件架构分析方式SAAM， software architectrue analysis method

3/成本收益分析方式CBAM，cost benfit analysis method

基于度量的方式

制定一些定量值来度量架构，如代码行数，要制定质量属性和度量结构之间的映射。

SAAM评估方法

SAAM是一种非质量属性的架构分析分析方法，SAAM的主要输入是问题描述，需求说明，架构描述，其分析过程主要包括场景开发，架构描述，单个场景评估，场景交互，总体评估。

1.形成场景

2.描述架构

3.对场景分类和确定优先级

4.对场景进行单个评估

5.场景评估的相互作用

6.形成总体评价

AMAM方法

评估活动步骤

1.描述ATAM方法：评估小组分组人向参加会议的项目干系人介绍ATAM评估方法。

2.描述业务动机：项目决策者从业务的角度介绍系统的概况，该描述应该包括系统最重要的功能，技术/管理/经离和政治方面的任何相关限制，与该项目相关的业务目标和上下文，

主要的项目干系人，以及架构的驱动因素等。

3.描述架构：包括技术约束，如操作系统/硬件/中间件等，将与本系统进行交互的其他系统，用以满足质量属性要求的架构方式等。

123是描述介绍阶段

4.确定架构方法：通过理解架构方法来分析架构，在这以不，由架构师确定架构方法，

5.生成质量属性效用树，评估小组，设计小组，管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。

6.分析架构方法，从质量属性入手，这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表，敏感点，权衡点列表。

456是调查和分析阶段，

7。讨论场景和场景分级，项目干系人进行两项相关的活动，分别是集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，项目干系人是一个终端用户，使用系统执行的一些功能，一旦收集了若干个场景后，必须设置优先级，评估人员通过投票表决的方式来完成。

8。分析架构方法：在收集并分析了场景后，设计师可以把最高级别的场景映射到描述的架构中，并对相关的架构如何由助于该场景的实现做出解释，在这一步中，评估小组要重复第6步的工作，把心得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第7步中，如何未产生任何在以前的分析步骤中都没有发现的高优先级场景，则在第8不就是测试步骤。

78是测试阶段

9.描述评估结果：最后要把ATAM分析中所得到的各种信息进行归纳，并反馈给项目干系人，ATAM的评估结果包括一个简洁的架构描述，表达清楚的业务目标，用场景集合捕捉质量属性，所确定的敏感点和权衡点的集合，由风险决策和无风险决策，风险主题的集合。

9是报告阶段

ATAM方法是系统架构评估的一种架构权衡分析方法，主要在系统开发前针对性能，可用性，安全性，可修改性等质量属性进行评价和这种。

ATAM可以分为4个活动阶段，包括：

1/场景和需求收集，

2架构视图的描述，（体系结构视图和场景实现）

3属性模型构造和分析，

4架构决策与折中，

整个评估过程强调以属性为架构评估的核心概念。

用到的工具就是质量效用树， Utility tree，如何开展分析，主要描述质量项目树中关注的是哪几个质量属性。

AMAM方法评估的参与者：