springCloud去中心化机制

发布时间: 2023-01-25 15:50:00

1. 闲聊注册中心——ZK、Eureka、Sofa-Registry

最开始服务之间的调用借助的是域名，域名其实是个好东西，使用起来很方便，但所有调用请求都得走域名解析和负载均衡，相对来说性能就差一点，而且这些夹在中间的零部件会演变成性能瓶颈和潜在的单点风险，后来大家一比较发现还不如直接端到端调用，那么就需要一个东西把调用链的两端连起来，这就是注册中心。

注册中心提供服务的注册发现，用来连接调用链路的 Provider 和 Consumer 这两个端点。一个注册中心得管理好服务的扩缩容、故障转移、流量分配这类的核心功能，自身同样需要高可用，妥善解决跨地域部署情况下注册中心节点之间的数据一致性，因此我更倾向于认为注册中心是一个偏向体系化的产品，它的价值依赖于与之相匹配的服务规模和治理体系，它的思想虽然产生得很早，但是规模化地落地并不容易，偏小的服务规模本身对于注册中心的依赖并不明显，实现的手段也没有定式；大型服务又会对注册中心的定位、功能提出更苛刻的需求。

究竟是选择强一致性还是高可用性，当下的主流技术选型倾向于后者，但这并不是说明 CP 组件没有存在的意义，而是 AP 组件更契合互联网对于注册中心的定位。

互联网系统高可用永远是摆在首位的东西，因为系统不可用的时间通常跟财产损失直接挂钩。服务列表在短时间少了一两个节点、多了一两个节点，这点流量倾斜对于大多数服务来说感知并不明显，只需要注册中心在某个短暂的时间窗口内重新达到一致性的状态就可以，注册中心不应该在运行时影响到处于正常调用的两个端点之间的连通性。

CP 的代表就是 zookeeper ，至今 zookeeper 也是非常流行的用于注册中心的组件，这在一定程度上要感谢 bbo 。 bbo 在 zookeeper 中是用一个树形结构的两个节点，分别维护服务的 Provider 和 Comsumer 的，列表注册在这两个节点下面，服务的健康检查依赖 zookeeper 提供的临时节点特性，实际上跟 session 的生命周期绑定在一起，但临时节点的问题就是数据易失，一旦集群故障节点重启丢失服务列表，可能造成服务大面积瘫痪，电商新贵 PDD 就曾经出现过这个问题。

CP 最关键的问题在于无法支持机房容灾，例如 ABC 三个机房，机房 C 和其他两个机房产生了网络隔离，部署在机房 C 的 zookeeper 节点是无法提供写入的，这意味着机房 C 部署的 Provider 不能扩缩容、不能重启，最好在故障期间一直保持原样，否则 Provider 任何操作都会是高危的，会直接影响到部署在机房 C 的 Comsumer 。

顺带说一句，我认为 zookeeper 真挺好的，它本身的定位就是个分布式协调服务，并不是专门为注册中心设计的，你不能拿评价注册中心的眼光去评价它，你要的功能 zookeeper 基本上都有，借助 Curator 拿来就可以用，提供了 election ，提供了 ZAB ， TPS 低了点（其实也可以了）但是也满足大部分服务规模。

Eureka —— 奈飞的网红组件， AP 注册中心的代表。 Eureka 1.x 今天回头看来是个很牵强的实现，因为它的架构从诞生之日起，就意味着将来数据规模增长之后大概率会出问题，集群整体可伸缩性很低，每扩容一台 Eureka 节点意味着整体点对点之间需要多一份数据流，而这种 Peer 点对点机制的数据流很容易打满网卡，造成服务端压力。根据公开的资料， Eureka 在实例规模五千左右时就会出现明显的性能瓶颈，甚至是服务不可用的情况。

但是从另一个方面来说， Eureka 的架构清晰、运维部署都很方便，而且 Eureka 作为 SpringCloud 推荐的注册中心实现，国内用户数目也相当可观，可见在服务规模恰当的情况下其性能并没有问题，从携程的分享资料也可以看出，其内部的注册中心也是类似于 Eureka 的实现，可见没有绝对完美的架构设计，适合自己、满足业务需求才是最主要的。

