springboot分布式事务解决方案_基于 Spring Boot 的分布式和服务化解决方案 Roses

Roses基于Spring Boot 2和Spring Cloud Finchley.SR2,致力做整套分布式和服务化解决方案,Roses拥有高效率的开发体验,提供可靠消息最终一致性分布式事务解决方案,提供基于调用链的服务治理,提供可靠的服务异常定位方案(Log + Trace)等等,一个分布式框架不仅需要构建高效稳定的底层开发框架,更需要解决分布式带来的种种挑战。

springboot分布式事务解决方案_基于 Spring Boot 的分布式和服务化解决方案 Roses_第1张图片

Roses企业级微服务视频教程

Roses企业级微服务视频教程,详情点击https://www.stylefeng.cn/rosesVideo

Guns VIP计划

Guns VIP计划,详情点击https://www.stylefeng.cn/gunsVIP

最新更新说明

Roses目前的版本为Roses 2.0,原有项目代码拆分为多个子项目存放在Roses项目组里,框架和业务分开维护,更快捷的开发新业务。

Roses项目组地址:https://gitee.com/stylefeng-Roses

Roses会持续更新下去,您可以star & watch本项目,以了解Roses的最新动态,感谢您的支持!

Roses子项目介绍

模块名称说明地址roses-kernelRoses框架核心支撑https://gitee.com/stylefeng-Roses/roses-kernelroses-biz-support基础业务服务支撑https://gitee.com/stylefeng-Roses/roses-biz-supportroses-cloud-support微服务支撑组件https://gitee.com/stylefeng-Roses/roses-cloud-supportroses-config-repo配置仓库https://gitee.com/stylefeng-Roses/roses-config-reporoses-system系统管理服务https://gitee.com/stylefeng-Roses/roses-systemroses-gateway微服务网关https://gitee.com/stylefeng-Roses/roses-gateway

为什么Roses 2.0拆分项目

相信大家所在的公司都有自己的gitlab仓库,或者托管在码云平台,仓库中有很多项目,很多业务模块,每个业务模块都配置了spring mvc,mybaits,mybaits plus之类的,每个 项目都有一些共性的东西,当您开发一个微服务的时候,您是直接从旧项目复制一套东西,在新项目改一改名字,包名,类名更方便,还是直接新建一个项目,引入一个maven的pom 更方便。还有就是框架上的东西升级的时候,同样的类,同样的方法,您一定不喜欢修改两次或者更多次。

可能有的人会反驳这个观点,直接建一个大项目,里边建立多个maven模块来构建,新建微服务的时候我直接在下边加个模块不可以吗?

也可以,但是不推荐,到了项目后期,模块越来越多,可能光导入项目机器都很卡,还有开发A模块的人,公司规定不准看B模块的业务,这种情况无法解决。随着公司的发展,公司一定不是只有一个项目。

所以拆分项目,更加适合公司实际业务开发的情况,共有的东西提出来,以maven模块方式依赖进业务系统。升级框架的时候,通知业务负责人升级pom 版本即可。业务人员也可以更加专注于开发业务,导入项目开发时,也只需要导入开发人员开发的模块即可,非常方便。


使用手册

如果是刚接触微服务,可能有些吃力,不要气馁,相信自己,花点时间一定可以跑起来。

由于拆分了项目,使用方式略有不同,不了解maven的同学,需要先学习下maven,另外项目还用了lombok,需要安装lombok插件。

请先导入roses-kernel,根pom下执行mvn clean install -Dmaven.test.skip=true或者deploy到自己公司的私服上。

再导入roses-biz-support,根pom下执行mvn clean install -Dmaven.test.skip=true或者deploy到自己公司的私服上。

之后需要先启动配置中心,再启动注册中心,仓库地址地址在https://gitee.com/stylefeng-Roses/roses-cloud-support上面,具体启动方法见仓库里readme

然后启动roses-system,仓库地址地址在https://gitee.com/stylefeng-Roses/roses-system,具体启动方法见仓库里readme

再启动roses-gateway网关,仓库地址在https://gitee.com/stylefeng-Roses/roses-gateway,具体启动方法见仓库里readme


微服务的优缺点

微服务不一定适用于所有的系统构建,需要根据各自公司业务情况来评估。以下列举一些微服务的优缺点,仅供参考。

1. 微服务的优势

  1. 单体服务就像在一个小超市中,一个人负责收银,打扫,摆货,咨询等各种事情,服务化就像是一大超市,采取分工的方式更好的服务顾客,更加高效。
  2. 多业务并行开发更加容易,单体应用按业务拆分后,一个微服务只需要关注某个方面的业务,例如订单,用户,积分,账户服务等,同时并行开发,代码提交互不影响,每个人只需要关注自己的领域迭代。
  3. 上线发布不会因为某个微服务升级,影响到所有服务,每次某个微服务升级,只需要重新部署一个服务即可。
  4. 技术栈不受限制,在微服务架构中,服务之间调用可用restful api方式进行交互,所以技术选型可以根据不同部门的需要设计不同的服务。
  5. 通过对服务的划分,当系统中某些业务出现瓶颈时,可根据需要进行升级,或者直接增加某些服务的机器。

