V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
bsg1992
V2EX  ›  程序员

业务拆分请教一下大家

  •  
  •   bsg1992 · 2020-08-26 17:35:20 +08:00 · 1638 次点击
    这是一个创建于 1569 天前的主题,其中的信息可能已经有所发展或是发生改变。

    有时会遇到业务逻辑太长涉及的东西比较多。

    比如库存 账户余额增减 订单修改 消息通知,对 N 多个表进行删除 更新 添加,为了保证事务的一致性都是套在一个事务里进行操作。

    这样做会非法耗时感觉也不好。

    如果是微服务架构做业务拆分比较合理。

    如果是单体架构为了业务解耦拆分,引用事件或者队列进行业务异步处理。

    但是这样就导致了事务拆分成了 N 个事物,不能保证一致性。为了保证一致性加入重试机制,这样也会导致单体架构的臃肿。

    遇到这情况大家技术上如何处理比较好呢

    8 条回复    2020-08-28 20:01:25 +08:00
    sivacohan
        1
    sivacohan  
       2020-08-26 17:49:19 +08:00 via iPhone
    单体能解决的问题不要瞎搞。
    拆解之后还想要和单体一样的事务级别,你至少要付出十倍的开发成本。
    Leigg
        2
    Leigg  
       2020-08-26 18:18:06 +08:00 via Android
    你遇到的就是分布式事务问题,一般常用的是对列,定时任务,最后是人工补偿,做好流水记录就行,不要思维固化就想着实现一个 [分布式事务] ,大部分场景只需要最终一致性。
    QZFCANBA
        3
    QZFCANBA  
       2020-08-26 18:42:38 +08:00
    rocketmq 事务消息
    jones2000
        4
    jones2000  
       2020-08-27 02:10:50 +08:00
    目前最好的方法就是花钱提升数据库服务器性能, 投 10W-20W 硬件基本就完事了, 钱到位机器上线就可以搞定的,成本最低。
    CoderGeek
        5
    CoderGeek  
       2020-08-27 10:34:40 +08:00
    必须要拆分的话 异步肯定就消息队列 保证发送与重试 还有
    事务强一致不现实 保证有正向反向接口 要看业务来
    前提业务接收你最终一致
    bsg1992
        6
    bsg1992  
    OP
       2020-08-28 09:12:28 +08:00
    @sivacohan
    因为有些业务太臃肿 越来越难维护
    bsg1992
        7
    bsg1992  
    OP
       2020-08-28 09:19:05 +08:00
    @CoderGeek 必须拆分之前就因为业务涉及到钱的问题,一直拖着没搞,导致出现一大坨的代码。维护也不好维护。
    原本打算想逐步演进到微服务架构上,后来考虑成本问题给否决了。
    CoderGeek
        8
    CoderGeek  
       2020-08-28 20:01:25 +08:00
    @bsg1992 那就要充分做好测试,还有上线切量 与回滚的方案 涉及资金的都不是小事 除非你们不在乎
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2980 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 11:47 · PVG 19:47 · LAX 03:47 · JFK 06:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.