SpringCloud学习

本笔记是在学习狂神说java的B站视频记录的。

回顾之前知识（加粗重点）：

• JavaSE
• 数据库
• 前端
• Servlet
• Http
• Mybatis
• Spring
• SpringMVC
• SpringBoot
• Dubbo、Zookeeper、分布式基础
• Maven、Git
• Ajax、Json

微服务架构会遇到的四个核心问题？

1. 这么多服务，客户端该如何去访问？
2. 这么多服务，服务之间如何进行通信？
3. 这么多服务，如何治理呢？
4. 服务挂了，怎么办？

解决方案：SpringCloud （生态）

1. Spring Cloud NetFlix ，出来了一套解决方案！一站式解决方案，我们都可以直接取这里拿

   Api网关——zuul组件

   Feign --> HttpClient ---> HTTP的通信方式，同步并阻塞

   服务注册与发现：Eureka

   熔断机制，Hystrix

   2018年年底，NetFlix宣布无限期停止维护。生态不再维护，就会脱节

2. Apache Dubbo zookeeper，第二套解决系统，半自动需要整合其他的。

   • API：没有，要么找第三方组件，要么自己实现

   • Dubbo是一个高性能的基于Java实现的RPC通信框架！2.6.x

   • 服务注册与发现，zookeeper：动物园管理者（Hadoop，Hive）

   • 没有熔断机制，借助了Hystrix

   • 不完善，Dubbo当前3.0汲取阿里内部HSF的设计长处

3. SpringCloud Alibaba 一站式解决方案！更简单

目前，又提出了一种方案：

​ 新概念：**服务网格 **：下一代微服务标准，Server Mesh

​ 代表解决方案：istio（未来需要掌握）

万变不离其宗，一通百通！

1. API网关，服务路由

2. HTTP、RPC框架，异步调用

3. 服务注册与发现，高可用

4. 熔断机制，服务降级

为什么要解决这个问题？本质：网络是不可靠的！

1. 微服务的核心：将传统一站式应用拆分成一个一个的服务，彻底解耦，每个微服务提供单个业务功能的服务，一个服务做一件事情，能够自行单独启动或销毁，拥有自己独立的数据库。

2. 微服务vs微服务架构

   微服务：是具体的一个服务应用（可以看做是IDEA的一个个微服务工程或者Module）

   微服务架构：是一种架构模式，提倡单体应用拆分成一组小的服务，服务间互相协调配合。处理一系列微服务问题。

3. 微服务优缺点

优点：

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

缺点：

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

微服务技术栈

微服务技术栈

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

1. 选型依据
   • 整体解决方案和框架成熟度
   • 社区热度
   • 可维护性
   • 学习曲线
2. 当前各大IT公司用的微服务架构有哪些
   • 阿里：dubbo+HFS
   • 京东：JSF
   • 新浪：Motan
   • 当当网：DubboX
3. 各微服务框架对比

各微服务框架对比

SpringCloud

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

SpringCloud

SpringCloud关注全局的服务治理框架

分布式传统架构

分布式传统架构

Dubbo和SpringCloud对比

dubbo和SpringCloud对比

最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用基于HTTP的REST方式

SpringCloud能干嘛

• Distributed/versioned configuration（分布式/版本化配置）
• Service registration and discovery（服务注册和发现）
• Routing（路由）
• Service-to-service calls（服务到服务的调用）
• Load balancing（负载均衡）
• Circuit Breakers（断路器）
• Global locks（全局锁）
• Leadership election and cluster state（领导选举和集群状态）
• Distributed messaging（分布式消息传递）

springcloud文档：https://www.springcloud.cc/

版本对应关系：

Spring Cloud	Spring Boot
Angel版本	兼容Spring Boot 1.2.x
Brixton版本	兼容Spring Boot 1.3.x，也兼容Spring Boot 1.4.x
Camden版本	兼容Spring Boot 1.4.x，也兼容Spring Boot 1.5.x
Dalston版本、Edgware版本	兼容Spring Boot 1.5.x，不兼容Spring Boot 2.0.x
Finchley版本	兼容Spring Boot 2.0.x，不兼容Spring Boot 1.5.x
Greenwich版本	兼容Spring Boot 2.1.x
Hoxtonl版本	兼容Spring Boot 2.2.x

在实际开发过程中，我们需要更详细的版本对应：

Spring Boot	Spring Cloud
1.5.2.RELEASE	Dalston.RC1
1.5.9.RELEASE	Edgware.RELEASE
2.0.2.RELEASE	Finchley.BUILD-SNAPSHOT
2.0.3.RELEASE	Finchley.RELEASE
2.1.0.RELEASE-2.1.14.RELEASE	Greenwich.SR5
2.2.0.M4	Hoxton.SR4

Eureka服务注册与发现

Eureka框架流程

Eureka两大组件：Eureka Server 和 Eureka Client

三大角色：

Eureka Server

Service Provider

Service Consumer

步骤

1. 导入依赖
2. 编写配置文件
3. 开启这个功能 @EnableXXX
4. 配置类

自我保护机制：

某时刻某一个微服务不可以用了，eureka不会直接注销这个服务,当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。

CAP是什么？

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

Zookeeper保证的是CP

Eureka保证的是AP

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

Riddon负载均衡

Spring Cloud Riddon是基于Netflix Ribbon实现的一套客户端负载均衡工具。

负载均衡（LoadBalancer）：ribbon会自动的帮助你基于某种规则（轮询/随机）去连接这些机器。

简单说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）。

常见的负载均衡软件有Nginx，Lvs等等

分类：

• 集中式LB
• 进程式LB——Riddon

riddon负载均衡

Feign负载均衡

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controller调用service。

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

feign，主要是社区，大家都习惯面向接口编程。这个是很多开发人员的规范，调用微服务访问两种方法：

1.微服务名字【ribbon】

2.接口和注解【feign】

feign能干什么？

• Feign旨在使编写Java Http客户端变得容易
• 前面在使用Ribbon+RestTemplate时，利用RestTemplate对Http请求的封装处理，形成了一套模块化的调用方法。但在实际开发中，往往一个接口会被多处调用。所以，Feign在此基础上做了进一步封装。在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它（类似以前Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可。）

服务熔断Hystrix

服务雪崩：单个依赖关系失败，导致整体失败

什么是Hystrix：能够保证一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式的弹性。

“断路器”（类似熔断保险丝）：本身是一种开关装置，当某个服务单元发生故障后，通过断路器的故障监控，向调用方返回一个服务预期的，可处理的备选相应（FallBack），而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证服务调用方的线程不会被长时间不必要的占用

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

熔断该节点微服务的调用，快速返回错误信息。

Zuul路由网关

zuul能干嘛？（功能）

• 代理

• 路由

• 过滤

什么是Zuul？

​ 其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理进行干预，实现请求校验，服务聚合等功能的基础。

Springcloud Config分布式配置

cofig分布式位置

分布式系统面临的问题——配置文件

配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置

springcloud config 能干嘛

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

总结

springcloud总结