微服务中服务保护和分布式事务

1.微服务保护

在微服务远程调用的过程中，还存在几个问题需要解决。
业务健壮性,级联失败(雪崩)问题…

1.1.服务保护方案

• 请求限流
• 线程隔离
• 服务熔断

1.2 高并发性能指标

1.2.1 QPS——每秒查询

QPS：Queries Per Second是衡量信息检索系统（例如搜索引擎或数据库）在一秒钟内接收到的搜索流量的一种常见度量。该术语在任何请求-响应系统中都得到更广泛的使用，更正确地称为每秒请求数（RPS：Request Per Second）。
高性能、高并发、高可用（简称“三高”）要求的系统必须注意其QPS，才能知道何时扩容系统以处理更多请求。

1.2.2 TPS——每秒事务

TPS：是Transactions Per Second的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户端向服务器发送请求然后服务器做出响应的过程。客户端在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
QPS vs TPS：QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。如，访问一个页面会请求服务器2次，一次访问，产生一个“T”，产生2个“Q”。

1.2.3 RT——响应时间

RT（Response-time）响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间，即从客户端发起请求到收到服务器响应结果的时间。该请求可以是任何东西，从内存获取，磁盘IO，复杂的数据库查询或加载完整的网页。
暂时忽略传输时间，响应时间是处理时间和等待时间的总和。处理时间是完成请求要求的工作所需的时间，等待时间是请求在被处理之前必须在队列中等待的时间。
响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。

1.2.4 Concurrency——并发数

并发数是指系统同时能处理的请求数量，这个也反应了系统的负载能力。
并发意味着可以同时进行多个处理。并发在现代编程中无处不在，网络中有多台计算机同时存在，一台计算机上同时运行着多个应用程序。

1.2.5 吞吐量

系统的吞吐量（承压能力）和处理对CPU的消耗、外部接口、IO等因素紧密关联。单个处理请求对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量有几个重要指标参数：QPS（TPS）、并发数、响应时间。

1. QPS（TPS）：（Queries Per Second）每秒钟请求/事务数量。
2. 并发数： 系统同时处理的请求/事务数。
3. 响应时间： 一般取平均响应时间。
   理解了上面三个指标的意义之后，就能推算出它们之间的关系：

• QPS（TPS）= 并发数/平均响应时间
• 并发数 = QPS*平均响应时间

1.3 Sentinel

Sentinel是阿里巴巴开源的一款服务保护框架，目前已经加入SpringCloudAlibaba中。

2.分布式事务

ACID属性：为保证事务(transaction)是正确可靠的,所必须具备的四个特性:原子性(atomicity,或称不可分割性)、一致性(consistency)、隔离性(isolation,又称独立性)、持久性(durability)。

我们知道每一个分支事务就是传统的单体事务，都可以满足ACID特性，但全局事务跨越多个服务、多个数据库，是否还能满足呢？

参与事务的多个子业务在不同的微服务，跨越了不同的数据库。虽然每个单独的业务都能在本地遵循ACID，但是它们互相之间没有感知，不知道有人失败了，无法保证最终结果的统一，也就无法遵循ACID的事务特性了。

这就是分布式事务问题，出现以下情况之一就可能产生分布式事务问题：

• 业务跨多个服务实现
• 业务跨多个数据源实现
  接下来研究下如何解决分布式事务问题

2.1.Seata

解决分布式事务的方案有很多，但实现起来都比较复杂，因此我们一般会使用开源的框架来解决分布式事务问题。在众多的开源分布式事务框架中，功能最完善、使用最多的就是阿里巴巴在2019年开源的Seata了。
其实分布式事务产生的一个重要原因，就是参与事务的多个分支事务互相无感知，不知道彼此的执行状态。因此解决分布式事务的思想非常简单：
就是找一个统一的事务协调者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败即可。大多数的分布式事务框架都是基于这个理论来实现的。
Seata也不例外，在Seata的事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
• TM (Transaction Manager) - **事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
• RM (Resource Manager) - **资源管理器：**管理分支事务，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

其中，TM和RM可以理解为Seata的客户端部分，引入到参与事务的微服务依赖中即可。将来TM和RM就会协助微服务，实现本地分支事务与TC之间交互，实现事务的提交或回滚。

而TC服务则是事务协调中心，是一个独立的微服务，需要单独部署。

2.1.1 XA模式

Seata支持四种不同的分布式事务解决方案：

• XA
• TCC
• AT
• SAGA
  XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

两阶段提交

A是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

正常情况：

异常情况：

一阶段：

• 事务协调者通知每个事务参与者执行本地事务
• 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁
  二阶段：
• 事务协调者基于一阶段的报告来判断下一步操作
• 如果一阶段都成功，则通知所有事务参与者，提交事务
• 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

RM一阶段的工作：

1. 注册分支事务到TC
2. 执行分支业务sql但不提交
3. 报告执行状态到TC
TC二阶段的工作：
4. TC检测各分支事务执行状态
   • 如果都成功，通知所有RM提交事务
   • 如果有失败，通知所有RM回滚事务
     RM二阶段的工作：

• 接收TC指令，提交或回滚事务

优缺点

XA模式的优点是什么？

• 事务的强一致性，满足ACID原则
• 常用数据库都支持，实现简单，并且没有代码侵入
  XA模式的缺点是什么？
• 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
• 依赖关系型数据库实现事务

2.2.2 AT模式

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

Seata的AT模型

基本流程图：

阶段一RM的工作：

• 注册分支事务
• 记录undo-log（数据快照）
• 执行业务sql并提交
• 报告事务状态
  阶段二提交时RM的工作：
• 删除undo-log即可
  阶段二回滚时RM的工作：
• 根据undo-log恢复数据到更新前

AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
• XA模式强一致；AT模式最终一致
  相比较下，AT模式使用起来更加简单，无业务侵入，性能更好。因此企业90%的分布式事务都可以用AT模式来解决。