【Spring Cloud系列学习】02.微服务实现框架(常用)

最新推荐文章于 2023-10-06 17:36:33 发布

米殇粟

最新推荐文章于 2023-10-06 17:36:33 发布

阅读量467

点赞数 1

分类专栏： springcloud 文章标签：微服务 springcloud

本文链接：https://blog.csdn.net/jianmingxie/article/details/88707388

版权

springcloud 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

4.3Hystrix Dashboard(仪表盘)和Turbine

4.4Spring Cloud Config(配置中心)

4.5Spring Cloud Bus(消息总线)

微服务是SOA发展后的产物，SOA是为了各功能（服务）间松耦合所诞生的，是一种粗粒度、松耦合服务架构，而微服务则是在此基础上，更为细粒度的服务架构。

前言

主流的微服务框架

Spring Cloud当然是目前的主流，使用最为广泛的也是它，Dubbo则是更偏向SOA的开源的分布式服务框架。两者的好处与地位当然不用说，前者为Spring全家桶的一员，能够完美兼容所有的Spring框架，后者则是阿里巴巴的开源框架，性能极高。但是两者都有所缺陷，它们只是Dev层的框架，缺少DevOps的整体解决方案（这正是微服务架构需要关注的），没有多语言的支持。所以，新生代的微服务架构——Service Mesh出现了。

一、Dubbo

略

二、spring Cloud

1.简介

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

2.优点及特性

2.1优点

Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证
Spring Cloud天然支持Spring Boot，更加便于业务落地。
Spring Cloud发展非常的快，2.x系列虽然闭源，但并不影响使用，更多的是使用1.x系列，
Spring Cloud是Java领域最适合做微服务的框架。
相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大。
对于中小企业来讲，使用门槛较低。

Spring Cloud 是微服务架构的最佳落地方案

2.2特性

分布式/版本化配置
服务注册和发现
路由
服务和服务之间的调用
负载均衡
断路器
分布式消息传递

这些特性都是由不同的组件来完成，在架构的演进过程中扮演着重要的角色。

3.总体框架

待填图

4.总体了解springcloud

Spring Cloud作为一套微服务治理的框架，几乎考虑到了微服务治理的方方面面，Spring Cloud在微服务的架构中都做了哪些事情？Spring Cloud提供的这些功能对微服务的架构提供了怎样的便利？

Spring Cloud解决的第一个问题就是：服务与服务之间的解耦。很多公司在业务高速发展的时候，服务组件也会相应的不断增加。服务和服务之间有着复杂的相互调用关系，经常有服务A调用服务B，服务B调用服务C和服务D …，随着服务化组件的不断增多，服务之间的调用关系成指数级别的增长。这样最容易导致的情况就是牵一发而动全身。
经常出现由于某个服务更新而没有通知到其它服务，导致上线后惨案频发。这时候就应该进行服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖。Spring Cloud 核心组件Eureka等就是解决这类问题。

4.1Eureka

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

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

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

补充知识点

Spring Cloud 支持的服务发现软件以及特性对比：其中euerka和consul使用较多。

Feature	euerka	Consul	zookeeper	etcd
服务健康检查	可配支持	服务状态，内存，硬盘等	(弱)长连接，keepalive	连接心跳
多数据中心	—	支持	—	—
kv 存储服务	—	支持	支持	支持
一致性	—	raft	paxos	raft
cap	ap	ca	cp	cp
使用接口(多语言能力)	http（sidecar）	支持 http 和 dns	客户端	http/grpc
watch 支持	支持 long polling/大部分增量	全量/支持long polling	支持	支持 long polling
自身监控	metrics	metrics	—	metrics
安全	—	acl /https	acl	https 支持（弱）
spring cloud 集成	已支持	已支持	已支持	已支持

4.2Hystrix(熔断器)

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

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

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

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

4.3Hystrix Dashboard(仪表盘)和Turbine

当熔断发生的时候需要迅速的响应来解决问题，避免故障进一步扩散，那么对熔断的监控就变得非常重要。熔断的监控现在有两款工具：Hystrix-dashboard和Turbine.
Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，通过Hystrix Dashboard我们可以直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。但是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine.监控的效果图如下：

4.4Spring Cloud Config(配置中心)

随着微服务不断的增多，每个微服务都有自己对应的配置文件。在研发过程中有测试环境、UAT环境、生产环境，因此每个微服务又对应至少三个不同环境的配置文件。这么多的配置文件，如果需要修改某个公共服务的配置信息，如：缓存、数据库等，难免会产生混乱，这个时候就需要引入Spring Cloud另外一个组件：Spring Cloud Config。
Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client通过接口获取数据、并依据此数据初始化自己的应用。
其实就是Server端将所有的配置文件服务化，需要配置文件的服务实例去Config Server获取对应的数据。将所有的配置文件统一整理，避免了配置文件碎片化。
如果服务运行期间改变配置文件，服务是不会得到最新的配置信息，需要解决这个问题就需要引入Refresh。可以在服务的运行期间重新加载配置文件。
当所有的配置文件都存储在配置中心的时候，配置中心就成为了一个非常重要的组件。如果配置中心出现问题将会导致灾难性的后果，因此在生产中建议对配置中心做集群，来支持配置中心高可用性。

