幂等性与微服务

幂等性

幂等性的使用场景?
    业务开发中，经常会遇到重复提交的情况，无论是由于网络问题无法收到请求结果而重新发起请求，或是前端的操作抖动而造成重复提交情况.
    exp: 1. 用户在app上连续点击多次提交订单,后台应只生成一个订单
         2. 向支付宝发起支付请求，由于网络问题或系统BUG重发，支付宝应该只扣一次钱。 
            很显然，声明幂等的服务认为，外部调用者会存在多次调用的情况，为了防止外部多次调用对系统数据状态的发生多次改变，将服务设计成幂等。
    为什么要设计幂等性服务?
        幂等可以使得客户端逻辑处理变得简单，但是却以服务逻辑变得复杂为代价.
            增加了额外控制幂等的业务逻辑，复杂化了业务功能；
            把并行执行的功能改为串行执行，降低了执行效率。
    如何处理幂等性问题?防重复
        关键在于要有唯一标识,比如id,订单号,可以防止多次支付的问题
        如何避免出现重复提交的问题?
            1.当提交完成之后,将按钮置为不可按状态
            2.每当访问一个页面的时候生成一个唯一的token,存储在数据库中,目的是在于对比传入的token是否唯一
              如果多次提交则,会检测到token已被提交过一次,则此次提交无效
    乐观锁: 通过版本号控制
    悲观锁: select * from ** for update
    两者的区别: 悲观锁和乐观锁是数据库用来保证数据并发安全防止更新丢失的两种方法, 
        响应速度：如果需要非常高的响应速度，建议采用乐观锁方案，成功就执行，不成功就失败，不需要等待其他并发去释放锁
        重试代价：如果重试代价大，建议采用悲观锁
        冲突频率：如果冲突频率非常高，建议采用悲观锁，保证成功率，如果冲突频率大，乐观锁会需要多次重试才能成功，代价比较大
    Redis分布式锁
        操作完成之后删除值,防止多次提交

微服务

什么是微服务?
    微服务架构的系统是一个分布式的系统,按业务进行划分为独立的服务单元,解决单体系统的不足,同时满足越来越复杂的业务需求
    什么是单体架构?
        将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上.
    单体架构的不足?
        随着项目的复杂程度的提高,代码的可读性和可维护性很差,同时面对大并发量的时候会受到很大压力
    什么是微服务    
        微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。
        这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。
        这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。
    微服务的优势?
        1. 将复杂业务拆分为多个小的业务,每个业务拆分为一个服务,将复杂问题简单化.利于分工,降低新人的学习成本
        2. 微服务系统是分布式系统,业务与业务之间完全耦合,随着业务的增加可以根据业务在进行拆分,具有极强的横向扩展能力
           面对搞并发的场景可以将服务集群化部署，加强系统负载能力。
        3. 服务间采用HTTP通信,服务于服务之间完全独立.每逢服务可以根据业务场景进行选取合适的编程语言和数据库
        4. 微服务每个服务都是独立部署的,每个服务的修改和部署对其他服务没有影响
    微服务和SOA的联系
        SOA是面向服务的架构, SOA是根据企业服务总线(ESB)模式整合继承大量单一庞大的徐彤,微服务可以说是SOA的一种实现
        将复杂的业务组件化.但它比ESB实现的SOA更加轻便敏捷和简单