微服务架构 分布式事物

传统企业级应用是单体应用，一般是分层结构，如表现层/应用层/领域层/数据层，运用了水平切分思想，
随着互联网应用的发展，特别是大型电商系统，大型复杂银行证券系统，它们都不是一个或某个单应用支持，是由多个应用或系统支持提供相应功能
，构成一个庞大应用体供用户正常使用，此类系统难点有 需要根据业务划分子系统，子系统定位承接具体业务，子系统之间如何协作调用运转等
所以对于复杂系统，可以考虑使用微服务架构 垂直切分子系统，然后水平切换单子系统，提供服务化

现分布式事物流行处理方式如（TCC事物补偿、最大努力通知、消息一致性）
推荐使用 消息一致性方案处理分布式事物

本文主要通过案例讲解微服务架构中分布式事物处理方式

如图所示分析问题
1.service.doSave(model)操作数据库如失败，数据未处理成功，进入catch事物回滚，正常执行
2.同上如成功，此时正常发送消息到MQ服务器如果成功，提交事物正常执行
3.同上发送MQ服务器如失败，会存在数据不一致情况

• 发送MQ服务器由于网络原因，当时未成功，后续成功，此时会出现数据库回滚，消息已消费
• 发送MQ服务器成功，由于负载量过大，消息阻塞，此时会出现数据库事物提交，消息未消费

很多喜欢用这种方式处理，由于极少数情况下会发生问题 忽略了以上问题
针对以上问题，可以采取存储本地事件加定时任务轮训方式

如图所示调整优化如下

• 业务操作数据库成功后保存事件，把业务操作和操作事件保持在同个事物中
  要么都成功，要么都失败。数据保持一致
• 业务操作成功后发送消息到MQ，MQ发送成功后，删除本地事件记录，可能有些人会问 如果同样发送MQ网络原因迟迟会返回结果，此时本地事件状态处于‘未发送’状态
• 通过定时轮训本地处于‘未发送’状态记录，然后持续发送消息到MQ，保证MQ消息正常消费，MQ服务消费者针对消息要做幂等，如有些消息自带重试功能如（rabbitMQ、rocketMQ）
• 正常情况消息由于当时网络带宽问题、MQ服务器问题等导致不可用，轮训发送消息可加大消息被正常消费力度
• 极端情况下同条消息发送5-10次还未正常消费，此时需要人工干预处理

通过下单、支付流程实例讲解消息一致性处理


如图所示分析问题

传统微服务方式处理下单流程如下

• 提交订单成功后，需要校验参数/使用优惠劵/扣库存/减积分等等操作，其中如果处理100个场景，每个场景都同步使用微服务远程调用方式，系统无法承受庞大调用开销。随着业务、场景增多，系统最终会处于缓慢、卡死、崩溃等
• 可能有些人会说 优惠劵、库存、积分等都可以横向扩展、部署多台能够提供更高效服务，但是下单这一刻从开始到结束，其中整个流程还是
  处于同步操作，每个节点还是存在耗时开销，加起来整个链路还是缓慢，未达到最终效果

针对以上问题，接下来将通过rocketMQ处理难点，解耦应用。

如图所示，处理流程如下

• 提交订单成功后，校验参数通过后，首先创建不可见订单，此举目的避免后续部分操作失败，订单丢失

• 通过线程池并行处理（优惠劵、减库存、积分）等等业务场景，统一设置超时时间
  存在如下情况
  1.如优惠劵、减库存、积分相应线程统一都处理成功后，更改订单状态为可见，结束 流程
  2.如优惠劵线程执行成功处于等待状态，减库存、积分其中某个线程一直未执行成功，到达设置超时时间后，统一认定失败
  因为，有可能网络、调用等其他原因减库存、积分存在执行成功可能，此时通过发送消息到MQ，所有下单依拉操作系统
  统一订阅此退单消息，做相应回滚操作。由于发送消息到MQ也存在 网络、mq服务器异常等风控问题，所以推荐使用rocketmq作为MQ消息中间件
  后续文章会详细阐述rocketmq，本文简单描述如下
  1.单台rocketmq 可承受千万级别消息处理能力，消息过多后会堆积不会丢失
  2.rocketmq 提供者、消费者同时可支持集群部署、稳定健壮
  3.rocketmq处理能力快，效率高

• 极端情况下 处理（优惠劵、减库存、积分）期间或者完后机房停电、应用服务器被攻击宕机，此处本地库中存有隐藏订单记录，
  待应用恢复后，通过单独定时任务模块Elastic-Job，定期分片查询 隐藏订单记录，由于业务场景状态复杂，此时发送MQ服务器进行退单操作

支付场景如下

同订单处理思路一致，通过Rocketmq解耦，效果如下

微服务架构优缺点

优点
1.降低系统复杂度，细化颗粒度
2.子系统专人开发，细化专注点
3.解耦相关业务
4.可用不通语言脚本开发集成
5.子系统可横向扩展，独立部署
缺点
1.开发成本加大，开发应用难度也加大
2.测试方式调整，功能测试、性能测试难度加大（如全链路压测）
3.服务治理难度加大
4.存在分布式事物等问题
5.数据库层面部署及使用复杂（主从/双主/读写分离/分区/分库/分表等）

总结

根据业务发展过程，不要盲目使用微服务架构，此架构虽解耦细化应用，但同时也会带来很多问题。
正确使用微服务架构，提供系统高可用方案，促进各系统之间协作交互，保障系统正常运转
多系统耦合较强关系下，可采用MQ方式解耦

作者简介：张程 技术研究

更多文章请关注微信公众号：zachary分解狮 (frankly0423)