阅读更多
引用

Spring Cloud作为一套微服务治理的框架,几乎考虑到了微服务治理的方方面面,之前也写过一些关于Spring Cloud文章,主要偏重各组件的使用,本次分享主要解答这两个问题:Spring Cloud在微服务的架构中都做了哪些事情?Spring Cloud提供的这些功能对微服务的架构提供了怎样的便利?

我们先来简单回顾一下,我们以往互联网架构的发展情况:

传统架构发展史

单体架构

单体架构在小微企业比较常见,典型代表就是一个应用、一个数据库、一个web容器就可以跑起来,比如我们开发的开源软件云收藏,就是标准的单体架构。

在两种情况下可能会选择单体架构:一是在企业发展的初期,为了保证快速上线,采用此种方案较为简单灵活;二是传统企业中垂直度较高,访问压力较小的业务。在这种模式下对技术要求较低,方便各层次开发人员接手,也能满足客户需求。

下面是单体架构的架构图:

在单体架构中,技术选型非常灵活,优先满足快速上线的要求,也便于快速跟进市场。

垂直架构

在单体架构发展一段时间后,公司的业务模式得到了认可,交易量也慢慢的大起来,这时候有些企业为了应对更大的流量,就会对原有的业务进行拆分,比如说:后台系统、前端系统、交易系统等。

在这一阶段往往会将系统分为不同的层级,每个层级有对应的职责,UI层负责和用户进行交互、业务逻辑层负责具体的业务功能、数据库层负责和上层进行数据交换和存储。

下面是垂直架构的架构图:

在这个阶段SSH(struts+spring+hibernate)是项目的关键技术,Struts负责web层逻辑控制、Spring负责业务层管理Bean、Hibernate负责数据库操作进行封装,持久化数据。

服务化架构

如果公司进一步的做大,垂直子系统会变的越来越多,系统和系统之间的调用关系呈指数上升的趋势。在这样的背景下,很多公司都会考虑服务的SOA化。SOA代表面向服务的架构,将应用程序根据不同的职责划分为不同的模块,不同的模块直接通过特定的协议和接口进行交互。这样使整个系统切分成很多单个组件服务来完成请求,当流量过大时通过水平扩展相应的组件来支撑,所有的组件通过交互来满足整体的业务需求。

SOA服务化的优点是,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。

服务化架构是一套松耦合的架构,服务的拆分原则是服务内部高内聚,服务之间低耦合。

下面是服务化架构图:

在这个阶段可以使用WebService或者dubbo来服务治理。

SOA和微服务架构

SOA和微服务的区别

其实服务化架构已经可以解决大部分企业的需求了,那么我们为什么要研究微服务呢?先说说它们的区别;
  • 微服务架构强调业务系统需要彻底的组件化和服务化,一个组件就是一个产品,可以独立对外提供服务
  • 微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
  • 微服务强调每个微服务都有自己独立的运行空间,包括数据库资源。
  • 微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行
  • 微服务的切分粒度会更小
总结:微服务架构是 SOA 架构思想的一种扩展,更加强调服务个体的独立性、拆分粒度更小。

为什么考虑Spring Cloud
  • Spring Cloud来源于Spring,质量、稳定性、持续性都可以得到保证
  • Spirng Cloud天然支持Spring Boot,更加便于业务落地。
  • Spring Cloud发展非常的快,从16年开始接触的时候相关组件版本为1.x,到现在将要发布2.x系列
  • Spring Cloud是Java领域最适合做微服务的框架。
  • 相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大。
  • 对于中小企业来讲,使用门槛较低。
Spring Cloud 是微服务架构的最佳落地方案

它的特性

以下为Spring Cloud的核心特性:
  • 分布式/版本化配置
  • 服务注册和发现
  • 路由
  • 服务和服务之间的调用
  • 负载均衡
  • 断路器
  • 分布式消息传递
这些特性都是由不同的组件来完成,在架构的演进过程中扮演着重要的角色,接下来我们一起看看。

微服务架构

