SpringCloud

SpringCloud

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库

微服务

强调的是服务的大小，关注的是某一个点，是具体解决某一个问题/提供落地对于服务的一个服务应用，狭义的看，可以看做成是IDEA中的一个个微服务功能或者Moudel

微服务架构

一个新的架构形式，Martin Fowler，2014提出

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。每一个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建

微服务优缺点

优点

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

缺点

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

微服务技术栈

为什么选择SpringCloud作为微服务架构

1.选型依据

• 整体解决方案和框架成熟度
• 社区热度
• 可维护性
• 学习曲线

2.当前各大IT公司用的微服务架构有哪些？
阿里：dubbo+HFS
京东：jsf
新浪：motan
当当网：dubboX

SpringCloud基于SpringBoot提供了一套微服务解决方案，包括服务注册于发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NexFlixx开源组件做高度抽象封装之外，还有一些选型中立的开源组件

SpringCloud利用SpringBoot开发便利性，巧妙地简化了分布式系统基础设施的开发，SpringCloud提供了快速构建分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等，他们可以用Springboot的开发风格做到一键启动和部署

Springboot并没有重复造轮子，它只是将目前各家公司开发的比较成熟，比较经得起实际考研的服务框架组合起来，通过Springboot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包

SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶

SpringCloud和SpringBoot关系

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

Dubbo和SpringCloud技术选型

1.分布式+服务治理Dubbo
目前成熟的互联网架构：应用服务化拆分+消息中间件

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框架，Spring Cloud的目标是微服务架构下的一站式解决方案

SpringCloud版本

Restful风格

Eureka服务注册与发现

什么是Eureka

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

原理讲解

Eureka的基本架构

• springcloud封装了Netflix公司开发的Eureka模块来实现服务注册和发现
• Eureka采用了C-S的架构设计，EurekaServer作为服务注册功能的服务器，他是服务注册中心
• 而系统中的其他微服务。使用Eureka的客户端连接到EurekaServer并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，Springcloud的一些其他模块（比如Zuul）既可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑
• 和Dubbo架构相比

遇到这个错误：

springboot的版本在2.2.0以后和cloud的GreenWich.SR1冲突，所有会报错
\

Eurake自我保护机制：好死不如赖活着

Eureka集群，如果你是一个人测试，需要把自己localhost修改

其中7003的设置：
ps：如果修改了主机上的host，也要改变

CAP原则

NoSQL (redis、mongdb)====>CAP
cap：
C(Consistency)：强一致性
A(Availablility):可用性
P(Partition tolerance)：分区容错性

CAP的三进二：CA、AP、CP
CAP理论的核心

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

Eureka和Zookeeper区别

Ribbon

什么是Ribbon？

• SpringCloud是基于Netflix Ribbon实现的一套客户端负载均衡的工具
• 简单地说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如：连接超时、重试等等。简单的说，就是在配置文件中列出LoadBalancer（简称：LB：负载均衡）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法！

Ribbon能干嘛？

• LB，即负载均衡（Load Balance），在微服务或分布式集群中经常用的一种应用
• 负载均衡简单来说就是将用户的请求平摊的分配到多个服务
• 常见的负载均衡软件有Nginx，Lvs等等
• dubbo、SpringCloud中均给我们提供了负载均衡，SprinCloud的负载均衡算法可以自定义
• 负载均衡简单分类：
  1. 集中式LB
  即在服务的消费方和提供方之间使用独立的LB设施，如Nginx，由该设施负责把访问请求通过某种策略转发至服务的提供方

2.进程式LB

• 将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器
• Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它获取到服务提供方的地址

配置只要加个注解

Ribbon和Eureka整合之后，客户端可以直接调用，不用关心ip地址和端口号

加载自定义ribben

Feign负载均衡

1.简介
feign是声明式的web service客户端，它让微服务之间的调用变得更加简单了，类似controller调用service。Spring Cloud集成了Ribbon和Eureka，可再使用Feign时提供负载均衡的http客户端。

只要创建一个接口，然后添加注解即可！

feign，主要是社区，大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法
1.微服务名字 【ribbon】
2。接口和注解 【feign】

feign能干嘛？
1.feign旨在使编写java http客户端变得更加容易
2.前面再使用ribbon+RestTemplate时，利用RestTemplate对Http
请求的封装处理，形成了模板化的调用方法。但是再实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，feign再基础上进行了一步一步的封装，由他来帮助我们定义和实现依赖服务接口的定义，再feign的实现下，我们只需要创建一个接口并且使用注解的方式来配置它（类似于以前Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个feign注解即可）。即可完成对服务提供方的接口绑定，简化了使用Springcloud ribbon时，自动封装服务调用客户端的开发量

Feign集成了Ribbon

• 利用Ribbon维护了MicroServiceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，通过Feign只需要定义服务绑定接口且以声明式的方法，优雅而且简单的实现了服务调用

Hystrix 熔断

hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等等，Hystrix能够保证再一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

断路器本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回有个服务预期的，可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩

能干嘛

• 服务降级
• 服务熔断
• 服务限流
• 接近实时的监控

服务熔断

是什么？
熔断机制是对应雪崩效应的一种微服务链路保护机制

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand

而在启动页面时候，添加的是

左下角网址false是默认的，true将localhost改成ip

监控服务

方法上添加注解

![在这里插入图片描述](https://img-blog.csdnimg.cn/20201210190748547.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0dvZF9PZl9HdW4=,size_16,color_FFFFFF,t_70依赖

添加bean

Zuul路由网关

概述
什么是Zuul？
Zuul包含了对请求的路由和过滤两个最主要的功能：

其中路由功能负责将外部请求转发到具体的微服务实例上面，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务器聚合等功能的基础，Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，哦同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得

注意：Zuul服务最终还是会注册进Eureka
提供：代理+路由+过滤三大功能！

Zuul能干嘛

• 路由
• 过滤

1.导入依赖
**
**

2.配置yml

3.配置启动项

SpringCloud config分布式配置

概述
分布式系统面临的一配置文件的问题

微服务意味着要将单个应用中业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务，由于每个服务都需要必要的配置信息才能运行，所以一套集中式的，动态的配置管理设施必不可少的。SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml,拿上百的配置文件要修改起来，岂不是发疯！

什么是SpringCloud config分布式配置中心

Springcloud config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置

Springcloud config分为服务端和客户端两部分

服务端也成为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供了获取配置信息，加密，解密信息等访问接口

客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容

SpringCloud config分布式配置中心能干嘛？

• 集中管理配置文件
• 不同环境，不同配置，动态化的配置更新，分环境部署，比如/dev,/test,/prod,/beta,/release-
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
• 当配置发生变动时，服务不需要重启，即可感知到配置的变化，并应用新的配置
• 将配置信息以REST接口的形式暴露

SpringCloud config分布式配置中心与guthub整合
由于SpringCloud config默认使用Git来存储配置文件（也有其他方式，比如支持svn和本地文件），但是最推荐的还是Git，而且使用的是Http:/https访问的形式