未分類
23 8 月 2020

业务拆分请教一下大家

业务拆分请教一下大家

資深大佬 : bsg1992 8

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

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

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

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

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

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

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

大佬有話說 (8)

  • 資深大佬 : sivacohan

    单体能解决的问题不要瞎搞。
    拆解之后还想要和单体一样的事务级别，你至少要付出十倍的开发成本。

  • 資深大佬 : Leigg

    你遇到的就是分布式事务问题，一般常用的是对列，定时任务，最后是人工补偿，做好流水记录就行，不要思维固化就想着实现一个 [分布式事务] ，大部分场景只需要最终一致性。

  • 資深大佬 : QZFCANBA

    rocketmq 事务消息

  • 資深大佬 : jones2000

    目前最好的方法就是花钱提升数据库服务器性能， 投 10W-20W 硬件基本就完事了， 钱到位机器上线就可以搞定的，成本最低。

  • 資深大佬 : CoderGeek

    必须要拆分的话 异步肯定就消息队列 保证发送与重试 还有
    事务强一致不现实 保证有正向反向接口 要看业务来
    前提业务接收你最终一致

  • 主 資深大佬 : bsg1992

    @sivacohan
    因为有些业务太臃肿 越来越难维护

  • 主 資深大佬 : bsg1992

    @CoderGeek 必须拆分之前就因为业务涉及到钱的问题，一直拖着没搞，导致出现一大坨的代码。维护也不好维护。
    原本打算想逐步演进到微服务架构上，后来考虑成本问题给否决了。

  • 資深大佬 : CoderGeek

    @bsg1992 那就要充分做好测试，还有上线切量 与回滚的方案 涉及资金的都不是小事 除非你们不在乎