Spring Cloud解决的第一个问题就是:服务与服务之间的解耦。很多公司在业务高速发展的时候,服务组件也会相应的不断增加。服务和服务之间有着复杂的相互调用关系,经常有服务A调用服务B,服务B调用服务C和服务D ...,随着服务化组件的不断增多,服务之间的调用关系成指数级别的增长,极端情况下就如下图所示:

这样最容易导致的情况就是牵一发而动全身。经常出现由于某个服务更新而没有通知到其它服务,导致上线后惨案频发。这时候就应该进行服务治理,将服务之间的直接依赖转化为服务对服务中心的依赖。Spring Cloud 核心组件Eureka就是解决这类问题。

Eureka

Eureka是Netflix开源的一款提供服务注册和发现的产品,它提供了完整的Service Registry和Service Discovery实现。也是Spring Cloud体系中最重要最核心的组件之一。

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

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

因此使用了Eureka就自动具有了注册中心、负载均衡、故障转移的功能。

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. 监控的效果图如下:

配置中心

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

Spring Cloud Config

Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分,Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去,Client通过接口获取数据、并依据此数据初始化自己的应用。

其实就是Server端将所有的配置文件服务化,需要配置文件的服务实例去Config Server获取对应的数据。将所有的配置文件统一整理,避免了配置文件碎片化。

如果服务运行期间改变配置文件,服务是不会得到最新的配置信息,需要解决这个问题就需要引入Refresh。可以在服务的运行期间重新加载配置文件。

当所有的配置文件都存储在配置中心的时候,配置中心就成为了一个非常重要的组件。如果配置中心出现问题将会导致灾难性的后果,因此在生产中建议对配置中心做集群,来支持配置中心高可用性。

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可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。

Zipkin是Twitter的一个开源项目,允许开发者收集 Twitter 各个服务上的监控数据,并提供查询接口

总结

我们从整体上来看一下Spring Cloud各个组件如何来配套使用:

从上图可以看出Spring Cloud各个组件相互配合,合作支持了一套完整的微服务架构。
  • 其中Eureka负责服务的注册与发现,很好将各服务连接起来
  • Hystrix 负责监控服务之间的调用情况,连续多次失败进行熔断保护。
  • Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况,并给予图形化的展示
  • Spring Cloud Config 提供了统一的配置中心服务
  • 当配置文件发生变化的时候,Spring Cloud Bus 负责通知各服务去获取最新的配置信息
  • 所有对外的请求和服务,我们都通过Zuul来进行转发,起到API网关的作用
  • 最后我们使用Sleuth+Zipkin将所有的请求数据记录下来,方便我们进行后续分析
Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来,方便我们系统架构演进的过程中,可以合理的选择需要的组件进行集成,从而在架构演进的过程中会更加平滑、顺利。

微服务架构是一种趋势,Spring Cloud提供了标准化的、全站式的技术方案,意义可能会堪比当前Servlet规范的诞生,有效推进服务端软件系统技术水平的进步。
  • 大小: 44.5 KB
  • 大小: 60 KB
  • 大小: 121.1 KB
  • 大小: 484 KB
  • 大小: 63.5 KB
  • 大小: 16.2 KB
  • 大小: 145.5 KB
  • 大小: 56.9 KB
  • 大小: 25.4 KB
  • 大小: 54.6 KB
  • 大小: 45.6 KB
