Question

我不完全理解的一个概念是单点故障。在我看来，只要您有多个服务（例如A，B和C）涉及整个系统，那么如果其中任何一个服务在整个系统中都无法使用，就可以了”不能做任何有用的事情（如果没有B的系统就可以有用，那么为什么一开始甚至需要B？）。

例如，假设我们有一个管道，A发布一个B消费的事件，然后B发布一个C消费的消息数据流就是整个系统实现其目的的方式。

A ===> B ===> C

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

由于这是一个消息传递系统，因此这些服务是“独立的”，即如果一个服务中断，则不会导致另一个服务中断。好的，但是如果B出现故障，那么C将不会收到任何新消息，并且整个系统都无法满足其目的。那么，拥有单独的服务A，B和C而不是单独的服务ABC有什么区别？

Answer 1

将服务（B）视为平行道路或处理渠道的集合。一旦将这些道路构建成设计（代码），它们就会在那里运作。设计不会改变，因此处理也不会改变，而且正如您所说。但是，考虑到道路发展出非设计性故障-硬件故障。路面在物理上是不可通行的。交通无法通过，但是幸运的是我们有许多平行的道路可以吸收这种交通！如果我们只有1条（宽）道路，则整条道路都已关闭以进行重铺路面，以免交通阻塞。

您可以更进一步。想象一下，您的平行道路上的交通量正在增加，而道路已达到极限。修建另一条单线道路很容易。这虽然不多，但是一旦构建完成，就可以使其以最大容量运行。但是土地租金要花钱！因此，当交通减少时，我们可以轻松停用这条小路而无需支付租金。

您可以更进一步-假设您提出了新的道路设计，因此您可以在现有道路的下一步中进行构建。您可以允许这条道路上的交通并测试其运行方式。如果设计中存在未知错误，则可能会丢失一些流量。但是大多数流量都可以通过您现有的良好道路。现在，我们可以更改设计，也可以保留它，然后慢慢将每条小路更改为新设计。

Answer 2

服务的不同部分具有不同的在线容量需求。失败模式分析对于真正了解需要在何处分离服务并使它们更具弹性的至关重要。例如，如果C对于订购工作流不是可选的，则也许对分离C没有用，但是由于C非常重要，因此C应该具有自己的附加弹性（在多个主机上具有多个故障转移工人）。

反之，如果C是一个执行系统（将检票单发送到仓库），则它不需要那种弹性，就可以承受下来。这是关于确定故障点在哪里以及防止这些故障的价值。

除了故障模式外，还需要考虑容量问题。与库存清单服务相比，信用卡处理可能具有完全不同的缩放需求。也许客户非常频繁地询问价格，因此，与信用卡处理服务相比，您可能需要支持更多容量。因此，您需要为该部分服务建立更多的扩展能力。同样，与实际订单处理服务中的故障相比，该服务中的故障可能更容易接受（收入可能与投机有关）。无论如何，您都需要了解每种服务的价值，并找到拆分服务的方法，以使您能够分别扩展其容量和弹性。

Answer 3

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

[（A）（A）（A）] ===> [（B）（B）（B）] ===> [（C）（C）（C）]

现在，即使其中一项复制服务说（B）出现故障，由于克隆（B）节点的可用性，用户故事也将完成。

此系统（在此范围内）没有单点故障。

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

微服务的其他方面需要详细讨论。可以帮助我理解与微服务一致的概念的前提是Scale cube model。

Answer 4

服务组合是微服务中最困难的部分之一。在不阅读有关这本书的几本书的情况下，这里有一些准则。如果您正在寻找以下一些好处，那么进入独立服务可能是有道理的：

重用逻辑。在您的示例中，如果服务C也被其他服务调用：D-> E->C。如果您怀疑自己的逻辑可以或应该被其他服务占用，则将服务C创建为独立服务意味着您甚至可以为该逻辑的客户服务当A和B下降时。
解耦团队。如果您是一个小型团队，则可能不需要数百种服务。但是，请编写您的逻辑，以便以后可以将其分离。即使一开始不将逻辑分解为独立的运行服务，也要有“微服务”的心态。
确保逻辑分离。当您的代码处于整体中时，很容易作弊。如果您确实需要强迫自己或您的团队将两件事视为“分开”以便可以重复使用，则另一种服务可以强迫这样做。
优化执行模式。如果您的系统必须同步响应，异步工作，处理大量入站工作（几分钟之内从0 rps到10,000 rps），您可能希望将服务分离出来。仅需要REST API调用并将其排队以进行实际工作的轻量级服务可能正是您处理入站工作量所需要的，您可以负担得起异步处理或响应的工作量。轻量级服务可以在几毫秒内加速运行，从而对不稳定的需求做出快速响应。如果您有12GB的Java野兽，则放大可能需要一段时间。

我还建议您明智地选择数据存储。优化编码服务和相关基础结构的可靠性可能要花费大量时间，但您的数据库体系结构（或网络或负载平衡器或dns或...）中仍然可能存在单点故障。

Answer 5

我认为您的问题是口头禅。显然，如果系统依赖于所有服务，则任何服务都是单点故障。如果一项服务出现故障，系统将不会“达到其目的”。拥抱微服务不会自动将您从单点故障的问题中解放出来。

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

实际上，您可以设计一个系统，其中在任何一项服务出现故障时都剩下一些实用程序。但是，我怀疑是否有任何系统在缺少其重要组件之一时能否正常运行。当系统在没有其组件之一的情况下正常运行时，所需的额外错误检查之类的工作量就太恐怖了。

但是事实是，这不是微服务设计的目的。那只是人们吹捧的所谓好处之一。只有在您设计允许故障的系统时，收益才会显现出来。但是，无论如何，您无需使用微服务即可。

使偶尔连接的客户端成为另一种避免单点故障的方法。 Git是一个很好的例子。如果GitHub出现故障，您将没有人围坐在一起说：“哦，看来我今天不必做任何工作。”

注意：负载平衡器可以扔到任何服务的前面，这样物理计算机就不会成为单点故障。

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

5 个答案: