见有聊点分布式事务，求解一般微服务方案

[jiurenmeng]

例： 微服务：商城、商品、订单 备注：都为单独服务和数据

try{ //商品服务 处理商品扣库存 //订单服务 订单生成（ error ）？ return; }catch($e) { // ？怎么处理合适 }

[jiurenmeng]

例： 微服务：商城、商品、订单 备注：都为单独服务和数据
\r\n

```
try{
//商品服务 处理商品扣库存
//订单服务 订单生成（ error ）？
return;
}catch($e) {
// ？怎么处理合适
}
```

\r\n
只有单体应用开发经验，不知道怎么排版

[realpg]

每个独立的 operation 都有对应的撤销方法

[zhgg0]

1 、生成订单号
2 、预扣商品库存
3 、订单生成
4 、真的扣库存

订单服务提供反查功能，根据订单号查是否成功

各种状况：
1 和 2 失败没任何影响；
3 那步挂了，库存服务过段时间反查订单是否成功，没成功的话将库存恢复；
4 那步挂了，库存服务过段时间反查订单是否成功，成功的话变成真的扣库存。

[xuanbg]

要搞微服务，先搞 devops 。git 用起来，jenkins 自动化容器化部署搞出来先。同时 elk 或者 efk 搞起来，不要捞个日志还费死个劲。然后 maven 私服什么的也搞起来。。。

上面这些搞好了，然后把例如用户中心、消息中心这些基础服务拆出来搞起来。

最后，你去搞业务就非常轻松了。如果一上来就拆业务，累死你也搞不好微服务。

[love]

那撤销方法中间机器死机了呢，数据不一致了

[xuanbg]

@realpg
@love 基本没人会这么搞，分布式系统大多采用的是最终一致性。也就是说如果出错，不是回滚数据，而是用消息队列进行补偿来保证数据的一致性。当然补偿也不能保证百分百成功，最终还可以通过肉偿(人工处理)来保证一致性。

[singerll]

看到微服务就想笑，我们公司的微服务几十个 jar 包，挂一个就全挂。真不知道研发脑子里面想的啥。

[Leigg]

@singerll 那是技术问题

[Leigg]

最终一致性，善用 mq 和定时任务