用SpringCloud进行微服务架构演进

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介:   在《架构师必须要知道的阿里的中台战略与微服务》 中已经阐明选择SpringCloud进行微服务架构实现中台战略,因此下面介绍SpringCloud的一些内容,SpringCloud已经出来了很多年,网上资料一大堆,这里推荐 程序猿DD 的博客http://blog.didispace.com/  关于SpringCloud微服务各组件内容等做了非常详细的介绍,适合入门的来学习。

  在《架构师必须要知道的阿里的中台战略与微服务》 中已经阐明选择SpringCloud进行微服务架构实现中台战略,因此下面介绍SpringCloud的一些内容,SpringCloud已经出来了很多年,网上资料一大堆,这里推荐 程序猿DD 的博客http://blog.didispace.com/  关于SpringCloud微服务各组件内容等做了非常详细的介绍,适合入门的来学习。

  Spring Cloud是基于Spring Boot的,因此还在使用SpringMVC的同学要先了解Spring Boot。先上一段官话,Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中涉及的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发框架。

  Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud全家桶

  上面的图是Spring Cloud的全家桶,包罗万象,犹如水电,涉及到开发的方方页面。

  Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。

首先是核心服务治理的组件(服务注册与发现)Spring Cloud Eureka

  Eureka是Netflix开源的一款提供服务注册和发现的产品,Eureka就是一个服务中心,将所有的可以提供的服务都注册到它这里来管理,其它各调用者需要的时候去注册中心获取,然后再进行调用,避免了服务之间的直接调用,方便后续的水平扩展、故障转移等。如下图:

当然服务中心这么重要的组件一但挂掉将会影响全部服务,因此需要搭建Eureka集群来保持高可用性,生产中建议最少两台。随着系统的流量不断增加,需要根据情况来扩展某个服务,Eureka内部已经提供均衡负载的功能,只需要增加相应的服务端实例既可。那么在系统的运行期间某个实例挂了怎么办?Eureka内容有一个心跳检测机制,如果某个实例在规定的时间内没有进行通讯则会自动被剔除掉,避免了某个实例挂掉而影响服务。
因此使用了Eureka就自动具有了注册中心、负载均衡、故障转移的功能。

  当然还有另外一个实现组件Spring Cloud Consul,这里不做多介绍。

  随着微服务不断的增多,每个微服务都有自己对应的配置文件。在研发过程中有测试环境、UAT环境、生产环境,因此每个微服务又对应至少三个不同环境的配置文件。这么多的配置文件,如果需要修改某个公共服务的配置信息,如:缓存、数据库等,难免会产生混乱,这个时候就需要引入Spring Cloud另外一个组件:Spring Cloud Config。

Spring Cloud Config

  Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分,其实就是Server端将所有的配置文件服务化,需要配置文件的服务实例去Config Server获取对应的数据。将所有的配置文件统一整理,避免了配置文件碎片化。

  如果服务运行期间改变配置文件,服务是不会得到最新的配置信息,需要解决这个问题就需要引入Refresh。可以在服务的运行期间重新加载配置文件,当所有的配置文件都存储在配置中心的时候,配置中心就成为了一个非常重要的组件。如果配置中心出现问题将会导致灾难性的后果,因此在生产中建议对配置中心做集群,来支持配置中心高可用性。

Hystrix

  在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应。

  如下图所示:A作为服务提供者,B为A的服务消费者,C和D是B的服务消费者。A不可用引起了B的不可用,并将不可用像滚雪球一样放大到C和D时,雪崩效应就形成了。

 

  在这种情况下就需要整个服务机构具有故障隔离的功能,避免某一个服务挂掉影响全局。在Spring Cloud 中Hystrix组件就扮演这个角色。

  Hystrix会在某个服务连续调用N次不响应的情况下,立即通知调用端调用失败,避免调用端持续等待而影响了整体服务。Hystrix间隔时间会再次检查此服务,如果服务恢复将继续提供服务。

Hystrix Dashboard和Turbine

  当熔断发生的时候需要迅速的响应来解决问题,避免故障进一步扩散,那么对熔断的监控就变得非常重要。熔断的监控现在有两款工具:Hystrix-dashboard和Turbine。

  Hystrix-dashboard是一款针对Hystrix进行实时监控的工具,通过Hystrix Dashboard我们可以直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。但是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine. 监控的效果图如下:

Spring Cloud Bus消息总线

  Refresh方案虽然可以解决单个微服务运行期间重载配置信息的问题,但是在真正的实践生产中,可能会有N多的服务需要更新配置,如果每次依靠手动Refresh将是一个巨大的工作量,这时候Spring Cloud提出了另外一个解决方案:Spring Cloud Bus
Spring Cloud Bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化(例如配置变化)或者其它的消息指令中。Spring Cloud Bus的一个核心思想是通过分布式的启动器对Spring Boot应用进行扩展,也可以用来建立一个或多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道。
Spring Cloud Bus是轻量级的通讯组件,也可以用在其它类似的场景中。有了Spring Cloud Bus之后,当我们改变配置文件提交到版本库中时,会自动的触发对应实例的Refresh,具体的工作流程如下:

服务网关

  在微服务架构模式下,后端服务的实例数一般是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑,通常会引入API Gateway作为轻量级网关,同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。 

  Spring Cloud体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分,提供动态路由,监控,弹性,安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。它的具体作用就是服务转发,接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口,同时也可以在网关做一些权限校验等类似的功能。

