spring cloud 学习笔记

spring cloud 学习笔记

学习内容包括《深入理解spring cloud与微服务架构》、spring could官方手册

什么是spring cloud

自我理解：一套基于spring boot微服务的框架，至于什么是微服务，可见我另一篇学习笔记。实现的功能包括服务的注册、发现、消费、断路器、路由网关、分布式配置中心、消息总线、链路追踪、监控等。也可以说是一套分布式的框架，分布式系统是若干独立计算机的集合，这计算机对用户来说就像单个相关系统。这样的框架简化我们的开发过程。

官方手册原文：

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.

下面这两张图片都是spring cloud架构图

spring cloud依赖组件完成功能，完成不同的功能需要不同的组件。下面依次学习介绍一下。

Spring Cloud Netflix

github上原文：

This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with battle-tested Netflix components. The patterns provided include Netflix OSS

自己理解一下：就是一个集成了有很多组件的组件，集成的组件包括服务发现（Eureka），断路器（Hystrix），智能路由（Zuul）和客户端负载平衡（Ribbon）。不过作为一个初学者，我很奇怪，spring could已经是一个框架了，Netflix为什么还要集成了，为什么要使用Netflix了。我查阅了很多资料，似乎是Netflix公司开发并开源了这些组件，这是我暂时的理解。

spring cloud Netflix Eureka（注册中心）

一个注册中心，实现服务的管理，包括注册、发现、消费等。他是Netflix的一个组件。

具体的代码实现可以参考《深入理解spring cloud与微服务架构》的作者的[博客][https://www.fangzhipeng.com/springcloud/2018/08/01/sc-f1-eureka.html]

大致过程就是创建一个maven主工程，然后创建两个model工程，一个model工程作为服务注册中心，即Eureka Server,另一个作为Eureka Client。我们可以再创建一个spring boot工程作为消费者，通过ribbon+restTemplate或者是feign调用方式，去调用注册的服务。

借用作者的一张图：

• 一个服务注册中心，eureka server,端口为8761
• service-hi工程跑了两个实例，端口分别为8762,8763，分别向服务注册中心注册
• sercvice-ribbon端口为8764,向服务注册中心注册
• 当sercvice-ribbon通过restTemplate调用service-hi的hi接口时，因为用ribbon进行了负载均衡，会轮流的调用service-hi：8762和8763 两个端口的hi接口；

zookeeper和Eureka对比

Dubbo使用ZooKeeper来做服务注册管理中心，SpringCloud使用Eureka来做服务治理中心。

区别：

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

Zookeeper保证CP

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

Eureka保证AP

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

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

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

spring cloud Netflix Hystrix（断路器）

为什么要使用断路器

在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

断路器可以在服务出现故障时，返回一个固定值，避免造成更严重的后果。

Netflix开源了Hystrix组件，实现了断路器模式，SpringCloud对这一组件进行了整合。 在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图：

较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystric 是5秒20次） 断路器将会被打开。

断路打开后，可用避免连锁故障，fallback方法可以直接返回一个固定值。

断路器的代码实现同样可见作者的[博客][https://www.fangzhipeng.com/springcloud/2018/08/01/sc-f1-eureka.html]

spring cloud Netflix Zuul 与 gateway （网关）

Zuul的主要功能是路由转发和过滤器。路由功能是微服务的一部分，比如／api/user转发到到user服务，/api/shop转发到到shop服务。zuul默认和Ribbon结合实现了负载均衡的功能。

Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。

同样借用作者的图来说明网关的作用

注意：A服务和B服务是可以相互调用的，作图的时候忘记了。并且配置服务也是注册到服务注册中心的。

在Spring Cloud微服务系统中，一种常见的负载均衡方式是，客户端的请求首先经过负载均衡（zuul、Ngnix），再到达服务网关（zuul集群），然后再到具体的服务，服务统一注册到高可用的服务注册中心集群，服务的所有的配置文件由配置服务管理，配置服务的配置文件放在git仓库，方便开发人员随时改配置。

zuul已经要被取代了，主要看看gateway。

gateway

官网手册原文：

This project provides a library for building an API Gateway on top of Spring MVC. Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.

在网络中，网关是一种充当转换重任的计算机系统或设备。使用在不同的通信协议、数据格式或语言，甚至体系结构完全不同的两种系统之间，网关是一个翻译器。按照不同的分类标准，网关也有不同种类。TCP/IP协议里的网关是最常用的，在这里我们所讲的“网关”均指TCP/IP协议下的网关。

网关实质上是一个网络通向其他网络的IP地址。比如有网络A和网络B，网络A的IP地址范围为“192.168.1.1~192. 168.1.254”，子网掩码为255.255.255.0；网络B的IP地址范围为“192.168.2.1~192.168.2.254”，子网掩码为255.255.255.0。在没有路由器的情况下，两个网络之间是不能进行TCP/IP通信的，即使是两个网络连接在同一台交换机(或集线器)上，TCP/IP协议也会根据子网掩码(255.255.255.0)判定两个网络中的主机处在不同的网络里。而要实现这两个网络之间的通信，则必须通过网关。如果网络A中的主机发现数据包的目的主机不在本地网络中，就把数据包转发给它自己的网关，再由网关转发给网络B的网关，网络B的网关再转发给网络B的某个主机。网络B向网络A转发数据包的过程。

因为我学过网络所以这里拿来对比一下

Spring Cloud Gateway功能：

• 基于Spring Framework 5，Project Reactor和Spring Boot 2.0构建
• 能够匹配任何请求属性上的路由。
• 谓词和过滤器特定于路由。
• Hystrix断路器集成。
• Spring Cloud DiscoveryClient集成
• 易于编写的谓词和过滤器
• 请求速率限制
• 路径改写

网关的断言和过滤器比较好理解，相关代码可以去作者的博客。我们这里主要看一下Spring Cloud Gateway如何配合服务注册中心进行路由转发。

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

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。

Spring Cloud Bus(消息总线)

Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改或者服务之间的通讯，也可以用于监控。Spring Cloud Bus 是基于MQ实现的，我准备再学一下，MQ和redis。下图实现用Spring Cloud Bus实现通知微服务架构的配置文件的更改。

当git文件更改的时候，通过pc端用post 向端口为8882的config-client发送请求/bus/refresh／；此时8882端口会发送一个消息，由消息总线向其他服务传递，从而使整个微服务集群都达到更新配置文件。

Spring Cloud Sleuth(服务链路追踪)

Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。

我使用ELK完成过zipkin的搭建，应用记录日志，通过ELK系统格式化，zipkin再读取ES的数据，这样也可以实现链路监控。

服务链路追踪)

Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。

我使用ELK完成过zipkin的搭建，应用记录日志，通过ELK系统格式化，zipkin再读取ES的数据，这样也可以实现链路监控。