微服务难点

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

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