Eureka 服务端多节点架构其实有点去中心化的意思，有意保持了每个节点的无状态特性，但是代价就是每个节点都持有全量数据，新增的数据可以往任意一个节点写入，然后由这个节点向其他节点广播，最终达到一致性。

数据都没有持久化，仅保存在内存中，带来了更好的读写性能、更短的响应时间，但是无法处理数据瓶颈，大节点扩容造成的数据同步存在打满网卡的风险，这点跟 redis 集群很像。客户端 30s 定期上报心跳、客户端缓存服务列表这些都没什么好谈的， Eureka 有个很有意思的点是，它的集群节点实现了一个自我保护机制，用来预测到底是集群出问题还是客户端出问题，实现很简单但是思想挺实用的。

Eureka 2.0 的设计文档上体现了读写分离集群的思想，本质上是为了提升集群性能和容量，但是非常遗憾，目前 2.0 的状态是 Discontinued ，短时间应该不会有成熟的产品出现。

虽然没有 Eureka 2.0 ，但是可以从蚂蚁开源的 Sofa-Registry 中了解类似思想的实现，Sofa-Registry 脱胎于阿里的 ConfigServer ，从公开的资料显示，国内阿里应该是最早做注册中心读写分离实践的。

这种架构带来的直接好处就是可以支持海量数据，第一层的 session 集群可以无限水平扩展，彼此之间完全不需要通信， session 集群在内存中维护了注册中心需要的一切拓扑关系，客户端仅仅连接一部分 session 集群中的机器，如果某台 session 机器挂了客户端会选择另一台重连；背后的 data 集群则通过分片存储所有的源数据，分片之间通过主从副本保证高可用，再将源数据推送到 session 集群保存下来，供客户端读取。

缺点也很明显，这种架构人力投入、运维成本肯定高于 Eureka 。

这几乎是注册中心不可避免的问题，高可用、机房容灾、网络延迟等都会催生出要求注册中心节点能够跨地域部署，这会引申出另一个问题就是如何做数据同步。

这种情况下已经不可能通过客户端注册或者是集群节点数据流复制来保证异地注册中心集群之间的数据一致，而是会研发单独的数据同步组件，通过跨地域专线实现地域间注册中心的数据同步，如果专线断开，此时各自地域的注册中心依旧可以独立服务于本地域内服务的调用，等到专线恢复，二者的数据继续进行同步合并纠正，最终达到一致性。对这个知识点感兴趣的可以了解下 Nacos-Sync 组件，是 Nacos 项目专门推出的开源数据同步服务。

文章略过了一些注册中心通用的概念，例如数据模型的分层、服务列表本地缓存、健康检查的方式、推拉权衡等，我认为叙述这些细节的意义并不大。

很多时候，理解某个组件我认为最重要的是理清它的架构演进过程，这是宝贵的经验财富，你可以抓住并学习每次架构演进的方向和原因。

2. 深入理解Spring Cloud Security OAuth2及JWT

OAuth2是一个关于授权的开放标准，核心思路是通过各类认证手段（具体什么手段OAuth2不关心）认证用户身份，并颁发token（令牌），使得第三方应用可以使用该令牌在 限定时间 、 限定范围 访问指定资源。主要涉及的RFC规范有 RFC6749 （整体授权框架）, RFC6750 （令牌使用）, RFC6819 （威胁模型）这几个，一般我们需要了解的就是 RFC6749 。获取令牌的方式主要有四种，分别是授权码模式，简单模式，密码模式和客户端模式，如何获取token不在本篇文章的讨论范围，我们这里假定客户端已经通过某种方式获取到了access_token，想了解具体的oauth2授权步骤可以移步阮一峰老师的理解OAuth 2.0 ，里面有非常详细的说明。

这里要先明确几个OAuth2中的几个重要概念：

明确概念后，就可以看OAuth2的协议握手流程，摘自RFC6749

Spring Security是一套安全框架，可以基于RBAC（基于角色的权限控制）对用户的访问权限进行控制，核心思想是通过一系列的filter chain来进行拦截过滤，以下是ss中默认的内置过滤器列表，当然你也可以通过 custom-filter 来自定义扩展filter chain列表

这里面最核心的就是 FILTER_SECURITY_INTERCEPTOR ，通过来进行资源权限的匹配， AccessDecisionManager 来执行访问策略。

