什么是SpringCloud

1.SpringCloud是什么？

• SpringCloud他是现代化的java开发
• SpringCloud他是基于Springboot提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。
• SpringCloud的利用SpringBoot的开发便利性，巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等，他们都可以用SpringBoot的开发风格做到一键启动和部署。
• SpringBoot并没有重复造轮子，他只是将目前各家公司的比较成熟，经得起实际考研的服务框架组合起来，通过SpringBoot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简答易懂，易部署和易维护的分布式系统开发工具包。
• SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。

2.SpringCloud和SpringBoot的关系（SpringCloud离不开SpringBoot）

• SpringBoot专注于快速方便的开发单个个体微服务。
• SpringCloud是关注全局的微服务协调整理治理框架，他将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选，分布式会话等等集成服务。
• SpringBoot可以离开SpringCloud独立使用，开发项目，但是SpringCloud离不开Springboot，属于依赖关系。
• SpringBoot专注于快速、方便的开发单个个体微服务，SpringCloud关注于全局的服务治理框架。

3.Dubbo和SpringCloud技术选型

1. 分布式+服务治理Dubbo

   目前成熟的互联网架构：应用服务化拆分+消息中间件

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QPfd50iz-1604756818134)(C:\Users\11111\AppData\Roaming\Typora\typora-user-images\image-20201007152051105.png)]

2. Dubbo和SpringCloud对比

   最大区别: SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。
   品牌机与组装机的区别
   很明显，Spring Cloud的功能比DUBBO更加强大，涵盖面更广，而且作为Spring的拳头项目，它也够与SpringFramework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合，这于微服务而言是至关重要的。使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题;而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。
   社区支持与更新力度
   最为重要的是，DUBBO停止了5年左右的更新，虽然2017.7重启了。对于技术发展的新需求，需要由开发者自行拓展升级（比如当当网弄出了DubboX)，这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。
   总结:
   曾风靡国内的开源RPC服务框架Dubbo在重启维护后，令许多用户为之雀跃，但同时，也迎来了一些质疑的声音。互联网技术发展迅速，Dubbo是否还能跟上时代?Dubbo与Spring Cloud相比又有何优势和差异?是否会有相关举措保证 Dubbo的后续更新频率?
   人物:Dubbo重启维护开发的刘军，主要负责人之一
   刘军，阿里巴巴中间件高级研发工程师，主导了Dubbo重启维护以后的几个发版计划，专注于高性能RPC框架和微服务相关领域。曾负责网易考拉RPC框架的研发及指导在内部使用，参与了服务治理平台、分布式跟踪系统、分布式一致性框架等从无到有的设计与开发过程。

   解决的问题域不一样：Dubbo的定位是一款RPC框架，SpringCloud的目标是微服务架构下的一站式解决方案

4.参考书

• 中文API文档：
• SpringCloud中国社区：
• SpringCloud中文网：

5.Eureka服务注册与发现

5.1、什么是Eureka

• Eureka他就是服务注册与发现
• Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于Dubbo的注册中心，比如zookeeper；

5.2、原理讲解

• Eureka的基本架构
  • SpringCloud封装了NetFlix公司开发的Eureka模块来实现服务注册和发现(对比Zookeeper)
  • Eureka采用了C-S的架构设计，EurekaServer作为服务注册功能的服务器，他是服务注册中心
  • 二系统中的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳连接，这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，SpringCloud的一些其他模块（比如Zuul）就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑；
  • 和Dubbo架构对比
  • Eureka包含两个组件：EurekaServer和EurekaClient。
  • EurekaServer提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会村粗所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
  • EnrekaClient是一个java客胡端，用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳（默认周期为30面）。如果EurekaServer在多个心跳周期内没用接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉（默认周期为90秒）
• 三大角色
  • Eureka Server：提供服务的注册与发现。类似于zookeeper
  • Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到。
  • Service Consumer:服务消费放从Eureka中获取注册服务列表，从而找到消费服务。

6.CAP对比Zookeeper

6.1、CPA原则

RDBMS（Mysql、Oracle、slqServer）===》ACID

NoSQL（redis、mongdb）===》CPA

6.2、ACID是什么

• A（Atomicity）原子性
• C（Consistency）一致性
• I（Isolation）隔离性
• D（Durabolity）持久性

6.3、CAP是什么？

• C（Consistency）强一致性
• A（Availability）可用性
• P（Partition tolerance）分区容错性

CAP的三进二：CA、AP、CP

CAP的核心：

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
• 根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类：
  • CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
  • CP：满足一致性，分区容错性的系统，通常性能不是特别高
  • AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

7.Eureka比Zookeeper好在哪里

一个分布式系统不可能同时满足C（一致性）、A（可用性）、P（容错）

由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。

• Zookeeper保证的是CP；
• Eureka保证的是AP；

Zookeeper保证的是CP

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

Eureka保证的是AP

​ Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依赖可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过去的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同时达到其他节点上（既保证当前节点依然可用）
3. 当网绿稳定时，当前实例新的注册信息会被同步到其他节点中

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