微服务相关

 

 

 

 

次要并且向后兼容的改变： 是可以随意发版

 

 

 

 

 

有一层抽象的层，这一层与产品经理描述的流程 保持一致。 如果整体流程不变，则这一层的代码就不用发生变化。
找出变化的部分，稳定的部分

 

 

 

 

 

当你觉得你的程序需要写注释才能理解时，说明这段代码需要抽成一个方法

 

 

 

 

 

 

 

 

1、熔断
2、降级

 

 

hystrix最近两年没有更新，可能一些特性的支持，有些单一

阿里的sential有些功能还没有开发完，在快速迭代 中

 

 

语言相关，有入侵

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

创建订单的消息，撤销订单的消息，修改订单的消息 
创建订单的消息比较多，阻塞了。创建订单的消息还没有消费, 撤销订单的消息已经来了，那么就与业务对顺序的强依赖有冲突
如果上面三类消息，都放到一个队列中，那么这个队列的消息比较多，解决方法是用多线程处理，仍有上面的问题

同一个订单都会分到一个分片中
路由键按照订单ID算出来的，这样 上面 三类消息，都可以路由到相同的队列中

 

尽量使用UK来保证幂等。通过select，check在并发场景，会有问题.insert和select同时进行，则会一定概率有问题

 

 

 在事务中不要发送消息，往一个事务表中插一条记录，有专门的定时任务来从 事务表中 捞数据，然后再发消息。这样可以避免 事务成功了，但消息发失败了。或消息发成功了，但事务回滚的问题