springboot去中心化

『壹』 90 SpringCloud 解决分布式事务--lcn解决分布式事务

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理论

1.1 CAP定律#

这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

（一）一致性（C）

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

（二）可用性（A）

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

（三）分区容错性（P） 形成脑裂问题

以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

https://ke..com/item/%E5%AE%B9%E9%94%99%E7%8E%87/9967698?fr=aladdin

（四）总结一下

以上可以知道分区容错性（P）主要代表网络波动产生的错误，这是不可避免的，且这个三个模式不可兼得，所以目前就只有两种模式：CP和AP模式。

其中CP表示遵循一致性原则，但不能保证高可用性，其中zookeeper作为注册中心就是采用CP模式，因为zookeeper有过半节点不可以的话整个zookeeper将不可用。

AP表示遵循于可用性原则，例如Eureka作为注册中心用的是AP模式，因为其为去中心化，采用你中有我我中有你的相互注册方式，只要集群中有一个节点可以使用，整个eureka服务就是可用的，但可能会出现短暂的数据不一致问题。

AP保证可用性：但是不能保证每个副本数据数据一致性；

CP保证数据一致性：如果有过半的zk节点宕机的情况下，不能保证可用性，但是必须保证每个副本节点之间数据一致性， 比如ZK；

BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

（一）基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，注意，这绝不等价于系统不可用。

比如：响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒。

系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

（二）软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性， 即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时 。

（三）最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

目前主流分布式解决框架：
1，单体项目多数据源，可以jta+Atomikos
2,基于RabbitMQ的形式解决，最终一致性的思想。
3，基于RocketMQ解决分布式事务，采用事务消息。
4，LCn采用lcn模式，假关闭连接
5,Alibaba的Seata

6，跨语言的方式实现解决分布式事务问题，类似于支付宝回调。
俩阶段提交协议基本概念：
2阶段提交协议可以理解为2pc，也就是分为参与者和协调者，协调者会通过2次阶段实现数据最终一致性。
2pc和3pc的区别就是解决参与者超时的问题和多加了一层询问，保证数据的传输可靠性。

http://www.txlcn.org/zh-cn/ LCN并不生产事务，LCN只是本地事务的协调工

现在官网已经不维护呢，可以参考：GitEE

https://gitee.com/wangliang1991/tx-lcn?_from=gitee_search

默认密码为：codingapi
lcn基本实现处理：
1，发起方与参与方都与我们的lcn管理器一直保持长连接；
2，发起方在调用接口前，先向lcn管理器中申请一个全局的事务分组id.
3,发起方调用接口的时候在请求头中传递事务分组id
,4参与方获取到请求头中有事务分组的id的，则当前业务逻辑执行完实现假关闭，不会提交或者回滚事务‘
5，发起方调用完接口后，如果出现异常的情况下，在通知给事务回滚事务，这时候事务协调则告诉参与方回滚当前的事务。
lcn解决分布式事务的原理：
角色划分：
1，全局事务协调者（组长）；
2，发起方--调用接口者
3，参与方--被别人调用接口。
订单（发起方）调用派单（参与方）
1.发起方和参与方都会与我们的全局事务协调者保持长连接；

SpringBoot整合lcn5.0

Maven依赖

相关配置

参与方获取全局id
1.SpringTracingApplier
拦截器 获取feign客户端请求头中的参数全局事务分组id，缓存到threadlocal中。

『贰』 如何快速搭建一个微服务架构

什么是微服务？

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…

单体架构(Monolithic Architecture )

企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。

这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包

上图：单体架构

大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。

多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。

单体架构的应用一般有以下特点：

微服务架构（Microservices Architecture）

微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！

上图：微服务架构

微服务设计

那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：

微服务消息

在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。

同步消息 REST

同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）

异步消息 – AMQP, STOMP, MQTT

异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT 这三种通讯协议

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。

服务约定 – 定义接口 – Swagger, RAML, Thrift IDL

如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。

REST设计的微服务，通常采用Swagger和RAML定义约定。

对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。

微服务集成 (服务间通信)

大部分微服务基于RPC、HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。

点对点方式

点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。

上图：通过点对点方式通信

很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提升，会变得越来越不可维护。这点有些类似SOA的ESB，尽量不采用点对点的集成方式。

API-网关方式

API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

上图：通过API-网关暴露微服务

所有的业务接口通过API网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。

采用网关方式有如下优势：

目前，API网关方式应该是微服务架构中应用最广泛的设计模式。

消息代理方式

微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。

上图：异步通信方式

通常异步的生产者/消费者模式，通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。

数据的去中心化

单体架构中，不同功能的服务模块都把数据存储在某个中心数据库中。

每个微服务有自己私有的数据库，其它微服务不能直接访问。单体架构，用一个数据库存储所有数据

微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（比如，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。因此，每个微服务都应该有自己的数据库。

每个微服务有自己私有的数据库，其它微服务不能直接访问。每个微服务有自己私有的数据库，其它微服务不能直接访问。

数据去中心话的核心要点：

数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

微服务架构的优点：

微服务架构的缺点：

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

关于微服务架构的取舍

『叁』 如何理解中心化与去中心化概念

在一个分布有众多节点的系统中，每个节点都具有高度自治的特征。节点之间彼此可以自由连接，形成新的连接单元。任何一个节点都可能成为阶段性的中心，但不具备强制性的中心控制功能。节点与节点之间的影响，会通过网络而形成非线性因果关系。这种开放式、扁平化、平等性的系统现象或结构，我们称之为去中心化。

对于去中心化，很多人都有误解，甚至进入一个困局——去中心化就是不要中心。去中心化，不是不要中心，而是由节点来自由选择中心、自由决定中心。简单地说，中心化的意思，是中心决定节点。节点必须依赖中心，节点离开了中心就无法生存。在去中心化系统中，任何人都是一个节点，任何人也都可以成为一个中心。任何中心都不是永久的，而是阶段性的，任何中心对节点都不具有强制性。

 

举例说明

中心化：SOA ESB中心化服务架构；去中心化：Dubbo、Spring Cloud去中心化架构。

中心化：上课；去中心化：学术交流

中心化：看电影；去中心化：玩手机

其他看法

通俗地讲，中心化就是一个或几个认证的嘉宾在讲话，所有其他人还能参与听，类似于上课的模式。而去中心化就是每个人都可以讲话，都可以选择听还是选择讲，就像自由讨论模式。以前的门户网站是中心化，今天的博客，社交媒体都是去中心化。

当然在今天没有完全的中心化和去中心化，就像大家普遍认为淘宝京东是中心化平台，但它们的用户也可以通过社交渠道去分享发掘流量，淘宝有自己的“社区”，京东也有自己的“发现”，这些都是去中心化的形态