链路跟踪

  随着服务的越来越多,对调用链的分析会越来越复杂,如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等,对这些信息进行监控就成为一个问题。在实际的使用中我们需要监控服务和服务之间通讯的各项指标,这些数据将是我们改进系统架构的主要依据。因此分布式的链路跟踪就变的非常重要,Spring Cloud也给出了具体的解决方案:Spring Cloud Sleuth和Zipkin

  Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。分布式链路跟踪需要Sleuth+Zipkin结合来实现,当然实现链路追踪的还有三方开源方案,如果zipkin实现的功能非常简单,图形化能力也不强,所以可以试试其它的方案,如pinpoint较成熟的框架等。

Feign

  声明式远程调度组件。

Ribbon

  负载均衡组件

Spring Cloud Data Flow

  大数据操作组件,它是Spring XD的替代品,也是一个混合计算模型,可以通过命令行的方式操作数据流

Spring Cloud Task

  组件基于Spring Tsak,提供任务调度和任务管理的功能

  以上只介绍经常用到非常重要的内容,一般的技术栈为 SpringCloud +GitLab+Jinkins进行普通服务的开发持续集成部署CI,后面可升级用SpingCloud +GitLab+Jinkins+Docker容器化布署,进一步升级到用 SpingCloud +GitLab+Jinkins+Docker+k8s自动化容器编排内容,这里的难度等级就完全不一样了,而且每一个组件都涉及到很多内容,传统业务如何进行微服务的拆分下次再进行讨论。 

相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
1天前
|
监控 持续交付 数据安全/隐私保护
Python进行微服务架构的监控
【6月更文挑战第16天】
12 5
Python进行微服务架构的监控
|
1天前
|
监控 Cloud Native 持续交付
云原生时代的微服务架构演进
【6月更文挑战第21天】随着云计算技术的不断成熟,云原生概念逐渐成为IT行业的新宠。本文将聚焦于云原生环境下的微服务架构,探讨其在设计哲学、技术选型和部署策略上的演进。我们将通过分析微服务架构的核心原则及其与容器化、持续集成/持续部署(CI/CD)和DevOps实践的结合,来揭示如何构建一个高效、可靠且易于维护的分布式系统。
|
1天前
|
存储 消息中间件 数据库
分布式系统详解--架构简介(微服务)
分布式系统详解--架构简介(微服务)
7 0
|
1天前
|
负载均衡 API 开发者
深入理解微服务架构中的API网关模式
在微服务架构中,API网关不仅仅是一个请求转发的节点,它承担着请求路由、负载均衡、认证授权、限流熔断等关键职责。本文将深入探讨API网关的设计原则、实现技术以及在实际部署中的最佳实践,帮助开发者构建一个高效、安全且可扩展的微服务入口。
|
1天前
|
存储 Prometheus 监控
云原生架构下的微服务治理之道
在数字化转型的大潮中,云原生技术以其弹性、可扩展和高度自动化的特点成为企业IT架构升级的首选。本文将深入探讨云原生架构下微服务治理的核心要素,包括服务发现、配置管理、流量控制等关键问题,旨在为读者提供一套系统的微服务治理策略。通过分析云原生环境下的微服务特点,结合具体的技术和工具,文章将为构建高效、稳定、易于管理的微服务系统提供实践指导。
|
1天前
|
监控 Cloud Native 安全
云原生架构下的微服务治理实践
本文旨在深入探讨在云原生环境下,如何有效实施微服务治理。通过分析微服务架构的核心价值与挑战,结合具体的云平台工具和最佳实践,文章详细阐述了服务发现、配置管理、弹性设计等关键治理策略。此外,文章还提供了关于如何在保障系统可观测性的同时,确保安全性和合规性的实用建议。读者将获得一套完整的微服务治理框架,以及在云原生旅程中应对复杂问题的能力提升。
|
1天前
|
运维 监控 Cloud Native
探索云原生架构的未来:容器化与微服务
在数字化浪潮的推动下,云原生技术正迅速成为企业数字化转型的核心。本文将深入探讨云原生架构的关键组成部分——容器化和微服务,并分析它们如何共同塑造着现代软件的开发、部署和运维。我们将从容器的基本概念出发,逐步解析微服务架构的设计原则,以及它们如何适应快速变化的市场需求。通过实际案例,我们还将揭示云原生技术带来的挑战与机遇,为读者提供一幅云原生技术发展的全景图。
|
1天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理实践
在云计算的浪潮中,云原生架构以其弹性、可扩展性及高效的资源利用成为企业数字化转型的首选。本文将深入探讨云原生环境下微服务的治理策略,包括服务发现、配置管理、流量控制等关键组件的应用,并通过案例分析展示如何构建健壮、灵活的微服务系统。
6 0
|
3天前
|
运维 监控 Cloud Native
云原生时代的微服务架构演进
【6月更文挑战第19天】在数字化转型的浪潮下,云原生技术成为支撑现代应用架构的关键力量。本文将探讨微服务架构在云原生环境下的演进路径,分析其设计理念的转变,以及如何借助容器化、自动化和服务网格等技术实现高效的微服务治理。文章旨在为开发者和架构师提供实践指导,帮助他们构建更加灵活、可扩展的应用系统。
|
2天前
|
存储 消息中间件 运维
从单体到微服务:架构演进中的技术挑战与解决方案
在软件开发的过程中,系统架构的选择对项目的成功与否起到至关重要的作用。本文将深入探讨从单体架构向微服务架构演进过程中所遇到的技术挑战,并提供相应的解决方案。
17 0