在业界,一般有两种微服务的实践方法:基于dubbo的微服务架构、基于Spring Cloud的微服务架构。从概念上来讲,Dubbo和Spring Cloud并不能放在一起对比,因为Dubbo仅仅是一个RPC框架,实现Java程序的远程调用,实施服务化的中间件则需要自己开发;而Spring Cloud则是实施微服务的一系列套件,包括:服务注册与发现、断路器、服务状态监控、配置管理、智能路由、一次性令牌、全局锁、分布式会话管理、集群状态管理等。
在国内基于Dubbo实施服务化,刚开始是基于ZooKeeper进行服务注册与发现,现在已经转成使用Etcd。
-
Eureka 微服务注册与发现
-
Actuator 微服务监控
-
RestTemplate 服务器远程调用
-
Ribbon 客户端的负载均衡
-
OpenFeign 声明式服务调用
-
Hystrix 微服务熔断、降级、资源隔离
-
HystrixDashboard
-
Zuul 微服务网关
-
Config 微服务配置中心
-
Sleuth zipkin 微服务链路追踪
1、SpringCloud分布式开发组件
服务发现——Netflix Eureka
Eureka:服务注册中心(也可以是一个集群,即Eureka相互注册),对外暴露自己的地址
提供者:定期向eureka注册自己的信息
Eureka服务端
Eureka客户端
消费者:向Eureka订阅服务,Eureka则会把服务的相关地址列表发送给消费者,并且定期更新
心跳:服务提供者定期向Eureka通过http形式向Eureka刷新自己的状态,30秒发一次
服务下线:
当服务进行正常关闭的时候,服务方会发送一个REST请求给EurekaServer,通知“我已经下线”
服务剔除:
特殊情况下出现内存溢出或者网络波动严重使得服务无法正常工作,而服务注册中心并未收到服务下线的请求,Eureka注册中心在启动的时候会创建一个定时任务,默认每隔一段时间(默认60s),将清单中超时超过90秒的没有续约的服务剔除
自我保护机制:
Eureka自我保护机制,即Eureka会统计服务实例最近15分钟内心跳续约比例是否低于85%,此时如果心跳续约比例高于85%,而某服务仍然不能按时续约,则剔除
客服端负载均衡——Netflix Ribbon
Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时,重试等。简单的说,就是在配置文件中列出Load Balancer后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机连接等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。简单地说,Ribbon是一个客户端负载均衡器。
Ribbon工作时分为两步:第一步先选择 Eureka Server, 它优先选择在同一个Zone且负载较少的Server;第二步再根据用户指定的策略,在从Server取到的服务注册列表中选择一个地址。其中Ribbon提供了多种策略,例如轮询、随机、根据响应时间加权等。
熔断器——Netflix Hystrix
用于处理雪崩问题,假设一个请求需要abcd四个服务执行,如果其中a服务挂掉,则返回结果阻塞,同时如果越来越多的请求进入,则最后http容器的连接数耗尽,此时其他正常的服务也无法使用
解决问题方式:
1、线程隔离,服务降级
给每个服务分配一定的线程池,如给a服务5个线程。此时用户来访问a服务,a已经挂了,则最多只能占用5个线程,不会影响到其他服务的线程,同时设定一个超时时长,即请求到a服务之后,无法通过,等待一定时间后,则服务返回一个“服务器繁忙”,同时断开连接,直到能成功为止。
2、熔断,在最近的20次请求,如果其中有超过一半次都失败,则熔断被访问的服务,同时请求直接返回失败,同时打开熔断器,休眠时间窗(默认5秒)10秒之后会再次尝试,进入半开状态,放一半的请求进入测试,如果仍然失败,则再次进入熔断再次进入半开状态,如果请求测试成功,则关闭熔断器。
服务网关——Netflix Zuul
* zuul是netflix开源的微服务网关,1.路由,2.控制,3.控流
* 其核心是一系列的过滤器,可以完成以下功能点:
* 1.身份认证与安全,识别每一个资源的验证要求,并拒绝那些与要求不符的请求
* 2.审查,监控,
* 3.动态路由
* 5.负载分配,为每一种负载类型分配对应的容量,并弃用超出限定值的请求
* 6.限流,限制用户流量
分布式配置——Spring Cloud Config
Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。使用Config Server,您可以在所有环境中管理应用程序的外部属性。随着应用程序通过从开发人员到测试和生产的部署流程,您可以管理这些环境之间的配置,并确定应用程序具有迁移时需要运行的一切。服务器存储后端的默认实现使用git,因此它轻松支持标签版本的配置环境,以及可以访问用于管理内容的各种工具。很容易添加替代实现,并使用Spring配置将其插入。
config server:
Spring Cloud Config分为服务端和客户端,下面我们先来为大家介绍服务端,服务端为外部配置(名称值对或等效的properties内容)提供了基于资源的HTTP。
要在您的项目中包含config server,请使用组org.springframework.cloud和spring-cloud-config-server的启动器。
config client:
Spring Boot应用程序可以立即利用Spring配置服务器(或应用程序开发人员提供的其他外部属性源),并且还将获取与Environment更改事件相关的一些其他有用功能。
这是在类路径上具有Spring Cloud Config Client的任何应用程序的默认行为。配置客户端启动时,它将通过配置服务器(通过引导配置属性spring.cloud.config.uri)绑定,并使用远程属性源初始化Spring Environment。
这样做的最终结果是所有想要使用Config Server的客户端应用程序需要bootstrap.yml(或环境变量),服务器地址位于spring.cloud.config.uri
Spring Cloud Config这个还是静态的,得配合Spring Cloud Bus实现动态的配置更新。
消息总线——Spring Cloud Bus
Spring Cloud Bus 核心原理其实就是利用消息队列做广播,所以要先有个消息队列,目前官方支持 RabbitMQ 和 kafka。例如借助 Spring Cloud Bus 的广播功能,让 client 端都订阅配置更新事件,当配置更新时,触发其中一个端的更新事件,Spring Cloud Bus 就把此事件广播到其他订阅端,以此来达到批量更新。
2、应用场景
注册中心
注册中心主要用于服务治理,提供了服务的注册与发现功能,微服务架构中服务可以注册到注册中心,也可以通过注册中心获取到其他服务的信息。这里提供了Eureka、Consul、Nacos三种解决方案;
配置中心
配置中心主要用于提供统一的外部配置管理,微服务架构中的服务可以从配置中心获取配置信息,同时支持动态刷新配置;这里提供了Spring Cloud Config 、Consul、 Nacos 三种解决方案;
API网关
API网关主要用于为微服务架构中的服务提供统一的外部访问入口,实现请求的路由与过滤功能。这里提供了Zuul和Gateway两种解决方案。
负载均衡
微服务架构中有的服务会部署多个,Ribbon提供了服务间调用的客户端负载均衡功能,OpenFeign基于Ribbon提供了声明式的服务间调用。
熔断与限流
熔断与限流是对微服务架构中服务的一种保护措施,当系统中有故障发生时,可以防止故障的蔓延。这里提供了Hystrix和Sentinel两种解决方案。
安全保护
Spring Cloud Security 为构建安全的SpringBoot应用提供了一系列解决方案,结合Oauth2可以实现单点登录、服务安全保护等功能,可以很好地保护微服务架构中的服务。
监控中心
Spring Boot Admin 结合 Spring Cloud的注册中心使用可以用来监控微服务架构中的服务。
分布式事务解决
微服务架构中,当一次业务操作需要操作多个数据源或需要进行远程调用时就会产生分布式事务问题,Seata可以很好地解决该问题。
下面我们就来看一下在微服务中,如何快速的使用它们
在一个请求进入到我们系统之后,我们的系统具体是怎么的一个流程来处理的呢?下面一个图来比较形象的描述对于这些组件之间的关系