比较全的常见的架构设计思想整理

1、MPP 架构

一、MPP架构的基础概念

MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每一个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特色划分到各个节点上，每台数据节点经过专用网络或者商业通用网络互相链接，彼此协同计算，做为总体提供数据库服务。非共享数据库集群有彻底的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优点。

简单来讲，MPP是将任务并行的分散到多个服务器和节点上，在每一个节点上计算完成后，将各自部分的结果汇总在一块儿获得最终的结果(与Hadoop类似)。

 

 

MPP 属于Shared Nothing，根据Shared 的不一样，能够分为以下几种：

Shared Everthting:通常是针对单个主机，彻底透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的表明SQLServer

Shared Disk：各个处理单元使用本身的私有 CPU和Memory，共享磁盘系统。典型的表明Oracle Rac， 它是数据共享，可经过增长节点来提升并行处理的能力，扩展能力较好。其相似于SMP（对称多处理）模式，可是当存储器接口达到饱和的时候，增长节点并不能得到更高的性能 。

Shared Nothing：各个处理单元都有本身私有的CPU/内存/硬盘等，不存在共享资源，相似于MPP（大规模并行处理）模式，各处理单元之间经过协议通讯，并行处理和扩展能力更好。典型表明DB2 DPF和hadoop ，各节点相互独立，各自处理本身的数据，处理后的结果可能向上层汇总或在节点间流转。

咱们常说的 Sharding 其实就是Share Nothing架构，它是把某个表从物理存储上被水平分割，并分配给多台服务器（或多个实例），每台服务器能够独立工做，具有共同的schema，好比MySQL Proxy和Google的各类架构，只需增长服务器数就能够增长处理能力和容量。

不少 Nosql数据库都是基于 MPP Shared Nothing架构的，好比

Greenplum是一种基于PostgreSQL的分布式数据库。其采用shared nothing架构（MPP），主机，操做系统，内存，存储都是自我控制的，不存在共享。也就是每一个节点都是一个单独的数据库。节点之间的信息交互是经过节点互联网络实现。经过将数据分布到多个节点上来实现规模数据的存储，经过并行查询处理来提升查询性能。
这个就像是把小数据库组织起来，联合成一个大型数据库。将数据分片，存储在每一个节点上。每一个节点仅查询本身的数据。所获得的结果再通过主节点处理获得最终结果。经过增长节点数目达到系统线性扩展。

elasticsearch也是一种MPP架构的数据库，Presto、Impala等都是MPP engine，各节点不共享资源，每一个executor能够独自完成数据的读取和计算，缺点在于怕stragglers，遇到后整个engine的性能降低到该straggler的能力，所谓木桶的短板，这也是为何MPP架构不适合异构的机器，要求各节点配置同样。

Spark SQL应该仍是算作Batching Processing, 中间计算结果须要落地到磁盘，因此查询效率没有MPP架构的引擎（如Impala）高。

二、MPP架构特征

● 任务并行执行;

● 数据分布式存储(本地化);

● 分布式计算;

● 私有资源;

● 横向扩展;

● Shared Nothing架构。

三、基于MPP架构的数据库架构

这种架构中的每个节点（node）都是独立的、自给的、节点之间对等，并且整个系统中不存在单点瓶颈，具备很是强的扩展性。

 

2、SMP(Symmetric Multi-Processor)架构

SMP又称对称多处理器结构，SMP系统内有许多紧耦合多处理器，在这样的系统中，全部的CPU共享所有资源，如总线，内存和I/O系统等;

所谓对称多处理器结构，是指服务器中多个 CPU 对称工做，无主次或从属关系。各 CPU 共享相同的物理内存，每一个 CPU 访问内存中的任何地址所需时间是相同的，所以 SMP 也被称为一致存储器访问结构 (UMA ： Uniform Memory Access) 。对 SMP 服务器进行扩展的方式包括增长内存、使用更快的 CPU 、增长 CPU 、扩充 I/O( 槽口数与总线数 ) 以及添加更多的外部设备 ( 一般是磁盘存储 ) 。

主要特征是共享，系统中全部资源 (CPU 、内存、 I/O 等 ) 都是共享的。也正是因为这种特征，致使了SMP 服务器的主要问题，那就是它的扩展能力很是有限。对于 SMP 服务器而言，每个共享的环节均可能形成 SMP 服务器扩展时的瓶颈，而最受限制的则是内存。因为每一个 CPU 必须经过相同的内存总线访问相同的内存资源，所以随着 CPU 数量的增长，内存访问冲突将迅速增长，最终会形成 CPU 资源的浪费，使 CPU 性能的有效性大大下降。实验证实， SMP 服务器 CPU 利用率最好的状况是 2 至 4 个 CPU 。