来自: GitChat
6
0
评论 共 4 条 请登录后发表评论
4 楼 loveminer 2017-11-10 10:50
很赞。   
3 楼 dick1305 2017-11-02 19:30
写的错。学习。
2 楼 ityouknow 2017-11-02 08:38
我的文章。
1 楼 sxdtzhaoxinguo 2017-11-01 14:39
总结的不错,看完,基本了解了Spring Cloud的主要内容!

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • 从架构演进的角度聊聊Spring Cloud都做了些什么

    1、从架构演进的角度聊聊Spring Cloud都做了些什么?2、中小型互联网公司微服务实践-经验和教训 3、Spring Cloud在国内中小型公司能用起来吗? 

  • 从架构演进的角度聊聊Spring Cloud都做了些什么?

    我们从整体上来看一下Spring Cloud各个组件如何来配套使用:从上图可以看出Spring Cloud各个组件相互配合,合作支持了一套完整的微服务架构。其中Eureka负责服务的注册与发现,很好将各服务连接起来Hystrix 负责监控...

  • 从架构演进的角度聊聊spring cloud都做了些什么?

    Spring Cloud作为一套微服务治理的框架,几乎考虑到了微服务治理的方方面面,之前也写过一些关于Spring Cloud文章,主要偏重各组件的使用,本次分享主要解答这两个问题:Spring Cloud在微服务的架构中都做了哪些事情...

  • 从架构演进的角度聊聊Spring Cloud做了些什么?

    传统架构发展史 单体架构 单体架构在小微企业比较常见,典型代表就是一个应用、一个数据库、一个web容器就可以跑起来,比如我们开发的开源软件云收藏,就是标准的单体架构。 在两种情况下可能会选择单体架构:一...

  • 第11讲:深入理解指针(1).pdf

    第11讲:深入理解指针(1)

  • springboot整合 freemarker方法

    springboot整合 freemarker方法

  • 第14讲:深入理解指针(4).pdf

    第14讲:深入理解指针(4)

  • 同行者4.1.2语音助手

    《同行者4.1.2语音助手:车机版安装详解》 在现代科技日新月异的时代,智能车载设备已经成为了汽车生活的重要组成部分。"同行者4.1.2"便是这样一款专为车机设计的语音助手,旨在提供更为便捷、安全的驾驶体验。该版本针对掌讯全系列设备进行了兼容优化,让车主能够轻松实现语音控制,减少驾驶过程中的手动操作,提升行车安全性。 我们来了解下"同行者4.1.2"的核心功能。这款语音助手集成了智能语音识别技术,用户可以通过简单的语音指令完成导航、音乐播放、电话拨打等一系列操作,有效避免了因操作手机或车机带来的分心。此外,其强大的语义理解和自学习能力,使得它能逐步适应用户的口音和习惯,提供更个性化的服务。 在安装过程中,用户需要注意的是,"同行者4.1.2"包含了四个核心组件,分别是: 1. TXZCore.apk:这是同行者语音助手的基础框架,包含了语音识别和处理的核心算法,是整个应用运行的基础。 2. com.txznet.comm.base.BaseApplication.apk:这个文件可能包含了应用的公共模块和基础服务,为其他组件提供支持。 3. TXZsetting.apk:这

  • 市场拓展主管绩效考核表.xls

    市场拓展主管绩效考核表

  • “线上购车3D全方位体验:汽车模型展示与个性化定制功能”,three.js案例- 线上购车3d展示(源码) 包含内容:1.汽车模型展示;2.汽车肤;3.轮毂部件更;4.开关车门动画;5.汽车尺寸测量

    “线上购车3D全方位体验:汽车模型展示与个性化定制功能”,three.js案例- 线上购车3d展示(源码) 包含内容:1.汽车模型展示;2.汽车肤;3.轮毂部件更;4.开关车门动画;5.汽车尺寸测量;6.自动驾驶;7.镜面倒影;8.hdr运用;9.移动端适配; 本为html+css+three.js源码 ,核心关键词:three.js案例; 线上购车3D展示; 汽车模型展示; 汽车换肤; 轮毂部件更换; 开关车门动画; 汽车尺寸测量; 自动驾驶; 镜面倒影; HDR运用; 移动端适配; HTML+CSS+three.js源码。,"Three.js源码:线上购车3D展示案例,含汽车模型、换肤、轮毂更换等九大功能"

  • (数据权威)中国城市_县域统计面板数据二合一

    数据名称:2000-2022年各县市区主要社会经济发展指标面板数据 数据类型:dta格式 数据来源:中国县域统计

  • 120页-环卫车项目初步方案.pdf

    一、智慧环卫管理平台的建设背景与目标 智慧环卫管理平台的建设源于对环卫管理全面升级的需求。当前,城管局已拥有139辆配备车载GPS系统、摄像头和油耗传感器的环卫车辆,但环卫人员尚未配备智能移动终端,公厕也缺乏信息化系统和智能终端设备。为了提升环卫作业效率、实现精细化管理并节省开支,智慧环卫管理平台应运而生。该平台旨在通过信息化技术和软硬件设备,如车载智能终端和环卫手机App,实时了解环卫人员、车辆的工作状态、信息和历史记录,使环卫作业管理透明化、精细化。同时,平台还期望通过数据模型搭建和数据研读,实现更合理的环卫动态资源配置,为环卫工作的科学、健康、持续发展提供决策支持。 二、智慧环卫管理平台的建设内容与功能 智慧环卫管理平台的建设内容包括运行机制体制建设、业务流程设计、智慧公厕系统建设、网络建设、主机和储存平台需求、平台运维管理体系、硬件标准规范体系以及考核评价体系等多个方面。其中,智慧公厕系统建设尤为关键,它能实时监控公厕运行状态,保障公厕的清洁和正常运行。平台建设还充分利用了现有的电子政务网络资源,并考虑了有线和无线网络的需求。在功能上,平台通过普查、整合等手段全面收集环卫车辆、企业、人员、设施、设备等数据,建立智慧环卫基础数据库。利用智能传感、卫星定位等技术实现环卫作业的在线监管和远程监控,实现对道路、公共场所等的作业状况和卫生状况的全面监管。此外,平台还建立了环卫作业网格化管理责任机制,实现从作业过程到结果的全面监管,科学评价区域、部门、单位和人员的作业效果。 三、智慧环卫管理平台的效益与风险规避 智慧环卫管理平台的建设将带来显著的环境、经济和管理效益。环境方面,它将有力推进环境卫生监管服务工作,改善环境卫生状况,为人民群众创造更加清洁、卫生的工作和生活环境。经济方面,通过智慧化监管,大大降低了传统管理手段的成本,提高了监管的准确性和效率。管理方面,平台能够追踪溯源市民反映的问题,如公厕异味、渣土车辆抛洒等,并找到相应的责任单位进行处置,防止类似事件再次发生。同时,平台还拥有强大的预警机制功能,能够在很多环卫问题尚未出现前进行处置。然而,平台建设也面临一定的风险,如部门协调、配合问题,建设单位选择风险以及不可预测的自然灾害等。为了规避这些风险,需要加强领导、统一思想,选择优秀的系统集成商承接项目建设,并做好计算机和应用系统的培训工作。同时,也要注意标准制定工作和相关法律法规的制定工作,以保证系统建设完成后能够真正为环卫管理工作带来便利。

  • 36 -企业管理主管绩效考核表1.xlsx

    36 -企业管理主管绩效考核表1

  • 1.1 -1.4 工程代码

    1.1 -1.4 工程代码

  • USDT合约,USDT智能合约

    USDT合约,USDT智能合约

  • 基于姿态估计三维人脸形状重建.pdf

    基于姿态估计三维人脸形状重建.pdf

  • 一般员工绩效考核表模板(通用版) (2).xls

    一般员工绩效考核表模板(通用版) (2)

  • 全国295个地级市2011-2022互联网宽带接入用户数互联网普及率(数据权威)

    全国各省295地级市互联网普及率、互联网用户数、每百人互联网宽带用户(2011-2022年) 数据年份:2011-2022年(2022存在部分缺失) 数据范围:全国各省295个地级市 数据来源:地方统计局

  • (数据权威)碳排放、碳中和、碳交易、碳金融、碳计算、碳建模资料

    一、各省、分行业CO2排放、283个地级市碳排放及计算过程 2.分行业二氧化碳排放量 在这里插入图片描述 3、280多个地级市碳排放及计算过程 二、碳中和文献、最新政策、碳金融数据+数学建模 1.二氧化碳减排规划,碳金融数据收集及数学建模 2.碳中和政策和下载量最高的碳中和论文 三、碳排放+碳市场+碳交易+碳中和+碳排放核算Excel自动计算表 全行业碳排放核算Excel自动计算表 四、碳交易数据 五、主要能源碳排放计算参数

Global site tag (gtag.js) - Google Analytics