专栏目录
44.避免链路信息丢失做的设计(2) 37. 实现异步的客户端封装配置管理的意义与设计 41. SpringCloudGateway 基本流程讲解(1) 42.SpringCloudGateway 现有的可供分析的请求日志以及缺陷 4.maven依赖回顾以及项目框架结构 39. 改造 resilience4j 粘合 WebClient 45. 实现公共日志记录 13.UnderTow 核心配置 5.所有项目的parent与spring-framework-common说明 30. FeignClient 实现重试 35. 验证线程隔离正确性 11.Log4j2 监控相关 23.订制Spring Cloud LoadBalancer 38. 实现自定义 WebClient 的 NamedContextFactory 14.UnderTow AccessLog 配置介绍 21.Spring Cloud LoadBalancer简介 41. SpringCloudGateway 基本流程讲解(2) 40. spock 单元测试封装的 WebClient(下) 20. 启动一个 Eureka Server 集群 17.Eureka的实例配置 15.UnderTow 订制 18.Eureka的客户端核心设计和配置 28.OpenFeign的生命周期-进行调用 22.Spring Cloud LoadBalancer核心源码 16.Eureka架构和核心概念 44.避免链路信息丢失做的设计(1) 40. spock 单元测试封装的 WebClient(上) 8.理解 NamedContextFactory 3.Eureka Server 与 API 网关要考虑的问题 26.OpenFeign的组件 10.使用Log4j2以及一些核心配置 27.OpenFeign的生命周期-创建代理 33. 实现重试、断路器以及线程隔离源码 43.为何 SpringCloudGateway 中会有链路信息丢失 19.Eureka的服务端设计与配置 29.Spring Cloud OpenFeign 的解析(1) 24.测试Spring Cloud LoadBalancer 1. 背景 25.OpenFeign简介与使用 12.UnderTow 简介与内部原理 7.从Bean到SpringCloud 2.微服务框架需要考虑的问题 6.微服务特性相关的依赖说明 34.验证重试配置正确性 32. 改进负载均衡算法 36. 验证断路器正确性 31. FeignClient 实现断路器以及线程隔离限流的思路 9.如何理解并定制一个Spring Cloud组件

1. 背景

unknown
• 阅读 1338

1. 背景

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

1. 背景

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 的特性功能以及底层原理的同时,使用这些组件实现一个具有完整功能的微服务体系,同时这个体系会适应目前最新的云原生环境。

1. 背景

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

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

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

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

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

1. 背景

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

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

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

1. 背景

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

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

1. 背景

点赞
收藏
评论区
推荐文章

暂无数据

unknown
unknown
Lv1
男 · rrrr · rrrrrrrr
rrrrr
文章
0
粉丝
17
获赞
0
热门文章

暂无数据