3、SOA 架构

SOA 即面向服务的架构，将应用程序的不一样功能单元（称为服务）进行拆分，并经过这些服务之间定义良好的接口和协议联系起来，接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操做系统和编程语言。这使得构件在各类各样的系统中的服务能够以一种统一和通用的方式进行交互。

面向服务架构，它能够根据需求经过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，能够直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性，SOA是一种粗粒度、松耦合服务架构，服务之间经过简单、精肯定义接口进行通信，不涉及底层编程接口和通信模型。

松耦合系统脚骨的好处有两点：

一、它的灵活性，它很是的灵活。

二、当组成整个应用程序的每一个服务的内部结构和实现逐渐地发生改变时，它可以继续存在。与之相反，紧耦合意味着应用程序的不一样组件之间的接口与其功能和结构是紧密相连的，于是当须要对部分或整个应用程序进行某种形式的更改时，它们就显得很是脆弱。

 

 

一个服务一般以独立的形式存在与操做系统进程中。各个服务之间经过网络调用跟SOA 相提并论的还有一个ESB（企业服务总线），单来讲ESB 就是一根管道，用来链接各个服务节点。为了集成不一样系统，不一样协议的服务，ESB 作了消息的转化解释和路由工做，让不一样的服务互联互通。

SOA 所解决的核心问题：

1. 系统集成：站在系统的角度，解决企业系统间的通讯问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步每每须要引入一些产品，好比ESB、以及技术规范、服务管理规范；
这一步解决的核心问题是【有序】

2. 系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，经过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】

3. 业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提高企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。

本文做者：张永清 来源出处：http://www.javashuo.com/article/p-tymdoedk-b.html

4、微服务架构

微服务架构其实和SOA 架构相似,微服务是在SOA 上作的升华，微服务架构强调的一个重点是“业务须要完全的组件化和服务化”，原有的单个业务系统会拆分为多个能够独立开发、设计、运行的小应用。这些小应用之间经过服务完成交互和集成。

组件表示一个能够独立更换和升级的单元，就像PC 中的CPU、内存、显卡、硬盘同样，独立且能够更换升级而不影响其余单元。若是咱们把PC 做为组件以服务的方式构建，那么这台PC 只须要维护主板和一些必要的外部设备。CPU、内存、硬盘都是以组件方式提供服务，PC 须要调用CPU 作计算处理，只须要知道CPU 这个组件的地址便可。

 

 

 

 

SOA与微服务区别：

一、SOA注重重用，微服务注重重写

SOA 的主要目的是为了企业各个系统更加容易地融合在一块儿。
微服务一般由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不必定必要。咱们向微服务迁移的时候一般从耦合度最低的模块或对扩展性要求最高的模块开始。

把它们一个一个剥离出来用敏捷地重写，能够尝试最新的技术和语言和框架，而后 单独布署。它一般不依赖其余服务。微服务中经常使用的 API Gateway 的模式主要目的也不是重用代码。

而是减小客户端和服务间的往来。API gateway 模式不等同与 Facade 模式，咱们可使用如 Future 之类的调用，甚至返回不完整数据。

二、SOA注重水平服务，微服务注重垂直服务

本文做者：张永清 来源出处：http://www.javashuo.com/article/p-tymdoedk-b.html

SOA 设计喜欢给服务分层(如 Service Layers 模式)。咱们经常见到一个 Entity 服务层的设计，美其名曰 Data Access Layer。这种设计要求全部的服务都经过这个 Entity 服务层。来获取数据。这种设计很是不灵活，好比每次数据层的改动均可能影响到全部业务层的服务。而每一个微服务一般有它本身独立的 Data Store。咱们在拆分数据库时能够适当的作些去范式化，让它不须要依赖其余服务的数据。

微服务一般是直接面对用户的，每一个微服务一般直接为用户提供某个功能。相似的功能可能针对手机有一个服务，针对机顶盒是另一个服务。在 SOA 设计模式中这种状况一般会用到 Multi-ChannelEndpoint 的模式返回一个大而全的结果兼顾到全部的客户端的需求。

三、SOA注重自上而下，微服务注重自下而上

SOA 架构在设计开始时会先定义好服务合同。它喜欢集中管理全部的服务，包括集中管理业务逻辑，数据，流程，Schema 等。它使用 Enterprise Inventory 和 Service Composition 等方法来集中管理服务。SOA 架构一般会预先把每一个模块服务接口都定义好。模块系统间的通信必须遵照这些接口，各服务是针对他们的调用者。

SOA 架构适用于 TO GAF 之类的架构方法论。

