微服务和“单点故障”概念

Question

我不完全理解的一个概念是单点故障。在我看来，每当你有多个服务，比如A，B和C，涉及到整个系统，那么如果它们中的任何一个出现故障，整个系统就不能做任何有用的事情(如果系统在没有B的情况下也是有用的，那么为什么首先需要B呢？)

例如，假设我们有一个管道，A发布一个由B使用的事件，然后B发布一个由C使用的消息，这个数据流就是整个系统服务于其目的的方式。

A ===> B ===> C

也许C是处理信用卡信息的服务:如果没有钱进来，业务就不会真正运行！

由于这是一个消息传递系统，因此这些服务是“独立的”，即如果一个服务出现故障，也不会导致另一个出现故障。好的，但是如果B宕机了，那么C将不会收到任何新的消息，整个系统也不会发挥它的作用。那么，拥有独立的服务A、B和C而不是一个服务ABC又有什么区别呢

Answer 1

稍微修改系统并添加冗余。

(A)(A)(A) ===> (B)(B)(B) ===> (C)(A)(B)(B)(B)===>(C)(A)(A)(B)(C)(C)(A)(B)(C)(A)(B)(B

现在，即使其中一个复制的服务(B)关闭，由于克隆(B)节点的可用性，用户故事也会完成。

此系统(在此范围内)没有单点故障。

需要注意的是，您的设计使用了消息传递或本质上是“松耦合”的，因此很容易修改系统并删除故障点。

微服务还有其他方面需要详细讨论。Scale cube model是的一个有远见的，它帮助我理解了与微服务相一致的概念。

Answer 2

我认为你的问题是反问式的。显然，如果系统依赖于所有服务，那么任何服务都是单点故障。如果一个服务出现故障，系统将不会“服务于它的目的”。拥抱微服务不会自动将您从单点故障问题中解放出来。

微服务的大多数支持者都会告诉您，您应该以这样一种方式设计您的系统，即整个系统不应该依赖于任何一个服务。但是，对我来说，这样的系统听起来就像是独角兽。这和说“如果你删除了一大块代码，应用程序应该继续工作”是一样的。

实际上，您可以设计一个系统，在该系统中，如果任何一个服务发生故障，都会留下一些实用程序。但是，我怀疑当它的一个重要组件丢失时，是否有任何系统可以正常运行。当一个系统在没有组件的情况下能够正常工作时，需要额外的错误检查等等，这是非常可怕的。

但问题是，这不是微服务设计的目的。这只是人们吹捧的好处之一。只有当您在设计系统时考虑到故障时，才能带来好处。但是，无论如何你都不需要使用微服务来做到这一点。

建立偶尔连接的客户端可以是避免单点故障的另一种方法。Git就是一个很好的例子。如果GitHub宕机了，你不会有人坐在那里说“哦，看起来我今天不需要做任何工作了”。

注意:负载均衡器可以放在任何服务的前面，这样物理机就不会成为单点故障。

Answer 3

可以将服务('B')看作是并行道路或处理通道的集合。一旦这些道路按照设计(代码)建造，它们就会在那里运行。设计不会改变，所以处理也不会改变，它会按照你说的做。然而，考虑到道路发生了非设计故障-硬件故障。路面在物理上是不能通行的。交通不能流动，但幸运的是，我们有许多平行的道路可以吸收这些交通！如果我们只有一条(宽)路，整条路都被关闭，以便重新铺设路面，这样就没有车辆可以通行了。

您可以更进一步。想象一下，平行道路上的交通流量正在增加，道路已经达到了最大容量。建造另一条单车道道路很容易。这不是很多，但是一旦它构建完成，您就可以允许它以最大容量运行。但是地租是要花钱的！因此，当交通量减少时，我们可以很容易地停用这条小路，而不需要支付房租。

你可以更进一步--假设你想出了一个新的道路设计，所以你把它建在现有道路旁边。您可以允许交通进入此道路，并测试其操作方式。如果您的设计中存在未知错误，某些流量可能会丢失。但是大部分的交通都可以通过你现有的良好道路。现在我们可以改变设计，也可以保留它，慢慢地将每一条小路改变成新的设计。