微服务架构的分布式容错 · SOSP 2019 - 面向信仰编程 · /papers-aegean

[draveness]

https://draveness.me/papers-aegean/

[ParadiseWitch]

想问一下,博主用来画脑图的平台或者软件是什么,感觉很好看

[draveness]

想问一下,博主用来画脑图的平台或者软件是什么,感觉很好看

看看文章结尾

[hudingyu]

这篇文章的图片用的新的画图工具？

[draveness]

这篇文章的图片用的新的画图工具？

不是的

[sd1990]

为什么感觉文章里面说到的问题跟平时遇到的微服务问题不太一样呢？以主从复制模式为例，这里的主从复制应该是数据库的复制吧，运行业务代码的服务怎么设计主从的问题呢？

[draveness]

为什么感觉文章里面说到的问题跟平时遇到的微服务问题不太一样呢？

论文其实使用更正式（formal）的方式对问题进行了建模，但是仔细思考会发现没有太多区别

以主从复制模式为例，这里的主从复制应该是数据库的复制吧，运行业务代码的服务怎么设计主从的问题呢？

如下所示，A、B 和 C 三个服务构成的调用链，如果 B 节点收到 C 节点请求后挂了应该怎么处理？

A -> B -> C

将主从复制应用到微服务中，可能就是 B 服务的副本到请求时将该请求发送给其他副本保证请求不会丢失

A -> B -> C
     |
     v
     B

主从复制这些可能都解决不了微服务中容灾问题，论文给出的解决方案可能是 A 节点同时将数据发送给多个 B 节点，然后它们通过服务器垫片（限流和去重等功能）发送给 C 节点，加上论文中其他的方案可以保证请求得到有效地处理

  -> B
A -> B -> C Shim -> C
  -> B

[scbizu]

这种Server Shim的设计方式是不是就类似于sidecar了(比如说图中的C Shim就类似于C的sidecar)。还是C shim在设计上也是一个单独的service，那C Shim本身也应该保证高可用吧。如果 C Shim 在没写入request log之前就挂了，还是要依靠幂等形式的retry呀。至于多出来的一次Network I/O值不值得又是一次tradeoff(

[xinnjie]

@sd1990 为什么感觉文章里面说到的问题跟平时遇到的微服务问题不太一样呢？以主从复制模式为例，这里的主从复制应该是数据库的复制吧，运行业务代码的服务怎么设计主从的问题呢？

middle server如果有状态，就有会容灾的问题呀。状态可能很重，比如本地缓存了一部分修改数据还未回写db；或者很轻，只是会调用多个下级服务，但是每个调用途中都有宕机风险，如果宕机需要从中间状态恢复过来。
轻状态的举个例子，比如一个订单服务，它包含调用一个扣费服务和下单服务（非db操作，无法通过一次db事务完成），扣费后宕机了，要怎么办呢？如果有主从复制，备机能否继续下一步下单操作都是需要考虑和设计的