微服务则敏捷得多。只要用户用获得，就先把这个服务挖出来。而后针对性的，快速确认业务需求，快速开发迭代。

微服务与 SOA 有不少相同之处。二者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念建立架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的，而它与 SOA 原则的演化的目标也是相同的，则减小传统的企业服务总线开发的高复杂性。二者之间最关键的区别在于，微服务专一于以自治的方式产生价值。可是两种架构背后的意图是不一样的：SOA 尝试将应用集成，通常采用中央管理模式来确保各应用可以交互运做。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

5、架构设计图

一、技术架构

从技术层面描述，主要是分层模型，例如持久层、数据层、逻辑层、应用层、表现层等，而后每层使用什么技术框架，例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术可以将整个系统的主要实现归纳

二、系统架构

指的完整系统的组成架构，例如系统分红几个部分？服务平台、管理门户、终端门户、ATM门户、外部系统以及接口、支撑系统等，将这些系统进行合理的划分。而后再进行功能分类细分，总之，将整个系统业务分解为逻辑功能模块，而且科学合理，就是系统架构

三、部署架构

指的是系统如何部署，包括应用的节点机器，网络、交换机，防火墙等。好比采用什么网络，nginx 部署几台，vip如何转发、APP应用部署多少个节点等。

四、数据架构

数据架构指导数据库的设计. 不只仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

五、代码架构

子系统代码架构主要为开发人员提供切实可行的指导，若是代码架构设计不足，就会形成影响全局的架构设计。好比公司内不一样的开发团队使用不一样的技术栈或者组件，结果公司总体架构设计就会失控。

代码架构主要定义：

①. 代码单元:

配置设计框架、类库。

②. 代码单元组织：

编码规范，编码的惯例。项目模块划分顶层文件结构设计，好比mvc设计。依赖关系

6、分布式架构中分布式事务的解决方案

一、分布式架构中分布式事务问题以及2PC/3PC协议

1）、单机ACID事务：

ACID原则是数据库事务正常执行的四个，分别指原子性、一致性、独立性及持久性。可是随着项目愈来愈大，数据量愈来愈多，单台数据库的磁盘系统被占满了或是单张表数据量太大，致使客户端请求数据库时存在阻塞问题或者是效率问题，此时的作法是将数据库进行分库分表，将数据按必定的规则（好比按照不一样的业务）分配到不一样的机器上，此时数据会在多个分布于不一样服务器中的数据库，因此产生了分布式事务的问题。

2）、分布式事务：

分布式事务指的是跨系统、跨机器之间的事务，因为其不知足单机的ACID特性，因此分布式事务每每很复杂。分布式数据库的通常划分方式以下：

• 垂直切分：将单个表按业务细化出多张表，每张表存放着不一样的字段，当须要使用到多张表时将其链接在一块儿（join）便可获取到所需的数据。

• 水平切分：使用多台数据库或表，将原先位于一个库或表的数据按某种规则映射到不一样的机器上，以此来减小原先单库或单表中所含的数据大小。
• 按业务流程拆分：
  • 一般，出现分库分表的场景还和业务拆分相关，一个很大的系统每每会拆分为多个小系统，每一个小系统之间经过RPC来进行调用，相互协调完成业务，这也会出现分布式事务的问题：

 

 

 

3）、两阶段提交协议（2PC）：

两阶段提交协议(2PC)是处理分布式事务的一种基本协议，两阶段指的是prepare和commit/rollback阶段，而且划分出了事务管理器与资源管理器角色：

在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。

在第一阶段，事务管理器询问全部资源管理器准备是否成功（prepare）。

若是全部资源均准备成功，那么在第二阶段事务管理器会要求全部资源管理器执行提交操做（commit）。

若是任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求全部资源管理器在第二阶段执行回滚操做（rollback）。

经过事务管理器的两阶段协调，最终全部资源管理器要么所有提交，要么所有回滚，最终状态都是一致的。
　　

•  该分布式系统中，存在一个节点做为协调者(Coordinator)，其余节点做为参与者(Cohorts)。且节点之间能够进行网络通讯。
• 全部节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即便节点损坏不会致使日志数据的消失。
• 全部节点不会永久性损坏，即便损坏后仍然能够恢复。

优缺点：

优势：原理简单，实现方便。

缺点：
同步阻塞问题。执行过程当中，全部参与节点都是事务阻塞型的。当参与者占有公共资源时，其余第三方节点访问公共资源不得不处于阻塞状态。

单点故障。因为协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤为在第二阶段，协调者发生故障，那么全部的参与者还都处于锁定事务资源的状态中，而没法继续完成事务操做。（若是是协调者挂掉，能够从新选举一个协调者，可是没法解决由于协调者宕机致使的参与者处于阻塞状态的问题）