2. 微服务面临的挑战

  1. 服务多级调用带来的调试,跟踪困难。访问一个业务功能,要经过网关,之后调用A服务,B服务,C服务,通常会先去寻找A服务的问题,之后去排查B服务,以此类推,排查所有服务后,也可能问题不在A,B,C三个服务上,也许只是A访问B时调用超时了,所以这就导致了服务出现问题,定位非常困难。
  2. 分布式事务问题。A服务调用B服务,之后A又调用C服务,若C服务执行时出现异常,那么如何回滚B服务的执行过程。
  3. 运维成本。更多的服务意味着更多的运维投入,单体架构中,只需部署一个项目即可,微服务中,少则部署数个多则部署几十个服务,并且某些服务可能为集群部署,机器的消耗和运维要比单体服务提升很多。
  4. 开发成本,对开发人员的技术要求和开发一个业务的工作量有所不同。单体服务中,没有幂等性和分布式事务等问题,微服务开发中,不仅需要编写业务,还要考虑到可能会影响业务正常运行的其他因素。

一些建议

  • 如果您觉得分布式项目不适合您,不妨考虑一下作者的另一款单体项目框架Guns,Guns项目代码简洁,注释丰富, 上手容易,是一个后台管理系统的脚手架,会让您降低不少开发成本!
  • 刚接触分布式框架的同学,请利用好手头的资源,运行前仔细阅读使用手册,按照步骤一步步来,一定可以成功运行!

Roses特点

1. 快速开发微服务的秘籍 roses-kernel

在roses-kernel模块的com.stylefeng.roses.core.config包下整合了大量开发常用到的配置,其中包含默认异常拦截,登陆用户的上下文获取,默认缓存配置,默认fastjson的配置,默认mybatis-plus的配置,默认的swagger的配置,默认的web配置等等等等,使得在新业务开发中,只要pom引入roses-kernel这个模块,即可很方便的注入这些特性,直接上手开编写业务,大大减少了新业务,新模块的配置,调试,各种框架集成拼接的时间,因为这些在Roses中已经为您提供好了,利用Spring Boot的自动配置机制,同样的,这些配置在项目启动的时候会默认加载,因为在roses-kernel模块下的META-INF/spring.factories中配有这些类,当然,如果您不需要某些特性(自动配置类)您可以在@SpringBootApplication注解上增加exclude参数来排除这些自动配置。

有了roses-kernel模块,开发别的模块时,您可以把百分之90的精力花在编写业务上,百分之10的精力花在搭建项目和配置项目上。

2. 网关实现统一鉴权,资源权限过滤

Roses中,所有业务请求经过网关,网关做统一的鉴权,权限过滤,数据签名校验,这样做的好处就是业务系统中不用集成鉴权模块,只需要关心各自服务的业务编写。鉴权方面Roses依旧使用jwt,如果想对某个用户作某些资源访问的限制,需要开启PathMatchFilter,该过滤器会对用户当前访问的资源进行权限校验,资源的收集方式也做了大大的简化,Roses中通过资源搜集器roses-scanner收集资源(详见特点6),所有的资源只需要用@ApiResource注解标识,项目运行后会把所有资源发送到roses-auth服务中,对比以往的每新增一个资源都需要在后台管理系统中新增一条记录,省了不少工作量。

3. 网关生成唯一请求号(RequestNoGenerateFilter)

Roses中,所有业务请求经过网关,网关做统一的鉴权,权限过滤,数据签名校验,并为每个请求生成该次请求的唯一请求号。唯一请求号的作用如下:请求在业务流转过程中可能经过多个微服务,查看这次请求的info日志信息,或者error日志信息等,需要从多个微服务的日志记录里去查找,效率非常低,那么,有了唯一请求号标识之后,可以用唯一请求号把请求经过的所有业务流转串起来,并存储起来,当请求遇到问题后,可以通过唯一请求号快速把这次请求的所有日志搜集并展示起来,从而方便排查问题。

Roses中,请求号在中转过程中填充到请求的Request-Header中,与之对应,响应时也会在Response-Hedaer中把本次的请求号输出。过滤器中的写法如下:

RequestContext currentContext = RequestContext.getCurrentContext();HttpServletResponse response = currentContext.getResponse();String requestNo = IdWorker.getIdStr();currentContext.addZuulRequestHeader(RosesConstants.REQUEST_NO_HEADER_NAME, requestNo);response.addHeader(RosesConstants.REQUEST_NO_HEADER_NAME, requestNo);

