SpringCloud

微服务架构4个核心问题

1.服务很多，客户端该怎么访问？

2.这么多服务？服务间如何通信

3.这么多服务？如何治理

4.服务挂了怎么办？

解决方案：

Spring Cloud 它是你个生态！

1.Spring Cloud NetFlix 一站式解决方案

api网关，zuul组件

Feign HttpClinet Http通信方式，同步，阻塞

服务注册于发现：Eureka

熔断机制：Hystrix

2.Apache Dubbo Zookeeper 半自动，需要整合别人的

API：没有，找第三方组件，或者自己实现

Dubbo

Zookeeper

没有：借助Hystrix

Dubbo这个方案并不完善

3.Spring Cloud Alibaba 一站式解决方案

新概念：服务网格 Server Mesh

istio

万变不离其宗

网络的不可靠产生了这四个问题
1.API
2. HTTP,RPC

3．注册和发现

4．熔断机制

优点
单一职责原则
每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求;·开发简单，开发效率提高，一个服务可能就是专一的只干一件事;
微服务能够被小团队单独开发，这个小团队是2~5人的开发人员组成;
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。·微服务能使用不同的语言开发。
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins，Hudson,bamboo
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML , cSS或其他界面混合
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库

缺点:
开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增加。运维的压力也在增大·系统部署依赖
服务间通信成本数据一致性系统集成测试
性能监控

Eureka:

自我保护机制:好死不如赖活着
一句话总结:某时刻某一个微服务不可以用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存!
·默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒)。但是当网络分区故障发生时，微服务与Eureka之间无法正常通行，以上行为可能变得非常危险了--因为微服务本身其实是健康的，此时本不应该注销这个服务。Eureka通过自我保护机制来解决这个问题--当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务)。当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。
在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话:好死不如赖活着
·综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留)，也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮和稳定
在SpringCloud中，可以使用eureka.server.enable-se1f-preservation m false禁用自我保护模式【不推荐关闭自我保护机制】

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

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

可用性（A）：保证每个请求不管成功或者失败都有响应。

分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。 [1] 

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

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

可用的抉择

编辑 播报

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地。

1. 数据库事务一致性需求　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。

2. 数据库的写实时性和读实时性需求　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

3. 对复杂的SQL查询，特别是多表关联查询的需求　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

与NoSQL的关系

编辑 播报

传统的关系型数据库在功能支持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机制的支持。而与之不同的是，NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）。

传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行；C代表一致性，即保证进行事务的过程中整个数据库的状态是一致的，不会出现数据花掉的情况；I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等；D表示持久化，即事务一旦完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）。

NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。

ACID 是关系型数据库的事务机制需要遵守的原则。事务是一个一致和可靠计算的基本单元，由作为原子单元执行的一系列数据库操作组成。数据库库一般在启动时会提供事务机制，包括事务启动、停止、取消或回滚等。

关系型数据库支持事务的 ACID 原则，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），这四种原则保证在事务过程当中数据的正确性，具体描述如下。

ACID：

原子性（A）

一个事务的所有系列操作步骤被看成一个动作，所有的步骤要么全部完成，要么一个也不会完成。如果在事务过程中发生错误，则会回滚到事务开始前的状态，将要被改变的数据库记录不会被改变。

一致性（C）

一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏，即数据库事务不能破坏关系数据的完整性及业务逻辑上的一致性。

 隔离性（I）

主要用于实现并发控制，隔离能够确保并发执行的事务按顺序一个接一个地执行。通过隔离，一个未完成事务不会影响另外一个未完成事务。

持久性（D）

一旦一个事务被提交，它应该持久保存，不会因为与其他操作冲突而取消这个事务。

从事务的四个特性可以看到关系型数据库是要求强一致性的，但是这一点在 NoSQL 数据库中是重点弱化的机制。原因是当数据库保存强一致性时，很难保证系统具有横向扩展和可用性的优势，因此针对分布式数据存储管理只提供了弱一致性的保障，即 BASE 原理。