4.5Spring 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，具体的工作流程如下：

4.6服务网关

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

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

4.7链路跟踪

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

Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。
Zipkin是Twitter的一个开源项目，允许开发者收集 Twitter 各个服务上的监控数据，并提供查询接口
分布式链路跟踪需要Sleuth+Zipkin结合来实现

4.8总结：

从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。

其中Eureka负责服务的注册与发现，很好将各服务连接起来
Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护。
Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况，并给予图形化的展示
Spring Cloud Config 提供了统一的配置中心服务
当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息
所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用
最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们进行后续分析

Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。
微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

5.形象化理解springcloud

Spring framework架构的项目就像一栋高楼大厦，一栋大厦里租用者各色各样的公司和企业为用户提供各种各样的服务。
大厦里的每间办公室都是一个容器，对应着一个docker容器，空办公室对于用户来说是没有任何意义的，只有里面入住了企业(Spring boot)，跑了各种程序，才叫一个微服务结点。
房间号可以理解成容器的ip和端口，企业名理解成微服务的服务名，如果一家企业规模较大，需要租多间办公室才可以，那就是多个容器共同组成一个高可用性的微服务组群。
大厦有一本企业列表，有哪些企业提供哪些服务，对应的房间号是什么，这本列表就是Spring Cloud Eureka。
大厦的大门是所有企业的对外的gateway，用户只能通过大门进去然后进行安检后保安会帮你指路告诉你要找的企业在哪里，这里的大门和门卫就是Spring Cloud Zuul。
也不是所有的房间都是给企业准备的，也有弱点室、茶水间等为所有企业准备的公共设施，这就是Spring Cloud Hystrix的Dashboard、redis、MQ等这些独立的辅助服务。
  如果要访问大厦里的某一个企业你只知道企业名，你是不知道具体在哪一楼层哪一房间的，需要去看楼层的导航图或者电梯附近的企业列表（Eureka），如果一个企业有多个房间，客户自己决定进哪一个房间去获取服务，这就是Spring Cloud Ribbon。如果你今天一连几次都没有在某一个企业获得自己想要的服务，你会过段日子再来试试运气（熔断了），或者约几个人一起来拜访（请求聚合和拆解），这就是Spring Cloud Hystrix。如果你是有头有脸的重要人物，以上访问一个企业的流程不够上档次，大厦会安排专门的礼仪小姐在电梯口迎接，提高客户满意度，这就是Spring Cloud Feign。
  如果你一次性进入这个大厦是要拜访不止一个企业，什么时候进入哪个房间什么时候出来，什么时候又进入了其他的房间这些通过摄像头都有记录，而且都给你拍照留念，这个机制就是Spring Cloud Sleuth。
  这座大厦的物业公司叫GitHub，所有企业的保洁阿姨等都是Git上给分配的，每个企业每天换什么样的地毯、卫生程度如何都是保洁阿姨决定的，他们是独立于所有企业但是又影响到所有企业的一个组织，这货就叫Spring Cloud Config。当然如果物业公司福利足够好，保洁阿姨住集体公寓，每天上下班都有巴士接送，那就成了Spring Cloud Bus。
  恰巧房间号701是生产皮革的企业，而房间703是生产LV包包的企业，俩家签订协议后一开始701的人搞到材料就给703送去，结果总是因为703手上活还没干完而且没多余的空间存放又让701给抱回去，于是两家商量好租下了702这个房间，皮革生产上把生产好的皮革直接送到702房里去，LV企业一旦加工完手上的这批包包就去702房里取新的材料来处理，这里702房就相当于一个Kafka或者RabbitMQ，而701和703之间与702之间的集成就是Spring Cloud Stream。

具体学习请查看后续博客-》

三、Service Mesh(服务网格)

1.简介
Service Mesh又译作“服务网格”，作为服务间通信的基础设施层。如果用一句话来解释什么是Service Mesh，可以将它比作是应用程序或者说微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用Service Mesh也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如Spring Cloud、OSS，现在只要交给Service Mesh就可以了。

Spring Cloud、Dubbo等各类微服务框架的应用越来越广泛，但同时问题也逐渐暴露了，技术门槛高、多语言支持不足、代码侵入性强等问题，服务网格的出现解决了该系列问题。

参考文章浅谈服务治理、微服务与服务网格

服务网格：微服务进入2.0时代

参考自：springcloud 纯洁的微笑博客

米殇粟

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【Spring Cloud系列学习】02.微服务实现框架(常用)

目录前言一、Dubbo二、spring Cloud1.简介2.优点及特性2.1优点2.2特性3.总体框架4.总体了解springcloud4.1Eureka4.2Hystrix(熔断器)4.3Hystrix Dashboard(仪表盘)和Turbine4.4Spring Cloud Config(配置中心)4.5Spring Cloud B...
复制链接

扫一扫