1，分布式事务产生的背景。
分情况而定
1， 在单体的项目中，多个不同的业务逻辑都是在同一个数据源中实现事务管理，是不存在分布式事务的问题，因为同一个数据源的情况都是采用事务管理器，相当于每个事务管理器对应一个数据源。
[上传失败(image-810669-1618491127348)]
2，在单体的项目中，有多个不同的数据源，每个数据源都有自己独立的事务管理器，互不影响，那么这时候也会存在多数据源事务管理： 解决方案 jta+Atomikos
[上传失败(image-7df061-1618491220423)]
3，在分布式/微服务架构中，每个服务都有自己的本地事务，每个服务本地事务互不影响，那么这时候也会存在分布式事务的问题。
事务的定义：
对我们的业务逻辑可以实现提交或者回滚，保证数据的一致性的情况。
所以要么提交，要么回滚
原子性a 要么提交 要么回滚
一致性c
隔离性i 多个事务在一起执行的时候，互不影响；
持久性d 事务一旦提交或者回滚后，不会在对该结果有任何影响
2，传统分布式事务解决方案
3，2PC/3PC协议使用场景。
4，LCN为什么不更新了？那些思想值得学习、
5，分布式事务解决方案有哪些？
6，强一致性/最终一致性区别。
7，LCn深度源码解读。
1 CAP定律和BASE理论
11 CAP定律#
这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
（一）一致性（C）
在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
（二）可用性（A）
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
（三）分区容错性（P） 形成脑裂问题
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前 *** 作在C和A之间做出选择。
>在正式学习如何搭建微服务架构之前，我们先来了解一下微服务架构中涉及的一些常见组件名称及其作用。
·服务注册中心：注册系统中所有服务的地方。
服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
·服务发现：服务调用方从服务注册中心找到自己需要调用服务的地址。
·负载均衡：服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点。
·服务容错：通过断路器（也称熔断器）等一系列的服务保护机制，保证服务调用者在调用异常服务时快速地返回结果，避免大量的同步等待。
·服务网关：也称为API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。
分布式配置中心：将本地化的配置信息（properties、yml、yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
什么场景下适用微服务？什么阶段时适用微服务？
设计的微服务系统的组织，其产生的架构设计应等价于组织间的沟通结构。
这句话的意思是说，原始组织之间的结构最好能映射到设计的微服务系统架构上。比如一个系统包含订单、商品、用户等功能，现实中分别由A、B、C三个小组进行开发维护，那么如果要拆分为微服务的架构，最好就能拆分为订单服务、商品服务、用户服务三个微服务，对应A、B、C三个现实的小组结构。
微服务并不是适合任何阶段，最好的方式就是随着项目的扩大或者团队的扩大时，逐步演进到微服务。因为单体应用会随着规模的扩大而逐渐增加内耗，导致生产力降低。微服务的目标是在规模扩大时，使得生产力能维持在一个稳定的水准之上。
微服务生产力超过单体的拐点，一般来说是指当团队人数规模达到百人时。当然，这也不是绝对的，需要团队负责人自己视情况进行评估。
如果在项目一开始就设计微服务的架构，一路上会遇到极大的困难与风险。比如业务模块边界的划分、无法预估的业务或者技术复杂性，这些都会耗费更多的人力和时间，甚至最终导致项目失败。
建议的方式就是由单体演进，我们可以在单体阶段不断摸索和沉淀业务和技术上的问题，随着越来越清晰的认知，再加上日渐增加的复杂度，可以考虑逐步拆分部分服务出来，朝着微服务架构的方向演进。
微服务架构中服务与服务各有不同，相互之间也应该按照层级的方式进行编排。有的与业务无关的服务天然属于底层基础服务，有的与业务有关联的服务则属于聚合了基础服务的聚合服务。
在常见的公司微服务总体架构中，一般的架构表现就如下所示：
有了各个层级的服务之后，中台的概念和战略就显得很自然。
服务注册与发现是微服务架构得以运转的核心功能，它不提供任何业务功能，仅仅用来进行服务的发现和注册，并对服务的健康状态进行监控和管理。其核心的工作原理：
现在注册中心比较多，主流的有Eureka、Consul、Zookeeper、Nacos等。
网关是整个系统对外暴露的唯一入口，它封装了系统内的所有微服务，对外看来，别人只知道也只能通过网关才可以和系统进行交互。网关对所有请求进行非业务功能的处理，然后再将请求发送给内部指定的微服务进行业务上的处理。总的来说，网关最主要的功能如下：
现在常见的网关有Kong、Zuul、Spring Cloud Gateway等；
在实际应用中，一个微服务体系架构的系统可以有多个网关用来应对不同的使用场景，比如公司内网网关、外网网关、提供给第三方调用的网关等；
微服务在启动和运行的过程中，经常会需要读取一些配置信息，这些配置信息拥有如下的特点：
如上这些特点和需求，催生了配置中心的出现。现在主流的配置中心有Spring Cloud Config、Nacos、Apollo等；
在微服务架构中，一次调用请求可能贯穿多个服务，这些服务可能是由不同的团队使用不同的技术开发而成的，如果出现调用失败需要排查问题时，如何能快速地复现调用现场，发现问题出在哪个服务哪个服务器上就成了全链路监控需要解决的问题。
全链路监控的基本原理都是：
全链路监控主流工具有CAT、Zipkin、Pinpoint、Skywalking等；
在微服务架构体系中，服务之间的调用是很频繁的，一旦某些服务出现故障或者高延迟，会很可能造成级联故障，如果客户端还在不停重试，将会加剧问题的严重性，最终导致整个系统彻底崩溃。
断路器的设计与实现有助于防止多服务之间的级联故障，允许我们构建具有容错性和高d性的微服务架构系统，当某些服务不可用时，提供服务熔断和服务降级功能，保证系统的其它部分仍能正常运行。
断路器的三个状态和含义如下：
主流常见的断路器有Hystrix、Sentinel等；
如果使用了容器技术，那么容器编排、发布、治理就成了避不开的话题。主流的技术如下：
各大容器云厂商基本都是使用基于k8s的容器治理方案，k8s也已经成为该领域事实上的标准了。
如上是自己在极客时间App上学习《微服务架构核心20讲》的笔记，该课程一天就能学完，没有实现微服务的细节，是高屋建瓴地讲解微服务架构的蓝图，带你鸟瞰整个微服务架构，推荐学习。本篇文章为NETCore实现企业级微服务架构技术点介绍
Consul是一个分布式，高可用、支持多数据中心的服务注册、发现、健康检查和配置共享的服务软件。
由 HashiCorp 公司用 Go 语言开发 推出的开源产品
用于实现分布式系统的服务发现、服务隔离、服务配置。
这些功能中的每一个都可以根据需要单独使用，也可以同时使用所有功能。Consul 官网目前主要推 Consul 在服务网格中的使用。
与其它分布式服务注册与发现的方案相比：
Consul 的方案更“一站式”——内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具。
Consul 本身使用 go 语言开发，具有跨平台、运行高效等特点，也非常方便和 Docker 配合使用。
与市面上其他系统比较如下：
使用Consul 的优势
使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接。相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft。
支持多数据中心，内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障，而其部署则需要考虑网络延迟, 分片等情况等。zookeeper 和 etcd 均不提供多数据中心功能的支持。
支持健康检查。etcd 不提供此功能。
支持 >ThingsBoard设计为：
扩展性：可水平扩展的平台使用领先的开源技术构建。
容错性：没有单点故障集群中的每个节点都是相同的。
健壮性：单个服务器节点可以根据使用情况处理以万级别的设备，集群可以处理数百万级别设备。
自定义：使用可自定义的部件和规则引擎节点可以轻松添加新功能。
持久化：永远不会丢失你的数据。
参见如下架构图及关键组件和相关接口。
通信
ThingsBoard提供了基于MQTT、>
微服务架构开发在软件编程开发领域中是一种非常常见的软件开发方式了，而今天我们就一起来了解一下，基于微服务架构的系统软件在运行过程中都有哪些问题会发生。
一：Hystrix是什么11:基本解释Hystrix开始由Netflix(看过美剧的都知道,它是一个美剧影视制作的巨头公司)开源的，后来由SpringCloudHystrix基于这款框架实现了断路器、线程隔离等一系列服务保护功能,该框架的目标在于通过控制访问远程系统、服务和三方库的节点，从而延迟和故障提供更强大的容错能力。
hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。
起到了微服务的保护机制,防止某个单元出现故障从而引起依赖关系引发故障的蔓延，终导致整个系统的瘫痪。
12:断路器的概念断路器本身是一个开关装置，用在电路上保护线路过载，当线路中有电器发生短路的时候。
“断路器”能够及时切断故障，防止发生过载、发热甚至起火等严重后果。
当分布式架构中，断路器模式起到的作用也是类似的。
当某个服务发生故障的时候，通过断路器的故障监控向调用方返回一个错误响应，而不是长时间的线程挂机，无限等待。
这样就不会使线程因故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
二：Hystrix解决超时问题21：问题假设我们前端提供了用户查询订单的功能，先请求映射到OrderController，控制器通过调用服务orderService获取订单信息，前端传过来两个参数：一个是订单id,一个是用户id,orderService需要通过用户id调取用户服务来获取用户的相关信息返回给订单服务去组装信息，假设这里是通过>
分布式系统架构中，分布式事务问题是一个绕不过去的挑战。而微服务架构的流行，让分布式事问题日益突出！
下面我们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！
如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都做了分布式系统架构拆分，按上数中的流程步骤进行分析：
1、电商平台中创建订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，因为此时已经要跨多个内部服务修改数据；
2、支付平台中创建支付订单（选yhk支付）：查询账户、查询限制规则，符合条件的就创建支付订单并跳转银行，此时不会有分布式事务问题，因为还不会跨服务改数据；
3、银行平台中创建交易订单：查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台，此时也会有分布式事务问题（如果是服务化架构的话）；
4、支付平台收到银行扣款结果：更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；
5、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等，系统内部各服务间调用也会遇到分布式事问题；
如上图，支付平台收到银行扣款结果后的内部处理流程：
1、支付平台的支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理；
2、支付订单服务根据银行扣款结果更改支付订单状态；
3、调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种的成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）；
4、调用积分服务给用户积分账户增加积分；
5、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；
6、调用通知服务将支付处理结果通知电商平台；
如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：
/ 支付订单处理 /
@Transactional(rollbackFor = Exceptionclass)
public void completeOrder() {
orderDaoupdate(); // 订单服务本地更新订单状态
accountServiceupdate(); // 调用资金账户服务给资金帐户加款
pointServiceupdate(); // 调用积分服务给积分帐户增加积分
accountingServiceinsert(); // 调用会计服务向会计系统写入会计原始凭证
merchantNotifyServicenotify(); // 调用商户通知服务向商户发送支付结果通知
}
本地事务控制还可行吗？
以上分布式事务问题，需要多种分布式事务解决方案来进行处理。
订单处理：本地事务
资金账户加款、积分账户增加积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。
会计记账：异步确保型事务（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）
商户通知：最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询 *** 作接口进行核对）
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）