微服务难点

总结一下:微服务下的几个难点问题及解决方案

SingleOneMan 2019-04-02 01:42:58  3247  收藏 9
展开
总结一下:微服务下的几个难点问题及常见的解决方案
文章目录
总结一下:微服务下的几个难点问题及常见的解决方案
1.接口幂等
2.分布式事物
3.接口超时
4.接口限流

环境
springboot1.5.9

记录一下项目开发和技术研究中遇到的微服务难点,能够解决项目问题的才是适合的,目前能力有限,只能持续迭代开发。

1.接口幂等
参考:https://cloud.tencent.com/developer/news/136205

https://blog.csdn.net/xichenguan/article/details/78085801

场景:同一个订单多次执行;

电商订单的创建;

页面的多次提交问题;

并发下的计数问题;

大型系统中的消息消费问题;

解决:

1)选择为业务单号加上唯一的索引或者组合索引,在并发的场景中,只有第一笔插入的交易请求能够成功,后续的请求哪怕是慢1ms或者更短时间,都会触发数据库的唯一索引异常而失败,那么你可以捕获这个异常;不能仅仅依赖先去查询一下订单,

2)Redis是提供分布式节点下的原子事务操作的,

又或者你想把幂等放在服务的最前端,减少实际服务处理的资源浪费,在请求一到达时就提前去重,不让他有执行的机会,那么你可以考虑引入一个redis或类似的组件,将业务请求单号缓存在这个分布式锁的组件内。那么,每当订单发起交易请求,交易系统会去Redis缓存中查询是否存在该订单号的Key,如果不存在,则向Redis增加Key为订单号。查询订单是否已经执行,如果没有则转发到交易系统,执行完成后删除该订单号的Key。当然,Redis是提供分布式节点下的原子事务操作的。

幂等只是一个承诺,一个概念,保证调用多次返回结果的一致性,具体实现需要考虑多种环境下的高并发情况,并根据不同的场景选择合适的方案;

对于新增的幂等性问题,可以配合数据库的唯一索引进行控制;
对于数据的更新幂等性问题,可以通过悲观锁,乐观锁,缓存的分布式锁来控制并发;
对于页面的多次提交,可以通过token机制进行控制;
消息消费的场景,可以通过在消息上设置一个taskid来进行控制
实际项目中的后台接口涉及到数据库的:db联合唯一索引,唯一性约束。

2.分布式事物
参考:https://www.jianshu.com/p/16b1baf015e8

https://www.cnblogs.com/jiangyu666/p/8522547.html

https://blog.51cto.com/4925054/2115667

前人总结的方案很多,但是实现起来未必适用项目,综合考虑了下,基于rocketmq的开源版实现事物消息,基于事物消息实现分布式事物。rocketmq4.3.0才放出事物消息,不过思路类似。

3.接口超时
参考:

https://www.jianshu.com/p/d68d572b0613

https://blog.csdn.net/qqwangjiahao/article/details/54578528

https://blog.csdn.net/sinat_36710456/article/details/83379782

实际项目中:核心逻辑的调用会有重试机制+重试次数达到设置的次数,进入消息队列+扫描任务定时处理

4.接口限流
参考:

https://www.cnblogs.com/codeon/p/6123863.html

http://www.cnblogs.com/exceptioneye/p/4783904.html

https://www.zybuluo.com/kay2/note/949160

https://blog.csdn.net/fanrenxiang/article/details/80949079

https://www.cnblogs.com/strugglesdd/p/7773418.html

https://www.cnblogs.com/softidea/p/6229543.html

http://ifeve.com/分布式限流/
————————————————
版权声明:本文为CSDN博主「SingleOneMan」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/yhhyhhyhhyhh/article/details/88961011

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页