业务拆分请教一下大家

[bsg1992]

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

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

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

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

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

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

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

[sivacohan]

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

[Leigg]

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

[QZFCANBA]

rocketmq 事务消息

[jones2000]

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

[CoderGeek]

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

[bsg1992]

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

[bsg1992]

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

[CoderGeek]

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