业务架构改进一

1.交易太重，需拆分

冗余了多个业务。

且view层和交易流程服务在一个工程里。view层变化则需要影响核心流程。

当某个业务发生改变时，需要影响其它业务。

合代码经常冲突，并且容易出现合并错误，交易组下不同小组的人通常只熟悉自己负责的业务线。

2.redis单点

可以使用redis3.0或4的cluster架构。

3.事务补偿可以按各自业务有独立事务表,补单结合mq及事务表轮循

4.监控异常报错机制不及时

需要类似基于日志分析的系统，出现问题做报警。

很多异常客户反馈才知道。

5.业务限流及溶断

没有评估最大tps，没有做系统限流及溶断，系统在高tps下容易down机不可用。

6.当某个业务出现异常后，不影响核心业务使用

比如购买页，出现代金券系统异常，则做降级，保证核心产品购买流程。

7.相应写业务服务，dubbo retries不为0，当这个写业务本身出现慢的情况下，后续的dubbo重试容易压跨这个写业务服务。

产品份额扣减服务，需要设置为0.

8.对于高峰值的抢购业务，tps容量规则，及性能测试。

9.rocketmq目前存在单点风险，只有一组master/slave。如果master挂了相应发送消息的业务均不可用。

目前rocketmq没有自动主备切换功能。

需要配置多组，当其中一组master挂掉后，客户端可以写活着的那组master。