数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求以后，发生了局部网络异常或者在发送commit请求过程当中协调者发生了故障，这回致使只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求以后就会执行commit操做。可是其余部分未接到commit请求的机器则没法执行事务提交。因而整个分布式系统便出现了数据部一致性的现象。

二阶段没法解决的问题：协调者再发出commit消息以后宕机，而惟一接收到这条消息的参与者同时也宕机了。那么即便协调者经过选举协议产生了新的协调者，这条事务的状态也是不肯定的，没人知道事务是否被已经提交。

4）、三阶段提交协议（3PC）

3PC，Three-Phase Commit，三阶段提交协议，由CanCommit、PreCommit、Do Commit三阶段组成。三阶段提交协议（3PC）相较于2PC来讲，新增了一个预提交阶段（preCommit）与超时机制来再次校验当前是否所有资源管理器（参与者）都可以提交成功（或超时），若成功则进行真正的提交阶段，若不成功则回滚。

阶段一：Can Commit

1. 事务询问。协调者向参与者发送一个包含事务内容的canCommit请求，询问是否能够执行事务提交操做，并开始等待参与者相应。
2. 参与者向协调者反馈事务询问的相应。

Can Commit阶段和2PC的提交请求阶段同样。

阶段二：PreCommit

执行事务PreCommit

假如协调者获取的全部相应都是YES则执行事务预提交。

1. 发送预提交请求。
2. 事务预提交，执行事务操做，并将Undo和Redo信息记录到事务日志中
3. 各参与中向协调者反馈事务执行结果的相应。

阶段三：doCommit
真正的事务提交，存在两种结果：

执行提交

1. 发送提交请求 协调者由预提交转换到提交状态，向全部参与者发送doCommit请求
2. 事务提交 参与者收到doCommit请求后，执行事务提交
3. 反馈事务提交结果 参与者完成事务提交后，向协调者发送ACK消息
4. 完成事务 协调者接收到全部参与者反馈的ACK消息后，完成事务

中断事务

1. 发送中断请求
2. 事务回滚
3. 反馈事务回滚结果
4. 中断事务

进入阶段三也存在两种故障：

1. 协调者出现问题
2. 协调者和参与者网络出现问题。

不管出现那种状况，最终都会导参与者没法及时接收到来自接收到协调者的doCommit请求或者是abort请求，针对这样的异常，参与者都会在等待超时以后，继续进行事务提交。

 

 

优势：下降参与者阻塞范围，并可以在出现单点故障后继续达成一致

缺点：引入preCommit阶段，在这个阶段若是出现网络分区，协调者没法与参与者正常通讯，参与者依然会进行事务提交，形成数据不一致。

3PC解决了参与者的阻塞范围，而且解决了协调者单点故障的问题。可是3PC仍是存在问题：3PC没法解决当存在网络分区的时候，参与者没法通讯的问题，在这种状况下，参与者只有一部分参与者可以执行提交请求，形成参与者数据不一致。

二、带有业务侵入的分布式事务解决方案：

1）、消息队列：

对于分布式事务问题，最简单的一种方式是使用消息队列来做为消息表，在业务的调用流程中经过消息队列来传达事务的执行结果，而后下一个流程做为消费者消费这个执行结果便可。因为要借助消息队列来完成这个过程，因此这种作法是有业务侵入的。

优缺点：

使用MQ解决分布式事务问题有以下的优势和缺点：

优势：简单易实现，而且随着MQ集群的出现和RocketMQ的prepare机制，使得这种方案具有高可用性和高性能，能达到最终一致性。是最多见的解决方案。

缺点：消费者只能成功，不能失败，若消费者失败也不能回滚前者的事务；具备必定的业务侵入性。

2）、TCC：

TCC是一种经典的2PC解决方案，也就是将整个事务控制过程分为Try、Confirm和Cancel阶段，经过Try阶段来对全部的参与者进行资源的检查与预留，若是Try阶段所有成功，那么就对全部参与者进行Confirm；若是Try阶段出现一者失败，那么就对全部参与者进行Cancel。

因为Try、Confirm、Cancel 3个方法均由业务编码实现，因此TCC是具有强业务侵入性的。

 

 

• 并发控制：在实现TCC时，应当考虑并发性问题，将锁的粒度降到最低，以最大限度提升分布式事务的并发性。
• 幂等性：因为网络可能出现数据包重传的状况，因此须要考虑Try、Confirm和Cancel这三个阶段的幂等性，也就是Try、Confirm、Cancel 执行一次和执行屡次的业务结果是同样的。