BASE原理：

BASE 理论是针对 NoSQL 数据库而言的，它是对 CAP 理论中一致性（C）和可用性（A）进行权衡的结果，源于提出者自己在大规模分布式系统上实践的总结。其核心思想是无法做到强一致性，但每个应用都可以根据自身的特点，采用适当方式达到最终一致性。

基本可用（Basically Available）

基本可用指分布式系统在出现故障时，系统允许损失部分可用性，即保证核心功能或者当前最重要功能可用。

对于用户来说，他们当前最关注的功能或者最常用的功能的可用性将会获得保证，但是其他功能会被削弱。

软状态（Soft-state）

软状态允许系统数据存在中间状态，但不会影响系统的整体可用性，即允许不同节点的副本之间存在暂时的不一致情况。

最终一致性（Eventually Consistent）

最终一致性要求系统中数据副本最终能够一致，而不需要实时保证数据副本一致。例如，银行系统中的非实时转账操作，允许 24 小时内用户账户的状态在转账前后是不一致的，但 24 小时后账户数据必须正确。

最终一致性是 BASE 原理的核心，也是 NoSQL 数据库的主要特点，通过弱化一致性，提高系统的可伸缩性、可靠性和可用性。而且对于大多数 Web 应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是多数分布式数据库产品的方向。

最终一致性可以分为客户端和服务端两个不同的视角。

从客户端的角度看

从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题，最终一致性有以下 5 个变种。

一致性变种	说明
因果一致性	如果进程 A 通知进程 B 它已更新了一个数据项，那么，进程 B 的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程 A 无因果关系的进程 C 的访问遵守一般的最终一致性规则。
读己之所写（Read-Your-Writes） 一致性	当进程 A 自己更新一个数据项之后，它总是访问到更新过的值，且不会看到旧值。这是因果一致性模型的一个特例。
会话（Session）—致性	这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话。
单调（Monotonic）读一致性	如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
单调写一致性	系统保证来自同一个进程的写操作顺序执行。

上述最终一致性的不同方式可以进行组合，例如，单调读一致性和“读己之所写”一致性就可以组合实现。从实践的角度来看，这两者的组合读取自己更新的数据，一旦读取到最新的版本，就不会再读取旧版本，对基于此架构上的程序开发来说，会减少很多额外的烦恼。

从服务器的角度看

从服务端来看，如何尽快地将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验度非常重要的方面。

分布式数据系统有以下特性：

• N 为数据复制的份数。
• W 为更新数据时需要进行写操作的节点数。
• R 为读取数据的时候需要读取的节点数。

如果 W+R>N，写的节点和读的节点重叠，则是强一致性。例如，对于典型的一主一备同步复制的关系型数据库（N=2, W=2,R=1），则不管读的是主库还是备库的数据，都是一致的。

如果 W+R≤N，则是弱一致性。例如，对于一主一备异步复制的关系型数据库（N=2,W=1,R=1），如果读的是备库，则可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置 N≥3。设置不同的N、W、R 组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

如果N=W 且 R=1，则任何一个写节点失效，都会导致写失败，因此可用性会降低。但是由于数据分布的 N 个节点是同步写入的，因此可以保证强一致性。

如果 N=R 且 W=1，则只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。在这种情况下，如果 W＜(N+1)/2，并且写入的节点不重叠，则会存在写冲突。

作为服务注册中心，Eureka比zookeeper好在哪里?

著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性)、A(可用性)、P(容错性)。由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。
.Zookeeper保证的是CP;
 Eureka保证的是AP;

Zookeeper保证的是CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得水k集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况:
1.Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2.Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用)

3.当网络稳定时，当前实例新的注册信息会被同步到其他节点中

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

推荐视频：【狂神说Java】SpringCloud最新教程IDEA版_哔哩哔哩_bilibili