这是一个创建于 2390 天前的主题，其中的信息可能已经有所发展或是发生改变。
1.微服务的数据库事务方面到底怎么做比较好?因为是金融类的项目,事务很重要.
2.微服务具体要怎么拆分,有没有什么开源的例子,或者相对来说实践知识比较多的文章或者视频,现在都是概念还是很困惑.
3.例如:我下单有三个流程:创建订单,修改余额,减少库存, 也有对应的三个微服务,那么我是再写一个下单的服务,还是在网关控制顺序去调用这 3 个微服务,然后直接返回结果呢?
最后问下有什么微服务相关的比较好的文章,视频,文章,感觉查到的都比较笼统,适合在现有微服务的情况下优化,而不是从头做微服务
 |
1
mfhh 2018-06-14 10:12:00 +08:00  2
耦合这么紧的三个流程我是不拆的。放到一个微服务里。
|
 |
2
keepongjl 2018-06-14 10:12:53 +08:00
你问的这些东西，不是一两句能说清的吧
|
 |
3
sujin190 2018-06-14 10:18:18 +08:00 1
微服务本身界定的是独立功能独立服务吧，没说每个小操作单独封装，每个小操作独立封装完全是没经验的外行瞎传吧
比如你刚才的，应该是两个微服务，下单和支付，创建订单和减少库存只属于下单功能的，修改余额只属于支付功能的，电商类来说下单成功但支付失败本身就是可接受的事情，只需要容错就行，不需要事务的吧 当然如果你这三个必须在同一个事务中操作，那么最好就是一个是一个微服务提供的完整功能 微服务想做事务除了两步提交，似乎也没有什么好的方法了吧，先请求一次所有微服务组件加载验证开数据库事务，再请求提交修改，但是似乎也没办法规避提交过程中又失败的情况 |
 |
4
luffysup 2018-06-14 10:19:49 +08:00
说的是啥 spring boot/cloud?
|
 |
5
m939594960 OP @keepongjl 我就想知道一个大概的概念,细节我可以自己了解.
|
 |
6
Muninn 2018-06-14 11:14:39 +08:00
不要强拆。
楼主说的订单，余额，库存。 小点的系统一般是一起的。 但是如果很大，像京东那样，那很可能是需要分开的。 但是来这里问的我估计业务量不大，所以说不要强拆。 尤其是必须要走事务的，那就乖乖的放一个服务里走事务吧。 如果非要拆怎么做呢？ 事件驱动了解一下。 需要一个可靠性很高的队列。然后还要写补偿机制，不好补偿了还需要产品流程配合。 |
 |
7
jjianwen68 2018-06-14 11:28:26 +08:00
也不要太微吧，过犹不及
|
 |
8
FinalDream 2018-06-14 11:39:53 +08:00
说这几个在一个服务的不合适吧，库存的管理明显和商品属于一套的，下单肯定是要耦合多个服务的，这两大块都不拆开还是用单体架构更合适一些。
一致性无非就是那几种，2PC，3PC，最终一致性 |
 |
9
alangz 2018-06-14 11:51:49 +08:00
第一，并不是任何公司业务都适合微服务，这个你要权衡，不要让以后痛苦；
第二，所谓微服务只是一种架构风格，现在没有一个标准，都是根据自己的业务场景和理解去实践的； 第三，微服务架构本身就是一个分布式系统，若你多个服务的操作需要在一个事务中这就可能涉及到分布式事务； 第四，目前普遍认为 Netflix 对微服务实践做的比较好，在 Java 的生态当中目前相关的组件他们都有开源，包括现在 spring cloud 很多组件都是他们的，因此你可以去看看他们的博客； |
 |
10
MiffyLiye 2018-06-14 12:46:36 +08:00
需要保持强一致性的业务只能放在同一个服务里，业务量小的时候问题不大。
业务量大的时候一般选择保 Availability，牺牲强一致性，只要求最终一致性。 例如，订单服务创建订单，但订单初始状态标记为待支付，然后 a. 通过可靠的途径发送消息（可重发，不可少发），余额服务收到消息后修改余额，... 或 b. 余额服务定期请求订单服务，查询待支付订单，然后处理，... 或 c. ... 余额服务处理完后通过可靠的方式通知订单服务处理成功或失败，订单服务将订单状态改为待发货或扣款失败（并通知其他服务“回滚”）。 与库存服务的交互也类似。 整个过程完全异步化，服务间只能保证最终一致性，要处理的各种异常（主要是网络异常）也变多，但是可以提升 Availability，系统的可维护性也可能会提高。 |
|
11
m939594960 OP @Muninn 我觉得这三个要是不拆分的话，微服务就没啥意义了，因为那么多涉及到动余额的服务，我总不能每个程序里单独写一份修改余额把，那么多要修改库存的服务，我总不能每个程序里单独写一份修改库存吧。
如果要是那样的话怎么应对需求的变更，例如对余额操作要加缓存、插入日志表之类的操作我总不能在每个服务中都进行一次修改吧，那样的话工作量会成百倍的增加 |
|
12
m939594960 OP @mfhh 不可能不拆的，修改余额这步，下单、充值、活动之类都设计，我总不可能每个服务都要单写一下修改余额，要是那样的话服务一多根本没办法维护好不？
|
|
13
mfhh 2018-06-15 09:36:25 +08:00
@m939594960 如果你业务小，拆服务带来的复杂度比放在一个原子事务里单独写要高的多，拆了不合算。不太了解楼主说每个程序里单独写一份修改余额的问题在哪里？如果只是代码复用，可以做成公用库。
|
 |