3）、Saga：

Saga事务核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，若是正常结束那就正常完成，若是某个步骤失败，则根据相反顺序一次调用补偿操做。

Saga事务基本协议以下：

• 每一个Saga事务由一系列幂等的有序子事务Ti组成。
• 每一个Ti都有对应的幂等补偿动做Ci，补偿动做用于撤销Ti形成的结果，补偿过程也被称为冲正过程。

 

 例如如今T一、T二、T3为扣减库存、建立订单、支付订单，若是在支付订单时失败了，那么就对原先的操做作回退，也就是补偿冲正：C3支付回滚、C2订单回滚、C1库存回滚，使得数据回到最开始的状态。

 

 能够将Saga的各事务作成服务编排，制订好每一个事务之间的调用顺序和回退顺序，这样能够将整个Saga事务的流程清晰化和规范化：

优缺点：

优势：实现简单，而且整个Saga事务的流程都十分地清晰，基于消息队列构建的Saga事务还能够避免单点问题。

缺点：具备业务侵入性，须要制订好每一个子事务失败后对应的回滚（冲正）操做。

能够看到，和TCC相比，Saga没有“预留”动做，它的Ti就是直接提交到库。

三、业务非侵入的解决方案：

1）、FMT：

FMT（Framework-managed transaction）即框架管理事务，是一种无侵入的事务解决方案。该模式下，分布式事务框架会托管全部的事务操做，事务的一阶段和二阶段操做均由框架自动生成。

FMT一阶段：拦截业务SQL语句，保存SQL执行前的快照，执行SQL，而且添加相应的行锁，避免出现并发冲突。

 

 FMT二阶段：执行其余业务SQL，若都成功，那么删除一阶段中产生的锁和快照；若其一失败，则重作快照，回滚数据，删除行锁。

 

 

优缺点

优势：整个事务处理过程由框架自动化完成，无需人工参与，无业务侵入性。

缺点：因为基于框架来对SQL、事务等进行拦截，因此会有性能损耗（譬如须要使用注解、反射、动态代理等机制）。

2）、XA：

XA模式是另一种无侵入的分布式事务解决方案，不一样于FMT的是，XA模式下，全部一阶段和二阶段都由数据库来完成，而不是由框架来完成。其原理与FMT类似，都是借助了快照来完成回退操做。

 

 

优缺点

优势：主流的数据库都实现了XA分布式事务方案，因此能够方便地实现。

缺点：严重依赖于数据库自身的规范和接口，不能高效拓展。

四、总结

 

 

分布式事务的解决基础是2PC和3PC协议。

2PC和3PC协议都划分出两个角色：事务发起者（事务管理器）和跟随者（资源管理器）。

2PC在第一阶段，事务管理器询问全部资源管理器准备是否成功（prepare）。若是全部资源均准备成功，那么在第二阶段事务管理器会要求全部资源管理器执行提交操做（commit）。若是任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求全部资源管理器在第二阶段执行回滚操做（rollback）。经过事务管理器的两阶段协调，最终全部资源管理器要么所有提交，要么所有回滚，最终状态都是一致的。

3PC相对于2PC来讲，增长了超时ACK判断以及在真正提交以前增长了预提交阶段（pre commit）来保证事务可以所有提交成功。

分布式事务的常看法决方案分为两大类，一类是业务侵入点、另外一类是业务非侵入的。

业务侵入的有MQ、TCC、Saga这三种解决方案。MQ的优势是实现简单而且不会存在单点问题，可是须要使用特定的MQ譬如RocketMQ中的Half Message才可以知足需求，而且消费者对于消息的消费是必定须要成功的；TCC是一种常用的方案，它的作法是将整个分布式事务拆分为三个部分：Try、Confirm和Cancel，在Try阶段进行资源的检查与预留，在第二阶段进行事务的统一Confirm和Cancel；Saga的作法是将长事务拆分红顺序执行的子事务，若是其中一个子事务执行失败，则须要继续相应的事务补偿、回滚和数据冲正。

非业务侵入的解决方案有FMT和XA两种选择，FMT的思路是由框架来对SQL进行拦截，而且保存以前的快照，在第二个阶段中若是所有事务都执行成功那么就删除以前的快照而且释放掉行锁，若是执行失败，那么会执行以前的快照。XA和FMT的作法是相似的，不过XA的两个阶段都由数据库自身来保证。

最后，其实每一种方案都有各自的优势与缺点，要结合自身业务的状况和系统的特性来选择具体的方案，选择性地牺牲某些方面以保证某些方面。

 

未完待续，后续会补充大数据相关的架构