一般意义来说的应用访问安全性，都是围绕认证（Authentication）和授权（Authorization）这两个核心概念来展开的。即首先需要确定用户身份，在确定这个用户是否有访问指定资源的权限。认证这块的解决方案很多，主流的有 CAS 、 SAML2 、 OAUTH2 等（不巧这几个都用过-_-），我们常说的单点登录方案（SSO）说的就是这块，授权的话主流的就是spring security和shiro。shiro我没用过，据说是比较轻量级，相比较而言spring security确实架构比较复杂。

将OAuth2和Spring Security集成，就可以得到一套完整的安全解决方案。

为了便于理解，现在假设有一个名叫“脸盆网”的社交网站，用户在首次登陆时会要求导入用户在facebook的好友列表，以便于快速建立社交关系。具体的授权流程如下：

不难看出，这个假设的场景中，脸盆网就是第三方应用（client），而facebook既充当了认证服务器，又充当了资源服务器。这个流程里面有几个比较重要的关键点，我需要重点说一下，而这也是其他的涉及spring security与OAuth2整合的文章中很少提及的，很容易云里雾里的地方。

细心的同学应该发现了，其实在标准的OAuth2授权过程中，5、6、8这几步都不是必须的，从上面贴的 RFC6749 规范来看，只要有1、2、3、4、7这几步，就完成了被保护资源访问的整个过程。事实上， RFC6749 协议规范本身也并不关心用户身份的部分，它只关心token如何颁发，如何续签，如何用token访问被保护资源（facebook只要保证返回给脸盆网的就是当前用户的好友，至于当前用户是谁脸盆网不需要关心）。那为什么spring security还要做5、6这两步呢？这是因为spring security是一套完整的安全框架，它必须关心用户身份！在实际的使用场景中，OAuth2一般不仅仅用来进行被保护资源的访问，还会被用来做单点登陆（SSO）。在SSO的场景中，用户身份无疑就是核心，而token本身是不携带用户信息的，这样client就没法知道认证服务器发的token到底对应的是哪个用户。设想一下这个场景，脸盆网不想自建用户体系了，想直接用facebook的用户体系，facebook的用户和脸盆网的用户一一对应（其实在很多中小网站现在都是这种模式，可以选择使用微信、QQ、微博等网站的用户直接登陆），这种情况下，脸盆网在通过OAuth2的认证后，就希望拿到用户信息了。所以现在一般主流的OAuth2认证实现，都会预留一个用户信息获取接口，就是上面提到的 https://api.facebook.com/user (虽然这不是OAuth2授权流程中必须的)，这样client在拿到token后，就可以携带token通过这个接口获取用户信息，完成SSO的整个过程。另外从用户体验的角度来说，如果获取不到用户信息，则意味者每次要从脸盆网访问facebook的资源，都需要重定向一次进行认证，用户体验也不好。

首先要明确一点， OAuth2并不是一个SSO框架，但可以实现SSO功能 。以下是一个使用github作为OAuth2认证服务器的配置文件

可以看到 accessTokenUri 和 userAuthorizationUri 都是为了完成OAuth2的授权流程所必须的配置，而 userInfoUri 则是spring security框架为了完成SSO所必须要的。所以总结一下就是： 通过将用户信息这个资源设置为被保护资源，可以使用OAuth2技术实现单点登陆（SSO），而Spring Security OAuth2就是这种OAuth2 SSO方案的一个实现。

Spring Security在调用user接口成功后，会构造一个 OAuth2Authentication 对象，这个对象是我们通常使用的对象的一个超集，里面封装了一个标准的，同时在 detail 中还携带了OAuth2认证中需要用到的一些关键信息（比如 tokenValue ， tokenType 等），这时候就完成了SSO的登陆认证过程。后续用户如果再想访问被保护资源，spring security只需要从principal中取出这个用户的token，再去访问资源服务器就行了，而不需要每次进行用户授权。这里要注意的一点是此时浏览器与client之间仍然是通过传统的cookie-session机制来保持会话，而非通过token。实际上在SSO的过程中，使用到token访问的只有client与resource server之间获取user信息那一次，token的信息是保存在client的session中的，而不是在用户本地。这也是之前我没搞清楚的地方，以为浏览器和client之间也是使用token，绕了不少弯路，对于Spring Security来说， 不管是用cas、saml2还是Oauth2来实现SSO，最后和用户建立会话保持的方式都是一样的 。

