• SpringCloud概念


    SpringCloud概述

    1.SpringCloud是什么?

    官方解释:

     官网: https://spring.io/projects/spring-cloud/

     SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用SpringBoot的开发风格做到一键启动和部署。SpringCloud并没有重复制造轮子,它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

    2.SpringCloudSpringBoot什么关系?

    SpringBoot专注于快速方便的开发单个个体微服务。
    SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,SpringBoot可以离开SpringCloud独立开发项目,但是SpringCloud离不开SpringBoot,属于依赖关系。

    3.SpringCloud优缺点

    1)SpringCloud来源于Spring,质量、稳定性、持续性都可以得到保证。

    SpirngCloud以SpringBoot为基础开发框架,可以给开发者大量的微服务开发经验,例如,只要极少量的标签,你就可以创建一个配置服务器,再加一些标签,你就可以得到一个客户端库来配置你的服务,更加便于业务落地。

    2)SpringCloud 是Java领域最适合做微服务的框架,对Java开发者来说就很容易开发。

    3)耦合度低,不影响其他模块

    4)多个开发团队可以并行开发项目,提高开发效率

    5)直接写自己的代码即可,然后暴露接口,通过组件进行服务通信。

     

    缺点

    只能针对Java开发

    部署麻烦、组件多

    每个微服务都可以用一个数据库,导致数据管理复杂

    一套完整的微服务包括自动化部署,调度,资源管理,进程隔离,自愈,构建流水线等功能,单靠SpringCloud是无法实现的,所以SpringCloud+k8s才是最好的方案

    4.为何要将SpringCloud项目部署到k8s平台?

    SpringCloud只能用在 SpringBoot的java环境中,而kubernetes可以适用于任何开发语言,只要能被放进docker的应用,都可以在kubernetes上运行,而且更轻量,更简单。

    每个微服务可以部署多个,没有多少依赖,并且有负载均衡能力,比如一个服务部署一个副本或5个副本,通过k8s可以更好的去扩展我们的应用。

    Spring提供应用的打包,Docker和Kubernetes提供部署和调度。Spring通过Hystrix线程池提供应用内的隔离,而Kubernetes通过资源,进程和命名空间来提供隔离。Spring为每个微服务提供健康终端,而Kubernetes执行健康检查,且把流量导到健康服务。Spring外部化配置并更新它们,而Kubernetes分发配置到每个微服务。

    SpringCloud很多功能都跟kubernetes重合,比如服务发现,负载均衡,配置管理,所以如果把SpringCloud部署到k8s,那么很多功能可以直接使用k8s原生的,减少复杂度。

    SpringCloud容易上手,是对开发者比较友好的平台;Kubernetes是可以实现DevOps流程的,SpringCloud和kubernetes各有优点,只有结合起来,才能发挥更大的作用,达到最佳的效果。

    5.SpringCloud项目部署到k8s的流程

    制作镜像--->控制管理pod--->暴露应用--->对外发布应用--->数据持久化---à日志/监控

    1.制作镜像: 应用程序、运行环境、文件系统

    2.控制器管理pod:deployment无状态部署、statefulset 有状态部署、Daemonset 守护进程部署、job & cronjob批处理

    3.暴露应用:服务发现、负载均衡

    4.对外发布应用:service、Ingress HTTP/HTTPS访问

    5.pod数据持久化:分布式存储-ceph和gluster

    6.日志/监控:efk、prometheus、pinpoint等

    SpringCloud组件介绍

    1. 服务发现与注册组件Eureka

    Eureka是Netflix开发的服务发现框架, SpringCloud将它集成在自己的子项目spring-cloud-netflix中,以实现SpringCloud中服务发现和注册功能。Eureka包含两个组件:Eureka Server和Eureka Client。

     

    互动:Netflix是什么?

    Netflix在SpringCloud项目中占着重要的作用,Netflix公司提供了包括Eureka、Hystrix、Zuul、Archaius等在内的很多组件,在微服务架构中至关重要。

     

    互动: 举个例子服务发现与注册

    我们在买车的时候,需要找中介,如果不找中介,我们自己去找厂商或者个人车主,这是很麻烦的,也很浪费时间,所以为了方便,我们一般去找中介公司,把我们的需求说出来,他们就会按需给我们推荐车型,我们相当于微服务架构中的消费者Consumer,中介相当于微服务架构中的提供者Provider,Consumer需要调用Provider提供的一些服务,就像是我们要买的车一样。

     

    1.1 Eureka组件

     

    Eureka Server

    Eureka Server提供服务注册中心,各个节点启动后,会将自己的IP和端口等网络信息注册到Eureka Server中,这样Eureka Server服务注册表中将会存储所有可用服务节点的信息,在Eureka的图形化界面可以看到所有注册的节点信息。

     

    Eureka Client

    Eureka Client是一个java客户端,在应用启动后,Eureka客户端将会向Eureka Server端发送心跳,默认周期是30s,如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)

     

    Eureka Client分为两个角色,分别是Application Service和Application Client

    Application Service是服务提供方,是注册到Eureka Server中的服务。

    Application Client是服务消费方,通过Eureka Server发现其他服务并消费。

    1.2 Eureka架构原理

    Register(服务注册):当Eureka客户端向Eureka Server注册时,会把自己的IP、端口、运行状况等信息注册给Eureka Server。
    Renew(服务续约):Eureka客户端会每隔30s发送一次心跳来续约,通过续约来告诉Eureka Server自己正常,没有出现问题。正常情况下,如果 Eureka Server 在90秒没有收到 Eureka 客户的续约,它会将实例从其注册表中删除。
    Cancel(服务下线):Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后,该客户端实例信息将从服务器的实例注册表中删除,防止consumer调用到不存在的服务。该下线请求不会自动完成,它需要调用以下内容:DiscoveryManager.getInstance().shutdownComponent();

    Get Registry(获取服务注册列表):获取其他服务列表。
    Replicate(集群中数据同步):eureka集群中的数据复制与同步。
    Make Remote Call(远程调用):完成服务的远程调用。

    2. 客户端负载均衡之Ribbon

    2.1 Ribbon简介

    Ribbon是一个基于HTTP和TCP的客户端负载均衡器,主要提供客户侧的软件负载均衡算法,运行在消费者端。客户端负载均衡是当浏览器向后台发出请求的时候,客户端会向Eureka Server读取注册到服务器的可用服务信息列表,然后根据设定的负载均衡策略,抉择出向哪台服务器发送请求。在客户端就进行负载均衡算法分配。Ribbon客户端组件提供一系列完善的配置选项,比如连接超时、重试、重试算法等。下面是用到的

    一些负载均衡策略:

    随机策略---随机选择server

    轮询策略---轮询选择, 轮询index,选择index对应位置的Server

    重试策略--在一个配置时间段内当选择Server不成功,则一直尝试使用subRule的方式选择一个可用的server

    最低并发策略--逐个考察server,如果server断路器打开,则忽略,再选择其中并发链接最低的server

    可用过滤策略--过滤掉一直失败并被标记为circuit tripped的server,过滤掉那些高并发链接的server(active connections超过配置的阈值)或者使用一个AvailabilityPredicate来包含过滤server的逻辑,其实就就是检查status里记录的各个Server的运行状态;

    响应时间加权重策略--根据server的响应时间分配权重,响应时间越长,权重越低,被选择到的概率也就越低。响应时间越短,权重越高,被选中的概率越高,这个策略很贴切,综合了各种因素,比如:网络,磁盘,io等,都直接影响响应时间;

    区域权重策略--综合判断server所在区域的性能,和server的可用性,轮询选择server并且判断一个AWS Zone的运行性能是否可用,剔除不可用的Zone中的所有server。

     

    互动: 举个列子说明ribbon

     

    比如我们设计了一个秒杀系统,但是为了整个系统的 高可用 ,我们需要将这个系统做一个集群,而这个时候我们消费者就可以拥有多个秒杀系统的调用途径了,如下图。

    如果这个时候我们没有进行一些 均衡操作 ,如果我们对 秒杀系统1 进行大量的调用,而另外两个基本不请求,就会导致 秒杀系统1 崩溃,而另外两个就变成了傀儡,那么我们为什么还要做集群,我们高可用体现的意义又在哪呢?

    所以 Ribbon 出现了,注意我们上面加粗的几个字——运行在消费者端 。指的是,Ribbon 是运行在消费者端的负载均衡器,如下图。

    其工作原理就是 Consumer 端获取到了所有的服务列表之后,在其内部 使用负载均衡算法 ,进行对多个系统的调用。

    2.2 Ribbon的功能

    易于与服务发现组件(比如Eureka)集成

    使用Archaius完成运行时配置

    使用JMX暴露运维指标,使用Servo发布

    多种可插拔的序列化选择

    异步和批处理操作

    自动SLA框架

    系统管理/指标控制台

    2.3 Ribbon和nginx对比分析

    区别:

    Ribbon实现的是客户端负载均衡,它可以在客户端经过一系列算法来均衡调用服务。Ribbon 工作时分两步:

    第一步:从Eureka Server中获取服务注册信息列表,它优先选择在同一个 Zone 且负载较少的 Server。

    第二步:根据用户指定的策略,在从Server取到的服务注册列表中选择一个地址,其中Ribbon提供了多种策略,例如轮询、随机等。

    Nginx是服务器端负载均衡,所有请求统一交给nginx,由nginx实现负载均衡请求转发,属于服务器端负载均衡。

    3. 服务网关Zuul

    Zuul是SpringCloud中的微服务网关,首先是一个微服务。也是会在Eureka注册中心中进行服务的注册和发现。也是一个网关,请求应该通过Zuul来进行路由。Zuul网关不是必要的,是推荐使用的。

    互动:网关是什么?

    是一个网络整体系统中的前置门户入口。请求首先通过网关,进行路径的路由,定位到具体的服务节点上。

    Zuul网关的作用:

     

    统一入口:为服务提供一个唯一的入口,网关起到外部和内部隔离的作用,保障了后台服务的安全性。

    鉴权校验:识别每个请求的权限,拒绝不符合要求的请求。

    动态路由:动态的将请求路由到不同的后端集群中。

    减少客户端与服务端的耦合:服务可以独立发展,通过网关层来做映射。

    4. 熔断器Hystrix

    Hystrix的中文名字是“豪猪”,豪猪是满身长满了刺,能够保护自己不受天敌的伤害,代表了一种防御机制,Hystrix在SpringCloud中负责服务熔断和服务降级的作用。

    什么是服务熔断?(熔断可以保护服务):

     

    在讲熔断之前先看个概念: 服务雪崩

    假设有A、B、C三个服务,服务A调用服务B和C,链路关系如下:

    假设服务C因为请求量大,扛不住请求,变得不可用,这样就是积累大量的请求,服务B的请求也会阻塞,会逐渐耗尽线程资源,使得服务B变得不可用,那么服务A在调用服务B就会出现问题,导致服务A也不可用,那么整条链路的服务调用都失败了,我们称之为雪崩。

    接下来看下服务熔断:

     

    互动:举个生活中的例子

    当电路发生故障或异常时,伴随着电流不断升高,并且升高的电流有可能能损坏电路中的某些重要器件,也有可能烧毁电路甚至造成火灾。若电路中正确地安置了保险丝,那么保险丝就会在电流异常升高到一定的高度和热度的时候,自身熔断切断电流,从而起到保护电路安全运行的作用。

    在微服务架构中,在高并发情况下,如果请求数量达到一定极限(可以自己设置阈值),超出了设置的阈值,Hystrix会自动开启服务保护功能,然后通过服务降级的方式返回一个友好的提示给客户端。假设当10个请求中,有10%失败时,熔断器就会打开,此时再调用此服务,将会直接返回失败,不再调远程服务。直到10s钟之后,重新检测该触发条件,判断是否把熔断器关闭,或者继续打开。

     

    服务降级(提高用户体验效果):

    在高并发的场景下,当服务器的压力剧增时,根据当前业务以及流量的情况,对一些服务和页面进行策略控制,对这些请求做简单的处理或者不处理,来释放服务器资源用以保证核心业务不受影响,确保业务可以正常对外提供服务,比如电商平台,在针对618、双11的时候会有一些秒杀场景,秒杀的时候请求量大,可能会返回报错标志“当前请求人数多,请稍后重试”等,如果使用服务降级,无法提供服务的时候,消费者会调用降级的操作,返回服务不可用等信息,或者返回提前准备好的静态页面写好的信息。

     

    5. API网关Springcloud Gateway

    互动: 为什么学习了网关Zuul,又要讲Spring Cloud Gateway呢?

    原因很简单,就是Spring Cloud已经放弃Zuul了。现在Spring Cloud中引用的还是Zuul 1.x版本,而这个版本是基于过滤器的,是阻塞IO,不支持长连接,spring官网上也已经没有zuul的组件了,所以给大家讲下SpringCloud原生的网关产品Gateway。

    Spring Cloud Gateway是Spring Cloud新推出的网关框架,之前是 Netflix Zuul,由spring官方基于Spring5.0,Spring Boot2.0,Project Reactor等技术开发的网关,该项目提供了一个构建在Spring Ecosystem之上的API网关,旨在提供一种简单而有效的途径来发送API,并向他们提供交叉关注点,例如:安全性,监控/指标和弹性.

    SpringCloud Gateway 特征:

    SpringCloud官方对SpringCloud Gateway 特征介绍如下:

    (1)集成 Hystrix 断路器

    (2)集成 Spring Cloud DiscoveryClient

    (3)Predicates 和 Filters 作用于特定路由,易于编写的 Predicates 和 Filters

    (4)具备一些网关的高级功能:动态路由、限流、路径重写

    从以上的特征来说,和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别,还是在底层的通信框架上。

    简单说明一下上文中的三个术语:

    1)Filter(过滤器):

    和Zuul的过滤器在概念上类似,可以使用它拦截和修改请求,并且对上游的响应,进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。

    2)Route(路由):

    网关配置的基本组成模块,和Zuul的路由配置模块类似。一个Route模块由一个 ID,一个目标 URI,一组断言和一组过滤器定义。如果断言为真,则路由匹配,目标URI会被访问。

    3)Predicate(断言):

    这是一个Java8的Predicate,可以使用它来匹配来自HTTP请求的任何内容,例如headers或参数。断言的输入类型是一个ServerWebExchange。

     Zuul和GateWay区别

    5. API网关Springcloud Gateway
    互动: 为什么学习了网关Zuul,又要讲Spring Cloud Gateway呢?
    原因很简单,就是Spring Cloud已经放弃Zuul了。现在Spring Cloud中引用的还是Zuul 1.x版本,而这个版本是基于过滤器的,是阻塞IO,不支持长连接,spring官网上也已经没有zuul的组件了,所以给大家讲下SpringCloud原生的网关产品Gateway。
    
    Spring Cloud Gateway是Spring Cloud新推出的网关框架,之前是 Netflix Zuul,由spring官方基于Spring5.0,Spring Boot2.0,Project Reactor等技术开发的网关,该项目提供了一个构建在Spring Ecosystem之上的API网关,旨在提供一种简单而有效的途径来发送API,并向他们提供交叉关注点,例如:安全性,监控/指标和弹性.
    
    SpringCloud Gateway 特征:
    SpringCloud官方对SpringCloud Gateway 特征介绍如下:
    (1)集成 Hystrix 断路器
    (2)集成 Spring Cloud DiscoveryClient
    (3)Predicates 和 Filters 作用于特定路由,易于编写的 Predicates 和 Filters
    (4)具备一些网关的高级功能:动态路由、限流、路径重写
    从以上的特征来说,和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别,还是在底层的通信框架上。
    
    简单说明一下上文中的三个术语:
    1)Filter(过滤器):
    和Zuul的过滤器在概念上类似,可以使用它拦截和修改请求,并且对上游的响应,进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
    2)Route(路由):
    网关配置的基本组成模块,和Zuul的路由配置模块类似。一个Route模块由一个 ID,一个目标 URI,一组断言和一组过滤器定义。如果断言为真,则路由匹配,目标URI会被访问。
    3)Predicate(断言):
    这是一个Java8的Predicate,可以使用它来匹配来自HTTP请求的任何内容,例如headers或参数。断言的输入类型是一个ServerWebExchange。

    6. 配置中心SpringCloud Config

    SpringCloud Config是一个解决分布式系统的配置管理方案,它包含了server和client 两个部分。 server 用来获取远程的配置信息(默认为 Git 仓库),并且以接口的形式提供出去,client 根据 server 提供的接口读取配置文件,以便于初始化自己的应用。如果配置中心出现了问题,将导致灾难性的后果,因此在生产环境下配置中心都会做集群,来保证高可用。此处配置高可用实际就是把多个配置中心(指定同一个 Git 远程仓库)注册到注册中心。

    将SpringCloud项目部署到K8S平台的注意事项

    • 1.如何进行服务发现?
    • 2.如何进行配置管理?
    • 3.如何进行负载均衡?
    • 4.如何访问k8s中的服务?
    • 5.如何通过k8s进行服务编排?
    • 6.k8s部署Spring Cloud项目的整体发布流程

    1.如何进行服务发现?

    可以通过springcloud的Eureka,也可以通过k8s自身的coredns。如果是把Springcloud项目迁移到k8s,可以使用原来的Eureka,这样可以避免开发人员对原来的代码进行大量的修改。通常情况下,我们的线上的服务在迁移到k8s环境下的时候,都是采用平滑迁移的方案。服务治理与注册中心等都是采用原先的组件。比如springcloud应用,在k8s环境下还是用原来的一套注册中心(如eureka),服务治理(hystrix,ribbon)等

    使用Kubernetes service发现pod:

    Kubernetes中的pod是有生命周期的,可以被创建、也可以被销毁,k8s中的pod可以有多组,每组pod可以称为一个微服务,那么怎么能让这些微服务相互访问呢?需要在每组pod前端有一个固定的接入层,叫做service,service解决了对后端pod进行负载均衡和自动发现的能力,但是我们怎么还需要知道service的ip,这样才能被其他服务访问,那么怎么解决这一问题呢?

    使用coredns发现service(服务):

    coredns可以解决Service的发现问题,k8s将Service的名称当做域名注册到coredns中,通过Service的名称就可以访问其提供的服务。Coredns支持的域名格式:

    <service_name>.<namespace>.svc.<cluster_domain>。

    默认的域名是<service_name>.<namespace>.svc.cluster.local

     

    2.如何进行配置管理?

    通过在k8s中部署SpringCloud Config,也可以通过k8s自带的的configmap。还可以使用spring-cloud-kubernetes进行配置管理。

     

    如果微服务架构中没有使用统一配置中心时,所存在的问题:

    配置文件分散在各个项目里,不方便维护

    配置内容安全与权限,实际开发中,开发人员是不知道线上环境的配置的

    更新配置后,项目需要重启

     

    k8s中自带的configmap怎么存配置?

    ConfigMap用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件。ConfigMap跟secret很类似,但它可以更方便地处理不包含敏感信息的字符串。

    怎么通过ConfigMap达到配置中心的作用?

    创建一个configmap资源,对应着一份配置文件,可以将该资源通过数据卷的形式映射到Pod上,这样Pod就能用上这个配置文件了 ,以管理mysql配置文件为例用下图演示:

    spring-cloud-starter-kubernetes-config

    spring-cloud-starter-kubernetes-config是spring-cloud-starter-kubernetes框架下的一个库,作用是将kubernetes的configmap与SpringCloud Config结合起来,通过spring-cloud-starter-kubernetes-config,我们的应用就像在通过SpringCloud Config取得配置信息,只不过这里的配置信息来自kubernetes的configmap,而不是SpringCloud Config server,SpringCloud Config来配置的应用几乎不用修改代码,仅仅调整了配置和依赖,就能顺利迁移到kubernetes之上,直接使用原生的配置服务,并且SpringCloud Config Server也可以不用在kubernetes上部署了。

     

    3.如何进行负载均衡?

    通过springcloud的Ribbon,也可通过k8s的service、Ingress Controller

     

    4.如何对外发布应用?

    通过Ingress

    如何通过k8s进行服务编排?

    通过编写yaml文件,对每个微服务进行发布

     

    5.k8s部署Spring Cloud项目的整体发布流程

    开发代码->提交代码到代码仓库->Jenkins调k8s API->动态生成Jenkins Slave Pod->Slave Pod拉取git上的代码->编译代码->打包镜像->推送镜像到镜像仓库harbor或者docker hub->Slave Pod工作完成之后自动删除->通过k8s编排服务发布到测试、生产平台->通过Ingress发布服务

    6.如何通过k8s进行服务编排?

    事先写好资源清单文件,然后放到gitlab,我们在调用jenkins的时候,通过pipeline里写上kubectl apply 更新yaml文件,就可以实现自动编排了。

     

  • 相关阅读:
    从 0 开始带你成为消息中间件实战高手
    jenkins升级2.249版本后 节点(Node)配置的启动方式中没有Launch agent via Java Web Star
    Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
    centOS7 gradle版本升级
    使用PDB调试Python程序
    pytest在控制台的方式下提示找不到包
    docker-compose文件详解
    storm案例分析
    strom 简单案例
    springboot实现读写分离
  • 原文地址:https://www.cnblogs.com/dahuige/p/15115109.html
Copyright © 2020-2023  润新知