为了让Feign调用中,自动填充网关生成的唯一号,Roses增加了RosesFeignHeaderProcessInterceptor拦截器

4. 分布式事务解决方案(可靠消息最终一致性)

首先,分布式事务在不同业务场景下,解决方案是不一样的,时效性要求较高的场景下,例如订单支付成功后,更改订单状态,给用户账户加款,给积分账户加积分,三个操作在三个不同的服务下,这个时候可以用TCC方式解决事务问题;在时效性要求较为不严格下,例如订单支付成功后,需要异步录入会计凭证(不严格要求时效性),这个时候可以用可靠消息最终一致性解决。

Roses中实现了可靠消息最终一致性的解决方案(如上所说第二个例子),TCC方案目前未集成到系统。

实现原理

单纯依靠消息队列无法实现消息的可靠投递和消费,所以借助预发送待确认消息,业务执行成功后再发送确认消息来保证消息的可靠投递,并且通过中间服务(消息服务)来控制统一的消息预存储和确认发送,统一执行发送到消息队列的操作,并且消息服务有单独的消息表来记录消息是否已经投递成功。

Roses中roses-message-service为消息服务,为可靠消息最终一致性实现的核心,roses-message-checker为定时任务执行器,每隔一定时间来轮训消息表中是否有消息不一致的数据,若消息不一致则从业务系统中调用接口来查询具体业务的执行状态,从而来更新消息表中的消息。

roses-example-order和roses-example-account两个模块,模拟了分布式事务的场景,首先通过order模块下一个单(/place接口),再执行完成此订单(/finish接口),在完成订单过程中,先调用了预发送消息接口(preSaveMessage),之后执行完业务后调用确认并发送消息(confirmAndSendMessage)。在account模块中有消息的监听器,监听到消息后存储账号交易流水记录(recordFlow)。account和order模块为了演示业务流程用,数据库设计比较简单,不合理处请见谅。

//创建预发送消息ReliableMessage reliableMessage = createMessage(order);//预发送消息messageServiceConsumer.preSaveMessage(reliableMessage);//更新订单为成功状态(百分之50几率失败,模拟错误数据)(此处错误已添加到消息表的数据会被roses-message-checker轮询时删除掉)updateToSuccess(order);//确认消息messageServiceConsumer.confirmAndSendMessage(reliableMessage.getMessageId());

幂等性校验

消息的投递有重试机制,所以在消息的消费端需要加上幂等性校验,使得多次消费消息也可以让业务实际只执行一次,在account模块中幂等性的判断通过订单号来标识操作的唯一性。

5. 分布式配置中心roses-config

在Roses中,正如您所见,所有的模块都是在一个大工程下,但是实际日常开发中,模块往往分隔在多个项目中,每个项目有单独的小组来维护,小组与小组之间甚至代码都不是可见。当项目中的一些通用配置变动时,例如数据库地址,账号密码等,要么你通知各个小组修改他们的配置,要么你自己打开所有项目修改一遍。如果使用了分布式配置中心,可以把所有项目的配置收集起来,集中配置,那么你只需要打开配置中心的git仓库来修改配置,从而简化配置的维护工作。

除此之外,如果spring boot应用开启了actuator,配置仓库中的配置更改后,应用还可以通过/refresh动态刷新项目的配置,这在网关动态增加路由等配置上非常方便。

当然,开启分布式配置之后也有不完美的地方,在本地开发调试中,常常需要修改配置,直接修改远程仓库的配置又会影响到别人的本地开发,关于这种情况,Roses在每个项目的src/test/resources文件夹中,都保留了一个application-local.yml,这个配置文件是local环境下的应用的配置文件,您可以把它拷贝到src/main/resources中,并配置bootstrap.yml中的spring.cloud.config.enable配置为false,即可关闭配置中心的配置,使用本地的配置。

6. 一切请求基于RequestData和ResponseData

为了方便日常接口开发,Roses对控制器层的请求参数和响应进行了统一封装。所有post方式的请求,并且带有json请求body的都可以用RequestData类来作为参数接收请求数据,所有的响应都可以用ResponseBody来作响应的结果。

RequestData类中封装了对请求参数获取的常用方法,例如getString(),getInteger(),parse()等等,可以很方便的获取请求中包含的字符串数据,整型数据,以及解析请求为某个类。而ResponseData类中包含了对常用成功或者失败响应的封装,可以通过静态方法ResponseData.success()或者ResponseData.error()来响应成功的结果或者失败的响应。

例如,请求的数据是一段json:

{name:"order001

你可能感兴趣的:(分布式模块之间的调用)