根据前面所说，大家不难看出，OAuth2的SSO方案和CAS、SAML2这样的纯SSO框架是有本质区别的。在CAS和SAML2中，没有资源服务器的概念，只有认证客户端（需要验证客户信息的应用）和认证服务器（提供认证服务的应用）的概念。在CAS中这叫做 cas-client 和 cas-server ，SAML2中这叫做 Service Providers 和 Identity Provider ，可以看出CAS、SAML2规范天生就是为SSO设计的，在报文结构上都考虑到了用户信息的问题（SAML2规范甚至还带了权限信息），而OAuth2本身不是专门为SSO设计的，主要是为了解决资源第三方授权访问的问题，所以在用户信息方面，还需要额外提供一个接口。

脸盆网的这个例子中，我们看到资源服务器和认证服务器是在一起的（都是facebook），在互联网场景下一般你很难找到一个独立的、权威的、第三方的认证中心（你很难想像腾讯的QQ空间通过支付宝的认证中心去授权，也很难想像使用谷歌服务要通过亚马逊去授权）。但是如果是在公司内部，这种场景其实是很多的，尤其在微服务架构下，有大量服务会对外提供资源访问，他们都需要做权限控制。那么最合理的当然就是建立一个统一的认证中心，而不是每个服务都做一个认证中心。我们前面也介绍了，token本身是不携带用户信息的，在分离后resouce server在收到请求后，如何检验token的真实性？又如何从token中获取对应的用户信息？这部分的介绍网上其实非常少，幸好我们可以直接从官方文档获取相关的蛛丝马迹，官方文档对于resouce server的配置是这样描述的：

寥寥数语，但已经足够我们分析了。从这个配置可以看出，client在访问resource server的被保护资源时，如果没有携带token，则资源服务器直接返回一个401未认证的错误

如果携带了token，则资源服务器会使用这个token向认证服务器发起一个用户查询的请求，若token错误或已经失效，则会返回

若token验证成功，则认证服务器向资源服务器返回对应的用户信息，此时resource server的spring security安全框架就可以按照标准的授权流程进行访问权限控制了。

从这个流程中我们可以看出，通过OAuth2进行SSO认证，有一个好处是做到了 认证与授权的解耦 。从日常的使用场景来说，认证比较容易做到统一和抽象，毕竟你就是你，走到哪里都是你，但是你在不同系统里面的角色，却可能千差万别（家里你是父亲，单位里你是员工，父母那里你是子女）。同时角色的设计，又是和资源服务器的设计强相关的。从前面的配置中不难发现，如果希望获得为不同资源服务器设计的角色，你只需要替换 https://api.facebook.com/user 这个配置就行了，这为我们的权限控制带来了更大的灵活性，而这是传统的比如SAML2这样的SSO框架做不到的。

终于来到了著名的JWT部分了，JWT全称为Json Web Token，最近随着微服务架构的流行而越来越火，号称新一代的认证技术。今天我们就来看一下，jwt的本质到底是什么。

我们先来看一下OAuth2的token技术有没有什么痛点，相信从之前的介绍中你也发现了，token技术最大的问题是 不携带用户信息 ，且资源服务器无法进行本地验证，每次对于资源的访问，资源服务器都需要向认证服务器发起请求，一是验证token的有效性，二是获取token对应的用户信息。如果有大量的此类请求，无疑处理效率是很低的，且认证服务器会变成一个中心节点，对于SLA和处理性能等均有很高的要求，这在分布式架构下是很要命的。

JWT就是在这样的背景下诞生的，从本质上来说，jwt就是一种 特殊格式 的token。普通的oauth2颁发的就是一串随机hash字符串，本身无意义，而jwt格式的token是有特定含义的，分为三部分：

这三部分均用base64进行编码，当中用 . 进行分隔，一个典型的jwt格式的token类似 xxxxx.yyyyy.zzzzz 。关于jwt格式的更多具体说明，不是本文讨论的重点，大家可以直接去官网查看官方文档，这里不过多赘述。

