分布式微服务

1. 什么是微服务

• 一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
• 每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。
• 每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

特征：

• 有自己的堆栈，包括数据库和数据模型；
• 通过REST API，事件流和消息代理的组合相互通信；
• 它们是按业务能力组织的，分隔服务的线通常称为有界上下文。

2. 分布式事务解决方案

• XA 方案
• TCC 方案
• 本地消息表
• 可靠消息最终一致性方案
• 最大努力通知方案

2.1 XA方案

所谓的 XA 方案，即：两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。

缺陷：严重依赖于数据库层面来搞定复杂的事务，效率很低，不适合高并发的场景。

2.2 TCC 方案

TCC 的全称是：Try、Confirm、Cancel。事务补偿机制。

• Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。
• Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。
• Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）
  

缺陷：事务回滚严重依赖于你自己写代码来回滚和补偿。

2.3 本地消息表

• A 系统在自己本地一个事务里操作同时，插入一条数据到消息表；
• 接着 A 系统将这个消息发送到 MQ 中去；
• B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息；
• B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；
• 如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；
• 这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。
  

缺陷：严重依赖于数据库的消息表来管理事务，不利于扩展和高并发场景。

2.4 MQ可靠消息最终一致性方案

不要用本地的消息表了，直接基于 MQ 来实现事务。

• A 系统先确认MQ正常；
• A 系统执行本地事务，如果成功则发送MQ消息；
• B 系统会接收到消息，然后执行本地的事务；
• 如果B系统执行失败，则重试，重试多次失败则发送报警由人工来手工回滚和补偿
  

2.5 最大努力通知方案

• 最大努力通知方案是对MQ事务方案的进一步优化。它在事务主动方增加了消息校对的接口，如果事务被动方没有接收到消息，此时可以调用事务主动方提供的消息校对的接口主动获取。

其适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口。

3 分布式定时任务解决方案

把分散的，可靠性差的计划任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式，就叫做分布式定时任务。

它有两层含义：

• 它是运行在分布式集群环境下的调度任务，同⼀个定时任务程序部署多份，则同一时刻应当只允许⼀个定时任务执行。
• 定时任务的拆分，就是把⼀个大的作业任务拆分为多个小的作业任务，同时执行。

3.1 quartz

• Job：表示一个工作，要执行的具体内容。此接口中只有一个方法void execute(JobExecutionContext context)

• JobDetail：表示一个具体的可执行的调度程序，Job是这个可执行程调度程序所要执行的内容，另外JobDetail还包含了这个任务调度的方案和策略。

• Trigger代表一个调度参数的配置，什么时候去调用。

• Scheduler代表一个调度容器，一个调度容器中可以注册多个JobDetail和Trigger。当Trigger与JobDetail组合，就可以被Scheduler容器调度了。

缺点：

• 同一个任务只能有一个节点运行，其他节点将不执行任务，性能低，资源浪费；
• 当碰到大量短任务时，各个节点频繁的竞争数据库锁，节点越多这种情况越严重，造成性能会很低下；
• quartz 的分布式仅解决了集群高可用的问题，并没有解决任务分片的问题，不能实现水平扩展，还是会有单机处理的极限。

3.2 elastic-job

elastic-job 是由当当网基于quartz 二次开发之后的分布式调度解决方案 ， 由两个相对独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成 。

• Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。
• Elastic-Job-Cloud使用Mesos + Docker(TBD)的解决方案，额外提供资源治理、应用分发以及进程隔离等服务。

特点：

• 定时任务 ：基于成熟的定时任务作业框架Quartz cron表达式执行定时任务；
• 作业注册中心 ：基于Zookeeper实现全局作业注册控制中心。用于注册，控制和协调分布式作业执行。
• 作业分片 ：将要给任务分片成多个小任务项到多服务器上同时执行；
• 弹性扩容缩容 ：运行中的作业服务器崩溃，或新增N台作业服务器，作业框架将在下次作业执行前重新分片，不影响当前作业执行；

调度原理：

3.3 xxl-job

• 调度中心：一个用于发布任务的中心，可以控制任务启动和停止，已经维护监控注册和日志。
• 执行器：用于执行任务的客户端，调度中心会根据注册执行器，按照算法分配任务执行。执行器有一个appName，与调度中心的执行器管理的appName对应，名称一致才会分配任务。
• 任务：设置任务、执行策略、分片机制、执行器等属性，其中执行器与执行器管理中选择一个执行器名称，这样就可以分配到对应appName的执行器。

调度原理：
1、“调度中心”向“执行器”发送http调度请求: “执行器”中接收请求的服务，实际上是一台内嵌Server，默认端口9999;
2、“执行器”执行任务逻辑；
3、“执行器”http回调“调度中心”调度结果: “调度中心”中接收回调的服务，是针对执行器开放一套API服务;

分片原理：
执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；

3.4 分布式事务方案对比