问几个关于微服务的问题

[m939594960]

1.微服务的数据库事务方面到底怎么做比较好?因为是金融类的项目,事务很重要.

2.微服务具体要怎么拆分,有没有什么开源的例子,或者相对来说实践知识比较多的文章或者视频,现在都是概念还是很困惑.

3.例如:我下单有三个流程:创建订单,修改余额,减少库存, 也有对应的三个微服务,那么我是再写一个下单的服务,还是在网关控制顺序去调用这 3 个微服务,然后直接返回结果呢?

最后问下有什么微服务相关的比较好的文章,视频,文章,感觉查到的都比较笼统,适合在现有微服务的情况下优化,而不是从头做微服务

[mfhh]

耦合这么紧的三个流程我是不拆的。放到一个微服务里。

[keepongjl]

你问的这些东西，不是一两句能说清的吧

[sujin190]

微服务本身界定的是独立功能独立服务吧，没说每个小操作单独封装，每个小操作独立封装完全是没经验的外行瞎传吧

比如你刚才的，应该是两个微服务，下单和支付，创建订单和减少库存只属于下单功能的，修改余额只属于支付功能的，电商类来说下单成功但支付失败本身就是可接受的事情，只需要容错就行，不需要事务的吧

当然如果你这三个必须在同一个事务中操作，那么最好就是一个是一个微服务提供的完整功能

微服务想做事务除了两步提交，似乎也没有什么好的方法了吧，先请求一次所有微服务组件加载验证开数据库事务，再请求提交修改，但是似乎也没办法规避提交过程中又失败的情况

[luffysup]

说的是啥 spring boot/cloud?

[m939594960]

@keepongjl 我就想知道一个大概的概念,细节我可以自己了解.

[Muninn]

不要强拆。

楼主说的订单，余额，库存。 小点的系统一般是一起的。 但是如果很大，像京东那样，那很可能是需要分开的。
但是来这里问的我估计业务量不大，所以说不要强拆。

尤其是必须要走事务的，那就乖乖的放一个服务里走事务吧。

如果非要拆怎么做呢？ 事件驱动了解一下。
需要一个可靠性很高的队列。然后还要写补偿机制，不好补偿了还需要产品流程配合。

[jjianwen68]

也不要太微吧，过犹不及

[FinalDream]

说这几个在一个服务的不合适吧，库存的管理明显和商品属于一套的，下单肯定是要耦合多个服务的，这两大块都不拆开还是用单体架构更合适一些。

一致性无非就是那几种，2PC，3PC，最终一致性

[alangz]

第一，并不是任何公司业务都适合微服务，这个你要权衡，不要让以后痛苦；
第二，所谓微服务只是一种架构风格，现在没有一个标准，都是根据自己的业务场景和理解去实践的；
第三，微服务架构本身就是一个分布式系统，若你多个服务的操作需要在一个事务中这就可能涉及到分布式事务；
第四，目前普遍认为 Netflix 对微服务实践做的比较好，在 Java 的生态当中目前相关的组件他们都有开源，包括现在 spring cloud 很多组件都是他们的，因此你可以去看看他们的博客；

[MiffyLiye]

需要保持强一致性的业务只能放在同一个服务里，业务量小的时候问题不大。

业务量大的时候一般选择保 Availability，牺牲强一致性，只要求最终一致性。
例如，订单服务创建订单，但订单初始状态标记为待支付，然后
a. 通过可靠的途径发送消息（可重发，不可少发），余额服务收到消息后修改余额，...
或 b. 余额服务定期请求订单服务，查询待支付订单，然后处理，...
或 c. ...
余额服务处理完后通过可靠的方式通知订单服务处理成功或失败，订单服务将订单状态改为待发货或扣款失败（并通知其他服务“回滚”）。
与库存服务的交互也类似。

整个过程完全异步化，服务间只能保证最终一致性，要处理的各种异常（主要是网络异常）也变多，但是可以提升 Availability，系统的可维护性也可能会提高。

[m939594960]

@Muninn 我觉得这三个要是不拆分的话，微服务就没啥意义了，因为那么多涉及到动余额的服务，我总不能每个程序里单独写一份修改余额把，那么多要修改库存的服务，我总不能每个程序里单独写一份修改库存吧。
如果要是那样的话怎么应对需求的变更，例如对余额操作要加缓存、插入日志表之类的操作我总不能在每个服务中都进行一次修改吧，那样的话工作量会成百倍的增加

[m939594960]

@mfhh 不可能不拆的，修改余额这步，下单、充值、活动之类都设计，我总不可能每个服务都要单写一下修改余额，要是那样的话服务一多根本没办法维护好不？

[mfhh]

@m939594960 如果你业务小，拆服务带来的复杂度比放在一个原子事务里单独写要高的多，拆了不合算。不太了解楼主说每个程序里单独写一份修改余额的问题在哪里？如果只是代码复用，可以做成公用库。

[troywinter]

微服务做分布式事务用两步提交是最差的方法，具体可以看 manning 出版的 microservice patterns，微服务的分布式事务一般是用 saga pattern 来做，这也是 netflix 实践过的比较成功的方案。

[m939594960]

@troywinter 恩,我查查,十分感谢.

[Muninn]

我觉得业务量小的时候，可以只要做个状态检查就行了。 比如库存可以为负，每当为负的时候就在控制台提示，啊，sb 了，快去给客户道歉取消订单吧。。

然后要是经常出现，可以做一个显示的库存，再做一个真实的库存，比显示库存多几件当做容错。 一个数据库操作就几毫秒，性能不好点的，算几十毫秒。 这个碰撞的概率还是很小的。
只要不做抢购秒杀什么的，不会有问题。

秒杀的业务逻辑经常需要特殊处理，比如秒杀完了不是立刻给结果的，等会才给结果。。

[m939594960]

@Muninn 我觉得你这个思想很危险,做程序要做保证不能出错,而不是出错的几率比较小. 很多不可控的东西,会无线放大这些错误.

[Muninn]

@m939594960 哈哈 危险的是你这种追求完美的想法。

程序不可能不出错，随着业务量和并发的上涨，各种地方都会出问题。

你一万块可能就能做出来个和京东一模一样的站，但是你承载不了那么多用户。

所有的创业企业，一开始的 app 都是从几千几万的投入开始的。但是发展大了以后，累计投入可能会有几个亿。

而你的思想，是东西还没有卖出去一件，就想做一个别人投入几个亿做出来的可靠性的东西。

记住，能被预见的并能提示你的出错不叫出错，它只是一个业务上需要处理的异常。

[m939594960]

@Muninn 我十分反对你这种思想，当然会出问题，但是出的问题一定是想到可能会发生的，做好可能会发生的问题的预测与准备，而不是到一定量一定会发生的，然后就去调整所谓的逻辑，去避免这个问题。 你想想如果京东淘宝这类东西，为了避免秒杀并发过大容易超卖只有充值一万的会员 才能进行秒杀，那么这个项目能做到这么大么？技术是为业务服务的，而不是业务为了技术服务。

[Muninn]

无法交流， 希望你能学会优先去理解别人的表达，确认理解了后再攻击。