微服务开发框架主流技术总结介绍

微服务架构概述

微服务架构是种架构模式，它提倡将单⼀应⽤程序划分成⼀组⼩的服务，服务之间互相协调、互相配合，为⽤户提供最终价值。服务运⾏在其独⽴的进程中，服务与服务间采⽤轻量级的通信机制互相协作(通常是基于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的负载均衡算法，在多个服务器之间选择⼀个进⾏访问。
常见的负载均衡算法：
随机：通过随机选择服务进⾏执⾏，⼀般这种⽅式使⽤较少；
轮询：请求来之后排队处理，轮着来；
响应时间加权：通过响应时间，给⾼配置，低负载的服务器分配更⾼的权重，均衡各个服务器的压⼒；
最少并发数：将请求分配到当前压⼒最⼩的服务器上