相信看到签名大家都很熟悉了，没错，jwt其实并不是什么高深莫测的技术，相反非常简单。认证服务器通过对称或非对称的加密方式利用 payload 生成 signature ，并在 header 中申明签名方式，仅此而已。通过这种本质上极其传统的方式，jwt可以实现 分布式的token验证功能 ，即资源服务器通过事先维护好的对称或者非对称密钥（非对称的话就是认证服务器提供的公钥），直接在本地验证token，这种去中心化的验证机制无疑很对现在分布式架构的胃口。jwt相对于传统的token来说，解决以下两个痛点：

在上面的那个资源服务器和认证服务器分离的例子中，如果认证服务器颁发的是jwt格式的token，那么资源服务器就可以直接自己验证token的有效性并绑定用户，这无疑大大提升了处理效率且减少了单点隐患。

就像布鲁克斯在《人月神话》中所说的名言一样：“没有银弹”。JWT的使用上现在也有一种误区，认为传统的认证方式都应该被jwt取代。事实上，jwt也不能解决一切问题，它也有适用场景和不适用场景。

适用场景：

这些场景能充分发挥jwt无状态以及分布式验证的优势

不适用的场景：

不要试图用jwt去代替session。 这种模式下其实传统的session+cookie机制工作的更好，jwt因为其无状态和分布式，事实上只要在有效期内，是无法作废的，用户的签退更多是一个客户端的签退，服务端token仍然有效，你只要使用这个token，仍然可以登陆系统。另外一个问题是续签问题，使用token，无疑令续签变得十分麻烦，当然你也可以通过redis去记录token状态，并在用户访问后更新这个状态，但这就是硬生生把jwt的无状态搞成有状态了，而这些在传统的session+cookie机制中都是不需要去考虑的。这种场景下，考虑高可用，我更加推荐采用分布式的session机制，现在已经有很多的成熟框架可供选择了（比如spring session）。

3. Spring Cloud笔记03: 服务注册和服务发现的基本概念

上节在K8S集群中部署了Nacos集群，并将Nacos的Web控制台和API以Ingress (nacos.youcomany.com)的形式暴露到了k8s集群外部，便于从外部测试和访问。这里再次强调Nacos被设计为一个在IDC内部使用的应用组件，而非面向公网环境的产品，因此需要在内部隔离网络中使用，这里为了测试将其暴露到K8S集群外部，如果是生产环境必须做好网络安全策略。

接下来我们将学习如何将服务注册到Nacos，在开始后边的实战之前，先看一下服务治理中关于服务注册和服务发现的一些概念。

服务治理首先要解决的问题就是服务注册于服务发现，解决了这两个问题才可能实现微服务之间的调用问题。

服务注册中心 : 每个服务实例会向注册中心注册自己的信息，一般包含地址、端口、协议、版本等信息。每种服务会有多个实例副本注册到注册中心，注册中心维护每种服务的多个实例列表。同时，注册中心会以某种机制去检查各个服务实例是否可用，如果某个实例已经失效会将其剔除。在某个服务实例关闭时会自动向注册中心注销自己。

常见的服务注册有三种实现方式：

服务发现 : 即服务客户端在其网络上找到其要调用服务的具体连接信息的过程。例如通过查询服务注册中心得到其所调用服务的具体 IP地址和端口。简单的说，服务发现就是服务或者应用之间互相定位的过程。

使用服务发现后，客户端对服务的调用不再和具体的服务实例地址耦合，而是基于服务发现机制。有以下4种常见的服务发现机制:

K8S中的一个Service资源对象对应微服务。每个Service有唯一的名字，一个ClusterIP，一个端口。 K8S中的Pod资源对象中运行的容器对应服务实例，通过Pod上的标签Label和Service上定义的标签选择器Label Selector将Service与Pod关联，通过Service内建的负载均衡机制，对Service的调用将转发到Pod的容器中。 K8S中的服务注册是在Pod创建时由调度者Kubernetes完成的。K8S中的服务发现采用的是服务端负载均衡器，服务注册中心为Kubernetes(后端持久化存储etcd)。

Spring Cloud对微服务提供了完整的解决方案和统一抽象，按照微服务的功能特性: 服务治理、负载均衡、服务间调用通信、服务配置中心、服务网关、分布式链路追踪、消息总线、消息时间驱动、分布式事务等，提供了一系列组件，被称为Spring Cloud全家桶。全家桶中的功能组件还支持使用第三方实现的某个组件单独替换，只要第三方组件是遵循Spring Cloud Common的抽象实现的。

