微服务架构概述
微服务架构是种架构模式,它提倡将单⼀应⽤程序划分成⼀组⼩的服务,服务之间互相协调、互相配合,为⽤户提供最终价值。服务运⾏在其独⽴的进程中,服务与服务间采⽤轻量级的通信机制互相协作(通常是基于HTTP协议的RESTfulAPI)。每个服务都围绕着具本业务进⾏构建,并且能够被独⽴的部署到⽣产环境、类⽣产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的⼀个服务⽽⾔,应根据引⽤上下⽂,选择合适的语⾔、⼯具进⾏构建。
Spring-Cloud
微服务架构工具集 :
https://spring.io/projects/spring-cloud
Spring Cloud为开发人员提供工具,以快速构建分布式系统中的一些常见模式 (例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态)。
nacos 服务发现 配置管理
服务发现:1.生产者启动时注册地址信息。2.消费者拉取信息列表。3.注册表对生产者进行健康检测。4.如果信息有变更,对消费者发送变更通知。5.消费者重新拉取。
sentinel 服务容错
雪崩效应:由于网络或者自身原因,服务无法保证100%可用。如果一个服务出现问题后,在调用这个服务时就会出现延迟,此时若大量的网络涌入,就会形成任务堆积,最终导致服务瘫痪。
因为无法完全杜绝雪崩发生,只有做好足够的容错,保证在一个服务发生问题,不会影响到其他服务的正常运行。
Sentinel (分布式系统的流量防卫兵) 是阿⾥开源的⼀套⽤于服务容错的综合性解决⽅案。它以流量为切⼊点, 从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性。
Sentinel 提供了开箱即⽤特性,可以快速实现与它开源框架整合, 例如与 Spring
Cloud、Dubbo、gRPC 的整合。只需要引⼊相应的依赖并进⾏简单的配置即可快速地接⼊。
Sentinel核⼼分为两个部分:
核⼼库(Java 客户端):能够运⾏于所有 Java 运⾏时环境,同时对Dubbo /Spring Cloud 等框架也有较好的⽀持。
控制台(Dashboard):基于 Spring Boot 开发,打包后可以直接运⾏。
安装Sentinel服务
1,下载并启动服务
java -Dserver.port=8180 -Dcsp.sentinel.dashboard.server=localhost:8180 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.0.jar
2,访问Sentinal服务
第⼀步:假如Sentinal启动ok,通过浏览器进⾏访问测试,如图所⽰
第⼆步:登陆sentinel,默认⽤户和密码都是sentinel,登陆成功以后的界⾯如图所⽰:
常见服务容错模式:
限流:限流机制一般会控制访问的并发量,例如每秒允许处理的并发用户数及查询量、请求量等。
舱壁模式:这里用轮船的设计比喻舱壁隔离模式,若一艘航船遇到了意外事故,其中一个船舱进了水,则我们希望这个船舱和其他船舱是隔离的,希望其他船舱可以不进水,不受影响。
熔断模式:当服务的输入负载迅速增加时,如果没有有效的措施对负载进行熔断,则会使服务迅速被压垮,服务被压垮会导致依赖的服务都被压垮,出现雪崩效应,因此,可通过模拟家庭的电路保险开关,在微服务架构中实现熔断模式。
seata 分布式事务
seata介绍
1. Seata是⼀款致⼒于⾼性能和简单易⽤的分布式解决⽅案。
2. Seata主要提供了AT、TCC、SAGA 和 XA 事务模式,阿⾥⾸推的模式的AT。
3. 在Seata中存在三种⾓⾊,分别是:TC(事务协调者,维护全局和分⽀事务,解决分布式事务的提交/回滚)。TM(事务管理者,事务的
执⾏者)。RM(资源管理者,管理分⽀事务的资源并于TM进⾏交互并上报当前事务的状态)。
4. TC 为单独部署的Server服务,TM和RM嵌⼊到应⽤中(client端)。
Seata设计分析
1. Seata是对⼆阶段提交协议的⼀种改进⽅案,在第⼀阶段:业务数据和回滚⽇志记录在本地事务中,核⼼在于会根据业务sql解析转换成undolog,也就是说会将资源⽣成前置镜像存放到undo_log表中,供之后的事务操作提供判断和回滚的⽀持。
2. 第⼆阶段:分布式事务执⾏成功的话,TC就通知RM异步删除undo_log。如果失败的话,会由TM向TC提交回滚请求,⽽TC就会通知
RM进⾏事务回滚,RM通过XID 和 分⽀事务Id 找到对应的undo_log⽇志记录,通过undo_log记录反向⽣成更新sql执⾏,完成分⽀的回滚。
gateway 服务网关
服务网关时分布式系统的唯一入口,封装了应⽤程序的内部结构,为客户端提供统⼀服务,⼀些与业务本⾝功能⽆关的公共逻辑可以在这⾥实现,诸如认证、鉴权、监控、缓存、负载均衡、流量监控、路由转发等。
在微服务架构中, 不同的微服务可以有不同的⽹络地址,各个微服务之间通过相互调⽤完成⽤户请求,客户端可能通过调⽤N个微服务的接⼝完成⼀个⽤户请求。
openfeign 服务调用
OpenFeign是Spring Cloud 在Feign的基础上⽀持了Spring MVC的注解,如@RequesMapping等等。OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接⼝,并通过动态代理的⽅式产⽣实现类,实现类中做负载均衡并调⽤其他服务。
ribbon 负载均衡
负载均衡是从多个服务中根据某个策略选择⼀个进⾏访问,常见的负载均衡分为两种:
1. 客户端负载均衡:即在客户端就进⾏负载均衡算法分配。例如spring cloud中的ribbon,客户端会有⼀个服务器地址列表,在发送请ribbon求前通过负载均衡算法选择 ⼀个服务器,然后进⾏访问。
2. 服务端负载均衡:在消费者和服务提供⽅中间使⽤独⽴的代理⽅式进⾏负载。例如Nginx,先发送请求,然后通过Nginx的负载均衡算法,在多个服务器之间选择⼀个进⾏访问。
常见的负载均衡算法:
随机:通过随机选择服务进⾏执⾏,⼀般这种⽅式使⽤较少;
轮询:请求来之后排队处理,轮着来;
响应时间加权:通过响应时间,给⾼配置,低负载的服务器分配更⾼的权重,均衡各个服务器的压⼒;
最少并发数:将请求分配到当前压⼒最⼩的服务器上