V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
m939594960
V2EX  ›  问与答

问几个关于微服务的问题

  •  
  •   m939594960 · 2018-06-14 09:59:00 +08:00 · 3123 次点击
    这是一个创建于 2114 天前的主题,其中的信息可能已经有所发展或是发生改变。

    1.微服务的数据库事务方面到底怎么做比较好?因为是金融类的项目,事务很重要.

    2.微服务具体要怎么拆分,有没有什么开源的例子,或者相对来说实践知识比较多的文章或者视频,现在都是概念还是很困惑.

    3.例如:我下单有三个流程:创建订单,修改余额,减少库存, 也有对应的三个微服务,那么我是再写一个下单的服务,还是在网关控制顺序去调用这 3 个微服务,然后直接返回结果呢?

    最后问下有什么微服务相关的比较好的文章,视频,文章,感觉查到的都比较笼统,适合在现有微服务的情况下优化,而不是从头做微服务

    第 1 条附言  ·  2018-06-14 23:43:41 +08:00
    不可能不拆的,

    修改余额这步,下单、充值、活动之类都设计,我总不可能每个服务都要单写一下修改余额,要是那样的话服务一多根本没办法维护好不?

    减少库存这步,无论是后台修改,前台下单,还有用户退货之类的,肯定都要有一套通用的服务去处理,总不可能每个地方写一套吧?


    还是我对微服务理解有问题?


    @sujin190 @Muninn @MiffyLiye
    22 条回复    2018-06-22 09:42:39 +08:00
    mfhh
        1
    mfhh  
       2018-06-14 10:12:00 +08:00   ❤️ 2
    耦合这么紧的三个流程我是不拆的。放到一个微服务里。
    keepongjl
        2
    keepongjl  
       2018-06-14 10:12:53 +08:00
    你问的这些东西,不是一两句能说清的吧
    sujin190
        3
    sujin190  
       2018-06-14 10:18:18 +08:00   ❤️ 1
    微服务本身界定的是独立功能独立服务吧,没说每个小操作单独封装,每个小操作独立封装完全是没经验的外行瞎传吧

    比如你刚才的,应该是两个微服务,下单和支付,创建订单和减少库存只属于下单功能的,修改余额只属于支付功能的,电商类来说下单成功但支付失败本身就是可接受的事情,只需要容错就行,不需要事务的吧

    当然如果你这三个必须在同一个事务中操作,那么最好就是一个是一个微服务提供的完整功能

    微服务想做事务除了两步提交,似乎也没有什么好的方法了吧,先请求一次所有微服务组件加载验证开数据库事务,再请求提交修改,但是似乎也没办法规避提交过程中又失败的情况
    luffysup
        4
    luffysup  
       2018-06-14 10:19:49 +08:00
    说的是啥 spring boot/cloud?
    m939594960
        5
    m939594960  
    OP
       2018-06-14 10:26:14 +08:00
    @keepongjl 我就想知道一个大概的概念,细节我可以自己了解.
    Muninn
        6
    Muninn  
       2018-06-14 11:14:39 +08:00
    不要强拆。

    楼主说的订单,余额,库存。 小点的系统一般是一起的。 但是如果很大,像京东那样,那很可能是需要分开的。
    但是来这里问的我估计业务量不大,所以说不要强拆。

    尤其是必须要走事务的,那就乖乖的放一个服务里走事务吧。

    如果非要拆怎么做呢? 事件驱动了解一下。
    需要一个可靠性很高的队列。然后还要写补偿机制,不好补偿了还需要产品流程配合。
    jjianwen68
        7
    jjianwen68  
       2018-06-14 11:28:26 +08:00
    也不要太微吧,过犹不及
    FinalDream
        8
    FinalDream  
       2018-06-14 11:39:53 +08:00
    说这几个在一个服务的不合适吧,库存的管理明显和商品属于一套的,下单肯定是要耦合多个服务的,这两大块都不拆开还是用单体架构更合适一些。

    一致性无非就是那几种,2PC,3PC,最终一致性
    alangz
        9
    alangz  
       2018-06-14 11:51:49 +08:00
    第一,并不是任何公司业务都适合微服务,这个你要权衡,不要让以后痛苦;
    第二,所谓微服务只是一种架构风格,现在没有一个标准,都是根据自己的业务场景和理解去实践的;
    第三,微服务架构本身就是一个分布式系统,若你多个服务的操作需要在一个事务中这就可能涉及到分布式事务;
    第四,目前普遍认为 Netflix 对微服务实践做的比较好,在 Java 的生态当中目前相关的组件他们都有开源,包括现在 spring cloud 很多组件都是他们的,因此你可以去看看他们的博客;
    MiffyLiye
        10
    MiffyLiye  
       2018-06-14 12:46:36 +08:00
    需要保持强一致性的业务只能放在同一个服务里,业务量小的时候问题不大。

    业务量大的时候一般选择保 Availability,牺牲强一致性,只要求最终一致性。
    例如,订单服务创建订单,但订单初始状态标记为待支付,然后
    a. 通过可靠的途径发送消息(可重发,不可少发),余额服务收到消息后修改余额,...
    或 b. 余额服务定期请求订单服务,查询待支付订单,然后处理,...
    或 c. ...
    余额服务处理完后通过可靠的方式通知订单服务处理成功或失败,订单服务将订单状态改为待发货或扣款失败(并通知其他服务“回滚”)。
    与库存服务的交互也类似。

    整个过程完全异步化,服务间只能保证最终一致性,要处理的各种异常(主要是网络异常)也变多,但是可以提升 Availability,系统的可维护性也可能会提高。
    m939594960
        11
    m939594960  
    OP
       2018-06-14 23:37:08 +08:00
    @Muninn 我觉得这三个要是不拆分的话,微服务就没啥意义了,因为那么多涉及到动余额的服务,我总不能每个程序里单独写一份修改余额把,那么多要修改库存的服务,我总不能每个程序里单独写一份修改库存吧。
    如果要是那样的话怎么应对需求的变更,例如对余额操作要加缓存、插入日志表之类的操作我总不能在每个服务中都进行一次修改吧,那样的话工作量会成百倍的增加
    m939594960
        12
    m939594960  
    OP
       2018-06-14 23:39:07 +08:00
    @mfhh 不可能不拆的,修改余额这步,下单、充值、活动之类都设计,我总不可能每个服务都要单写一下修改余额,要是那样的话服务一多根本没办法维护好不?
    mfhh
        13
    mfhh  
       2018-06-15 09:36:25 +08:00
    @m939594960 如果你业务小,拆服务带来的复杂度比放在一个原子事务里单独写要高的多,拆了不合算。不太了解楼主说每个程序里单独写一份修改余额的问题在哪里?如果只是代码复用,可以做成公用库。
    troywinter
        14
    troywinter  
       2018-06-15 10:08:29 +08:00
    微服务做分布式事务用两步提交是最差的方法,具体可以看 manning 出版的 microservice patterns,微服务的分布式事务一般是用 saga pattern 来做,这也是 netflix 实践过的比较成功的方案。
    m939594960
        15
    m939594960  
    OP
       2018-06-15 12:59:13 +08:00
    @troywinter 恩,我查查,十分感谢.
    Muninn
        16
    Muninn  
       2018-06-15 23:16:49 +08:00   ❤️ 1
    我觉得业务量小的时候,可以只要做个状态检查就行了。 比如库存可以为负,每当为负的时候就在控制台提示,啊,sb 了,快去给客户道歉取消订单吧。。

    然后要是经常出现,可以做一个显示的库存,再做一个真实的库存,比显示库存多几件当做容错。 一个数据库操作就几毫秒,性能不好点的,算几十毫秒。 这个碰撞的概率还是很小的。
    只要不做抢购秒杀什么的,不会有问题。

    秒杀的业务逻辑经常需要特殊处理,比如秒杀完了不是立刻给结果的,等会才给结果。。
    m939594960
        17
    m939594960  
    OP
       2018-06-20 10:11:45 +08:00
    @Muninn 我觉得你这个思想很危险,做程序要做保证不能出错,而不是出错的几率比较小. 很多不可控的东西,会无线放大这些错误.
    Muninn
        18
    Muninn  
       2018-06-20 14:24:21 +08:00
    @m939594960 哈哈 危险的是你这种追求完美的想法。

    程序不可能不出错,随着业务量和并发的上涨,各种地方都会出问题。

    你一万块可能就能做出来个和京东一模一样的站,但是你承载不了那么多用户。

    所有的创业企业,一开始的 app 都是从几千几万的投入开始的。但是发展大了以后,累计投入可能会有几个亿。

    而你的思想,是东西还没有卖出去一件,就想做一个别人投入几个亿做出来的可靠性的东西。

    记住,能被预见的并能提示你的出错不叫出错,它只是一个业务上需要处理的异常。
    m939594960
        19
    m939594960  
    OP
       2018-06-20 23:15:22 +08:00
    @Muninn 我十分反对你这种思想,当然会出问题,但是出的问题一定是想到可能会发生的,做好可能会发生的问题的预测与准备,而不是到一定量一定会发生的,然后就去调整所谓的逻辑,去避免这个问题。 你想想如果京东淘宝这类东西,为了避免秒杀并发过大容易超卖只有充值一万的会员 才能进行秒杀,那么这个项目能做到这么大么?技术是为业务服务的,而不是业务为了技术服务。
    Muninn
        20
    Muninn  
       2018-06-21 17:42:30 +08:00
    无法交流, 希望你能学会优先去理解别人的表达,确认理解了后再攻击。
    m939594960
        21
    m939594960  
    OP
       2018-06-21 21:22:41 +08:00
    @Muninn
    其实都不想跟你说这么多。
    1.你知道微服务是什么么?
    2.事务和状态检查有啥关系? 我要用事务就是为了不超卖?
    3.当库存为负的时候给客户道歉??然后要是经常出现????? 我真不知道作为一个程序员如何的不要脸才能跟运营说这种话
    4.性能不好点的,算几十毫秒。 这个碰撞的概率还是很小的? 你知道运营会怎么运营这个东西么?你知道商品并发购买的数量有多少么? 我告诉你我做的项目虽然不大,但是有些火的商品不去做控制想要一下超卖十几个还是太简单了。
    5.如果你的程序测试一压就超卖了,还能上线? 就算我去做个 2000 块的外包,也不可能让他那么容易就超卖

    还是。。。。你只是单纯的想给我讲一下库存的容错???
    Muninn
        22
    Muninn  
       2018-06-22 09:42:39 +08:00
    年轻人,火气不要那么大。
    我是工作了十几年的架构师,2015 年之后的生产项目都用的微服务架构。在你还在学校研究 js 和 php 的时候,我已经把英文的微服务资料看了很多遍了。当然这三年微服务也一直在进化,我也持续的在看新的技术演进。
    你问的问题很普遍,去用英文搜一下到处都是答案。

    我只是怕你不懂,给你个最终一致性的补偿模式的最简单的例子,结果你还是不懂。你确定你不需要先好好再去补补课吗?

    你想追求完美,给你个详细点的方案把,叫 tcc 模式。
    http://www.grahamlea.com/2016/08/distributed-transactions-microservices-icebergs/

    好好学习,别总想着攻击别人。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1116 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 18:49 · PVG 02:49 · LAX 11:49 · JFK 14:49
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.