Spring Cloud在服务治理的组件上有以下三种选择:

当然由于"某些原因"，在最新版本的Spring Cloud中Netflix组件库已经逐渐被移除。

我们在这里对Spring Cloud服务注册和服务发现的学习将使用Spring Cloud Alibaba组件的Nacos。

Nacos是Spring Cloud Alibaba提供的服务发现和配置管理的解决方案。Nacos是用Java开发的，通过Spring Cloud Alibaba可以很好的与Spring Cloud整合。如果项目的所有微服务都是用Java开发的，那么使用Nacos作为服务发现可能会使一个不错的选择。

Nacos的服务注册采用的是由"服务进程内直接包含服务注册模块，由服务实例自己完成上线注册和下线注销。"，这与K8S服务注册方案中"由一个中间调度者K8S来帮助处理服务注册"是不同的。

4. 【知识总结】6.服务注册发现框架比较(Consul/Zookeeper/etcd/Eureka)

服务发现就是服务提供者将自己提供的地址post或者update到服务中介，服务消费者从服务中介那里get自己想要的服务的地址。

但是有两个问题：
第一个问题：如果有一个服务提供者宕机，那么中介的key/value中会有一个不能访问的地址，该怎么办？

心跳机制：服务提供者需要每隔5秒左右向服务中介汇报存活，服务中介将服务地址和汇报时间记录在zset数据结构的value和score中。服务中介需要每隔10秒左右检查zset数据结构，踢掉汇报时间严重落后的地址。这样就可以保证服务列表中地址的有效性。

第二个问题是服务地址变动时如何通知消费者。有两种解决方案。

第一种是轮询，消费者每隔几秒查询服务列表是否有改变。如果服务地址很多，查询会很慢。这时候可以引入服务版本号机制，给每个服务提供一个版本号，在服务变动时，递增这个版本号。消费者只需要轮询这个版本号的变动即可知道服务列表是否发生了变化。

第二种是采用pubsub。这种方式及时性要明显好于轮询。缺点是每个pubsub都会占用消费者一个线程和一个额外的连接。为了减少对线程和连接的浪费，我们使用单个pubsub广播全局版本号的变动。所谓全局版本号就是任意服务列表发生了变动，这个版本号都会递增。接收到版本变动的消费者再去检查各自的依赖服务列表的版本号是否发生了变动。这种全局版本号也可以用于第一种轮询方案。

CAP理论
CAP理论是分布式架构中重要理论

关于P的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求，CAP 不可能都取，只能取其中2个。原因是

（1）如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。

（2）如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。

（3）再如果，同事满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心，好了，明白这些理论，就可以在相应的场景选取服务注册与发现了。

平时经常用到的服务发现的产品进行下特性的对比，首先看下结论：

补充：
（1）运维和开发如果是 Java 更熟，也更多 Java 的应用，那毫无疑问应该用 ZK；如果是搞 Go 的，那么还是 etcd 吧，毕竟有时候遇到问题还是要看源码的。
（2）在创建一百万个或更多键时，etcd可以比Zookeeper或Consul稳定地提供更好的吞吐量和延迟。此外，它实现了这一目标，只有一半的内存，显示出更高的效率。但是，还有一些改进的余地，Zookeeper设法通过etcd提供更好的最小延迟，代价是不可预测的平均延迟。
（3）
一致性协议： etcd 使用 Raft 协议，Zookeeper 使用 ZAB（类PAXOS协议），前者容易理解，方便工程实现；
运维方面：etcd 方便运维，Zookeeper 难以运维；
数据存储：etcd 多版本并发控制（MVCC）数据模型，支持查询先前版本的键值对
项目活跃度：etcd 社区与开发活跃，Zookeeper 感觉已经快死了；
API：etcd 提供 HTTP+JSON, gRPC 接口，跨平台跨语言，Zookeeper 需要使用其客户端；
访问安全方面：etcd 支持 HTTPS 访问，Zookeeper 在这方面缺失；

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。

从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。

但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。

因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好（淘宝的双十一，京东的618就是紧遵AP的最好参照）。

当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署环境下，因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则。Eureka是在Java语言上，基于Restful Api开发的服务注册与发现组件，由Netflix开源。遗憾的是，目前Eureka仅开源到1.X版本，2.X版本已经宣布闭源。

Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。

