1 微服务架构,看这一篇文章就够了

发布于 2022年 02月 13日 15:46

微服务架构是现在业界很火的一种分布式服务治理的解决方案,解决了原来通过rpc框架进行多个服务间调用和通信的问题。是业务从单体架构,到集群架构,到搭载多个服务的集群机构的发展。它带来的好处有
1 将业务拆分为多个微服务,提升业务间的隔离度,增强系统在面对高并发大流量下的稳定性,系统的各个模块的拆分保证了各个模块工作的稳定性,同时能够使业务的调用更加方面,业务间更加解耦
2 系统可以横向大规模发展,各个团队之间的分工也更加明确。
当然:微服务时代,我们面临要解决的问题会很多,比如:系统的复杂度上升、服务依赖关系、服务性能监控、全链路日志、容灾、断路器、限流等。
本文将从几个方面来进行介绍微服务架构原理

1微服务原理

2微服务框架介绍及选型

3spring cloud架构及其原理

3.1 注册中心
3.2 熔断限流Hystrix
3.3 Feign
3.4 Ribbon
3.5 Zuul

1微服务原理

在这里看一下一个因为流程,以电商网站下单为例子。原本的流程是,创建订单-调用库存-增加积分-发货。原来的逻辑如果按照这样的流程,中间任何一环出了问题,都可能导致用户购买不成功。而加入微服务开发后,将这一系列的逻辑,采用订单服务-库存服务-积分服务

通过这样的服务化,保证了各个服务的稳定运行

2常见的微服务架构以及框架

微服务框架,一般包括注册中心,网关,微服务本身等。现在比较流行的微服务框架有spring cloud和dubbo.spring cloud源自spring家族,提供一整套分布式服务治理的解决方案,从注册中心到微服务化,监控,限流等。而阿里的dubbo只是实现了服务治理。spring cloud提供的功能更多

dubbo由于是二进制的传输,占用带宽会更少(基于netty等) springCloud是http协议传输,带宽会比较多,同时使用http协议(http+restful api)一般会使用JSON报文,消耗会更大。 http协议的通信对于应用的负载量会否真正成为瓶颈点(Spring Cloud也并不是和http+JSON强制绑定的,如有必要Thrift、protobuf等高效的RPC、序列化协议同样可以作为替代方案)

dubbo的开发难度较大,原因是dubbo的jar包依赖(存在代码级别的强依赖)问题很多大型工程无法解决 springcloud的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级

dubbo的注册中心可以选择zk,redis等多种,springcloud的注册中心只能用eureka或者自研 从系统结构简易程序: .cloud程序结构简单,“springMVC+注册”=spring-cloud .dubbo相对复杂,Url,protocol,register,invocation,dubbofilter,dubboSPI,dubbo序列化 从性能: dubbo网络开销略小于cloud,但是可以通过压缩、二进制、高速缓存、分段降级等方法解决 开发难易度: dubbo的神坑是jar包依赖,开发阶段难度极大,jar升级是大问题 springcloud比较自由,但带来的问题是无法“强力约束接口规范”,建议用行政方式解决

3 spring cloud架构及其原理

3.1 注册中心

spring的注册中心有两者Eureka 和consul 以Euraka为例子  
Eureka Client:负责将这个服务的信息注册到Eureka Server中  
Eureka Server:注册中心,里面有一个注册表,保存了各个服务所在的机器和端口号

3.2 Feign

原本微服务间的通信需要写大段通信代码,并且很有可能踩坑。通过feign可以很简单的调用微服务。
![下单流程]( https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2018/11/7/166ebfff505b2a20~tplv-t2oaga2asx-image.image )

3.3 Ribbon

通过feign调用微服务,但是某个微服务部署在多台服务器上,这个时间需要挑选一台进行访问。而ribbon就是这个挑选机制。   
Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法,按照顺序一圈圈轮训  

它与feign和注册中心的关系如下图

3.4 Hystrix

一个系统中有很多微服务,很多组件。这么多服务互相调用,要是不做任何保护的话,某一个服务挂了,就会引起连锁反应,导致别的服务也挂。比如积分服务挂了,会导致订单服务的线程全部卡在请求积分服务这里,没有一个线程可以工作,瞬间导致订单服务也挂了,别人请求订单服务全部会卡住,无法响应。

Hystrix会搞很多个小小的线程池,比如订单服务请求库存服务是一个线程池,请求仓储服务是一个线程池,请求积分服务是一个线程池。每个线程池里的线程就仅仅用于请求那个服务。如果积分服务挂了,只会影响请求积分服务的线程池,对其他服务的调用依然有效。

熔断:但是如果积分服务都挂了,每次调用都要去卡住几秒钟干啥呢?有意义吗?当然没有!所以我们直接对积分服务熔断不就得了,比如在5分钟内请求积分服务直接就返回了,不要去走网络请求卡住几秒钟,这个过程,就是所谓的熔断!

降级:每次调用积分服务,你就在数据库里记录一条消息,说给某某用户增加了多少积分,因为积分服务挂了,导致没增加成功!这样等积分服务恢复了,你可以根据这些记录手工加一下积分。

3.5 Zuul

网关Zuul,也就是微服务网关。这个组件是负责网络路由的。不懂网络路由?行,那我给你说说,如果没有Zuul的日常工作会怎样?假设你后台部署了几百个服务,现在有个前端兄弟,人家请求是直接从浏览器那儿发过来的。打个比方:人家要请求一下库存服务,你难道还让人家记着这服务的名字叫做inventory-service?部署在5台机器上?就算人家肯记住这一个,你后台可有几百个服务的名称和地址呢?难不成人家请求一个,就得记住一个?你要这样玩儿,那真是友谊的小船,说翻就翻!

上面这种情况,压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关在里面,像android、ios、pc前端、微信小程序、H5等等,不用去关心后端有几百个服务,就知道有一个网关,所有请求都往网关走,网关会根据请求中的一些特征,将请求转发给后端的各个服务。

而且有一个网关之后,还有很多好处,比如可以做统一的降级、限流、认证授权、安全,等等。

总结

上述几个Spring Cloud核心组件,在微服务架构中,分别扮演的角色

:Eureka:各个服务启动时,Eureka Client都会将服务注册到Eureka
Server,并且Eureka Client还可以反过来从Eureka Server拉取注册表,从而知道其他服务在哪里Ribbon:服务间发起请求的时候,基于Ribbon做负载均衡,从一个服务的多台机器中选择一台
Feign:基于Feign的动态代理机制,根据注解和选择的机器,拼接请求URL地址,发起请求
Hystrix:发起请求是通过Hystrix的线程池来走的,不同的服务走不同的线程池,实现了不同服务调用的隔离,避免了服务雪崩的问题
Zuul:如果前端、移动端要调用后端系统,统一从Zuul网关进入,由Zuul网关转发请求给对应的服务

推荐文章