SpringCloud升级之路2020.0.x版-1.背景

SpringCloud升级之路2020.0.x版-1.背景_第1张图片

本系列为之前系列的整理重启版,随着项目的发展以及项目中的使用,之前系列里面很多东西发生了变化,并且还有一些东西之前系列并没有提到,所以重启这个系列重新整理下,欢迎各位留言交流,谢谢!~

SpringCloud升级之路2020.0.x版-1.背景_第2张图片

Spring Cloud 官方文档说了,它是一个完整的微服务体系,用户可以通过使用 Spring Cloud 快速搭建一个自己的微服务系统。那么 Spring Cloud 究竟是如何使用的呢?他到底有哪些组件?

spring-cloud-commons组件里面,就有 Spring Cloud 默认提供的所有组件功能的抽象接口,有的还有默认实现。目前的 2020.0.x (按照之前的命名规则应该是 iiford),也就是spring-cloud-commons-3.0.x包括:

  • 服务发现DiscoveryClient,从注册中心发现微服务。
  • 服务注册ServiceRegistry,注册微服务到注册中心。
  • 负载均衡LoadBalancerClient,客户端调用负载均衡。其中,重试策略spring-cloud-commons-2.2.6加入了负载均衡的抽象中。
  • 断路器CircuitBreaker,负责什么情况下将服务断路并降级
  • 调用 http 客户端:内部 RPC 调用都是 http 调用

然后,一般一个完整的微服务系统还包括:

  1. 统一网关
  2. 配置中心
  3. 全链路监控与监控中心

Spring Cloud 一直处于非常活跃,非常快速迭代的过程,并且 Spring Cloud 高度依赖 Spring Boot,Spring Boot 与 Spring Cloud 相辅相成。但是,快速迭代带来的不只是新功能的引入以及原有功能的优化,还有就是升级过程中带来了很多兼容性,功能性,完整性,稳定性的烦恼。本系列旨在帮助广大读者了解不同大版本 Spring Boot & Spring Cloud 的特性功能以及底层原理的同时,使用这些组件实现一个具有完整功能的微服务体系,同时这个体系会适应目前最新的云原生环境。

SpringCloud升级之路2020.0.x版-1.背景_第3张图片

我们使用的是目前最流行的 Docker + Kubernetes 的组合。目前一般微服务架构,都不会直接使用物理机,因为现代的互联网业务一般都具有这样的特性(我们拿电子商城举例):

  • 业务会在某一时刻开始突然开始快速增长,例如我们开始在各地投放广告,用户不断进入网站,随着口碑不断变好,用户增长速度越来越快。
  • 业务在一段时间内,有高峰有低谷。例如在一天内,白天一般都在上班,晚上访问网站下单的人数比较多。
  • 业务在一段时间内,最高峰与最低峰之间的差距随着业务增长越来越大。由于大部分用户都在晚上访问网站下单,导致白天和晚上的流量相差越来越大。
  • 会突然出现流量尖峰,并且很难预测这个时间点以及估计量。例如双 11 促销的时候,人们大量涌入,很难能估计的好会有多少流量。还有就是突然大家需要某个商品的时候,例如新冠刚开始的时候,口罩抢购一空。

对于这些特性,根据业务压力,智能并且快速动态扩容缩容这个功能变得越来越重要,但是这个功能在直接部署业务到物理机上很难实现。这时候出现了虚拟机,将物理机虚拟化抽象成多个虚拟机,比如 vmware 和 openstack,我们可以使用虚拟机在我们的操作系统中模拟出多台子电脑,子电脑之间是相互隔离的,这样可以更细致动态的分配物理机的资源。但是虚拟机对于开发和运维人员而言,还是太过于笨重了,存在启动慢,占用空间大,不易迁移的缺点。
接着,容器化技术应运而生,它不需要虚拟出整个操作系统,只需要虚拟一个小规模的环境即可,而且启动速度很快,除了运行其中应用以外,基本不消耗额外的系统资源。Docker 是应用最为广泛的容器技术,通过打包镜像,启动容器来创建一个服务。但是随着应用越来越复杂,容器的数量也越来越多,由此衍生了管理运维容器的这个重要场景。这个场景目前最流行的解决方案就是 Kubernetes(k8s)。

Kubernetes 能为我们提供如下功能:

  1. 容器编排与管理,机器资源管理以及存储卷挂载
  2. 服务的健康检查以及自愈
  3. 服务弹性扩容
  4. 配置中心
  5. 服务发现与调度
  6. 负载均衡

SpringCloud升级之路2020.0.x版-1.背景_第4张图片

在我们公司中,项目团队包括了运维团队以及后端开发团队。对于 Docker 镜像打包与管理以及对于 K8s 的开发维护部署,主要交给运维团队。微服务业务开发维护,实现微服务特性的框架的开发维护是交给后端开发团队的。所以对于 K8s 的功能,我们只使用了前三个,对于配置中心服务发现与调度还有负载均衡,我们还是主要交给实现微服务特性的框架实现的,未来可能会将这三个功能使用起来。

微服务框架需要考虑与 K8s 的交互,主要是服务的健康检查以及自愈以及服务弹性扩容

  • 服务的健康检查以及自愈:K8s 可以通过检查端口是否被监听使用,调用 http 接口来检查进程是否启动以及进程的健康性,我们需要提供这种健康检查接口。主要通过 spring boot 的 actuator 实现
  • 服务弹性扩容:K8s 需要获取进程的监控指标来决定是否需要扩容,并且我们也需要监控中心采集这些指标。我们主要通过 grafana(监控中心) + prometheus(采集指标) + actuator(暴露接口) 实现。

SpringCloud升级之路2020.0.x版-1.背景_第5张图片

本篇主要交代了我们使用 Spring Cloud 作为我们微服务框架的背景以及底层的云组件和功能边界,接下来我们会继续介绍我们要使用微服务框架实现的功能,以及包含的组件和使用中要考虑的问题。

微信搜索“我的编程喵”关注公众号,每日一刷,轻松提升技术,斩获各种offer

SpringCloud升级之路2020.0.x版-1.背景_第6张图片

你可能感兴趣的:(spring-cloud)