当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。

默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳（默认周期为30秒），Eureka Server 将会注销该实例（默认为90秒， eureka.instance.lease-expiration-ration-in-seconds 进行自定义配置）。

当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。

Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；
Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；
当网络稳定时，当前实例新注册的信息会被同步到其它节点中；
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写，因此具有天然可移植性（支持Linux、windows和Mac OS X）。
Consul采用主从模式的设计，使得集群的数量可以大规模扩展，集群间通过RPC的方式调用(HTTP和DNS)。

Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。

Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

默认依赖于SDK

Consul本质上属于应用外的注册方式，但可以通过SDK简化注册流程。而服务发现恰好相反，默认依赖于SDK，但可以通过Consul Template（下文会提到）去除SDK依赖。

Consul Template

Consul，默认服务调用者需要依赖Consul SDK来发现服务，这就无法保证对应用的零侵入性。

所幸通过 Consul Template ，可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置（比如nginx的upstream），这样对于服务调用者而言，只需要配置一个统一的服务调用地址即可。

Consul强一致性(C)带来的是：

Eureka保证高可用(A)和最终一致性：

其他方面，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。

etcd是一个采用http协议的分布式键值对存储系统，因其易用，简单。很多系统都采用或支持etcd作为服务发现的一部分，比如kubernetes。但正事因为其只是一个存储系统，如果想要提供完整的服务发现功能，必须搭配一些第三方的工具。

比如配合etcd、Registrator、confd组合，就能搭建一个非常简单而强大的服务发现框架。但这种搭建操作就稍微麻烦了点，尤其是相对consul来说。所以etcd大部分场景都是被用来做kv存储，比如kubernetes。

etcd 比较多的应用场景是用于服务发现，服务发现 (Service Discovery) 要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。和 Zookeeper 类似，etcd 有很多使用场景，包括：
配置管理
服务注册发现
选主
应用调度
分布式队列
分布式锁

按照官网给出的数据，在 2CPU，1.8G 内存，SSD 磁盘这样的配置下，单节点的写性能可以达到 16K QPS, 而先写后读也能达到12K QPS。这个性能还是相当可观。

etcd 提供了 etcdctl 命令行工具和 HTTP API 两种交互方法。etcdctl命令行工具用 go 语言编写，也是对 HTTP API 的封装，日常使用起来也更容易。所以这里我们主要使用 etcdctl 命令行工具演示。

（1）注册中心ZooKeeper、Eureka、Consul 、Nacos对比
https://zhuanlan.hu.com/p/165217227?utm_source=wechat_session
（2）常用的服务发现对比（Consul、zookeeper、etcd、eureka）
https://blog.csdn.net/gaohe7091/article/details/101197107

5. 如何理解中心化与去中心化概念

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

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

举例说明

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

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

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

其他看法

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

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

6. springcloud四个注册中心的比较

springcloud是一个非常优秀的微服务框架，要管理众多的服务，就需要对这些服务进行治理，也就是我们说的服务治理 , 服务治理的作用就是在传统的rpc远程调用框架中，管理每个服务与每个服务之间的依赖关系，可以实现服务调用、负载均衡、服务容错、以及服务的注册与发现。
如果微服务之间存在调用依赖，就需要得到目标服务的服务地址，也就是微服务治理的服务发现。要完成服务发现，就需要将服务信息存储到某个载体，载体本身即是微服务治理的服务注册中心，而存储到载体的动作即是服务注册。
springcloud支持的注册中心有 Eureka 、 Zookeeper 、 Consul 、 Nacos

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则,Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。

Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况:

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写，因此具有天然可移植性（支持Linux、windows和Mac OS X）。Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。
Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。一句话概括就是Nacos = 注册中心 + 配置中心。

这四个组件虽然都实现了注册中心的功能，但是他们的功能和实现方式都有不同的地方，也各有各的优点,单从注册中心方面来比价四个注册中心(如果不了解 CAP定理可先阅读下一章节):

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本，那么系统必然满足强一致性条件，因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。

因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 memcached 之类的 NOSQL 作为实现手段。虽然 memcached 也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached 服务器上。如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，但是实现难度是非常大的

例如，根据CAP定理将NoSql数据分成了满足CA原则、满足CP原则和满足AP原则的三大类:

7. 微服务框架之Spring Cloud简介

在了解 Spring Cloud 之前先了解一下微服务架构需要考量的核心关键点，如下图：

对于以上等核心关键点的处理，不需要我们重复造车轮， Spring Cloud 已经帮我们集成了，它使用 Spring Boot 风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。

Spring Cloud 所提供的核心功能包含：

Spring Cloud架构图

Spring Cloud子项目

Spring Cloud 旗下的子项目大致可以分为两类：

如下：

1. Spring Cloud 与 Spring Boot

Spring Boot 可以说是微服务架构的核心技术之一。通过在 Spring Boot 应用中添加 Spring MVC 依赖，就可以快速实现基于 REST 架构的服务接口，并且可以提供对 HTTP 标准动作的支持。而且 Spring Boot 默认提供 JackJson 序列化支持，可以让服务接口输入、输出支持 JSON 等。因此，当使用 Spring Cloud 进行微服务架构开发时，使用 Spring Boot 是一条必经之路。

2. Spring Cloud 与服务治理( Eureka )

服务治理是 Spring Cloud 的核心，在实现上其提供了两个选择，即 Consul 和 Netflix 的 Eureka 。

Eureka 提供了服务注册中心、服务发现客户端，以及注册服务的 UI 界面应用。

在 Eureka 的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机， Eureka 客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。

3. Spring Cloud 与客户端负载均衡( Ribbon )

Ribbon 默认与 Eureak 进行无缝整合，当客户端启动的时候，从 Eureka 服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时， Ribbon 就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。

Spring Cloud 通过集成 Netflix 的 Feign 项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认 Feign 项目集成了 Ribbon ，使得声明式调用也支持客户端负载均衡功能。

4. Spring Cloud 与微服务容错、降级( Hystrix )

为了给微服务架构提供更大的弹性，在 Spring Cloud 中，通过集成 Netflix 下子项目 Hystrix ，通过所提供的 @HystrixCommand 注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外， Hystrix 也默认集成到 Feign 子项目中。

Hystrix 是根据“断路器”模式而创建。当 Hystrix 监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（ fallback ），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。

而 Hystrix 的仪表盘项目（ Dashboard ）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。

5. Spring Cloud 与服务网关( Zuul )

Spring Cloud 通过集成 Netflix 中的 Zuul 实现 API 服务网关功能，提供对请求的路由和过滤两个功能

路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。

过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。

通过 Zuul ，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个 API 接口，屏蔽了服务端的实现细节。通过 Zuul 的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外， Zuul 默认会与 Eureka 服务器进行整合，自动从 Eureka 服务器中获取所有注册的服务并进行路由映射，实现 API 服务网关自动配置。

6. Spring Cloud 与消息中间件( Stream )

Spring Cloud 为简化基于消息的开发，提供了 Stream 子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与 Kafka 和 RabbitMQ 等消息中间件进行集成。

Spring Cloud Bus 基于 Stream 进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。

比如 Spring Cloud Config 借助 Bus ，可以实现配置的动态刷新处理。

7. Spring Cloud 与分布式配置中心( Config )

针对微服务架构下的配置文件管理需求， Spring Cloud 提供了一个 Config 子项目。 Spring Cloud Config 具有中心化、版本控制、支持动态更新和语言独立等特性。

在 Config 子项目中将微服务应用分为两种角色：配置服务器（ Config Server ）和配置客户端（ Config Client ）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到 Git 、 SVN 等具有版本管理仓库中，也可以存放在文件系统中。默认采用 Git 的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。

8. Spring Cloud 与微服务链路追踪( Sleuth )

Spring Cloud 中的 Sleuth 子项目为开发者提供了微服务之间调用的链路追踪。

Sleuth 核心思想就是通过一个全局的 ID 将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。

因此，通过 Sleuth 可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给 Zipkin 进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。

9. Spring Cloud 与微服务安全( Security )

Spring Cloud Security 为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合 Zuul 可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。

Spring Cloud Security 默认支持 OAuth 2.0 认证协议，因此单点登录也可以非常容易实现，并且 OAuth2.0 所生成的令牌可以使用 JWT 的方式，进一步简化了微服务中的安全管理。

10. Spring Cloud 的其他子项目

8. 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依赖

springCloud去中心化机制

与springCloud去中心化机制相关的资讯