14
troywinter 2018-06-15 10:08:29 +08:00
微服务做分布式事务用两步提交是最差的方法，具体可以看 manning 出版的 microservice patterns，微服务的分布式事务一般是用 saga pattern 来做，这也是 netflix 实践过的比较成功的方案。
|
|
15
m939594960 OP @troywinter 恩,我查查,十分感谢.
|
|
16
Muninn 2018-06-15 23:16:49 +08:00 1
我觉得业务量小的时候，可以只要做个状态检查就行了。 比如库存可以为负，每当为负的时候就在控制台提示，啊，sb 了，快去给客户道歉取消订单吧。。
然后要是经常出现，可以做一个显示的库存，再做一个真实的库存，比显示库存多几件当做容错。 一个数据库操作就几毫秒，性能不好点的，算几十毫秒。 这个碰撞的概率还是很小的。 只要不做抢购秒杀什么的，不会有问题。 秒杀的业务逻辑经常需要特殊处理，比如秒杀完了不是立刻给结果的，等会才给结果。。 |
|
17
m939594960 OP @Muninn 我觉得你这个思想很危险,做程序要做保证不能出错,而不是出错的几率比较小. 很多不可控的东西,会无线放大这些错误.
|
|
18
Muninn 2018-06-20 14:24:21 +08:00
@m939594960 哈哈 危险的是你这种追求完美的想法。
程序不可能不出错，随着业务量和并发的上涨，各种地方都会出问题。 你一万块可能就能做出来个和京东一模一样的站，但是你承载不了那么多用户。 所有的创业企业，一开始的 app 都是从几千几万的投入开始的。但是发展大了以后，累计投入可能会有几个亿。 而你的思想，是东西还没有卖出去一件，就想做一个别人投入几个亿做出来的可靠性的东西。 记住，能被预见的并能提示你的出错不叫出错，它只是一个业务上需要处理的异常。 |
|
19
m939594960 OP @Muninn 我十分反对你这种思想，当然会出问题，但是出的问题一定是想到可能会发生的，做好可能会发生的问题的预测与准备，而不是到一定量一定会发生的，然后就去调整所谓的逻辑，去避免这个问题。 你想想如果京东淘宝这类东西，为了避免秒杀并发过大容易超卖只有充值一万的会员 才能进行秒杀，那么这个项目能做到这么大么？技术是为业务服务的，而不是业务为了技术服务。
|
|
20
Muninn 2018-06-21 17:42:30 +08:00
无法交流， 希望你能学会优先去理解别人的表达，确认理解了后再攻击。
|
|
21
m939594960 OP @Muninn
其实都不想跟你说这么多。 1.你知道微服务是什么么？ 2.事务和状态检查有啥关系？ 我要用事务就是为了不超卖？ 3.当库存为负的时候给客户道歉？？然后要是经常出现？？？？？ 我真不知道作为一个程序员如何的不要脸才能跟运营说这种话 4.性能不好点的，算几十毫秒。 这个碰撞的概率还是很小的？ 你知道运营会怎么运营这个东西么？你知道商品并发购买的数量有多少么？ 我告诉你我做的项目虽然不大，但是有些火的商品不去做控制想要一下超卖十几个还是太简单了。 5.如果你的程序测试一压就超卖了，还能上线？ 就算我去做个 2000 块的外包，也不可能让他那么容易就超卖 还是。。。。你只是单纯的想给我讲一下库存的容错？？？ |
|
22
Muninn 2018-06-22 09:42:39 +08:00
年轻人，火气不要那么大。
我是工作了十几年的架构师，2015 年之后的生产项目都用的微服务架构。在你还在学校研究 js 和 php 的时候，我已经把英文的微服务资料看了很多遍了。当然这三年微服务也一直在进化，我也持续的在看新的技术演进。 你问的问题很普遍，去用英文搜一下到处都是答案。 我只是怕你不懂，给你个最终一致性的补偿模式的最简单的例子，结果你还是不懂。你确定你不需要先好好再去补补课吗？ 你想追求完美，给你个详细点的方案把，叫 tcc 模式。 http://www.grahamlea.com/2016/08/distributed-transactions-microservices-icebergs/ 好好学习，别总想着攻击别人。 |
Select Language