我不完全理解的一个概念是单点。在我看来，每当您有多个服务时，A，B和C，涉及整个系统，那么，如果其中任何一个都无法做到整个系统，则无法做任何有用的事情（如果系统可能有用没有B，那么为什么首先需要B？）
例如，假设我们有一条管道，使得A发布了由B消费的事件，然后B发布了一条由C消耗的消息，并且这种数据流是整个系统的目的。
A ===> B ===> C
也许C是处理信用卡信息的服务：如果没有钱，业务不会真正运行！
由于这是一个消息传递系统，因此这些服务是"独立的"，因为如果一个人倒下，它不会导致另一个服务降低。好的，但是如果B降低，则C不会收到任何新消息，并且整个系统都无法实现其目的。那么，它有什么区别使拥有单独的服务A，B和C，而不是一项服务ABC？P>
[（a）（a）（a）] ===> [（b）（b）（b）] ===> [（c）（c）（c）（c）]
现在，即使一个复制的服务之一说（b）下降了用户的故事，由于克隆（b）节点的可用性。
此系统（在此范围内）没有一个失败点。
注意，您的设计使用消息传递或本质上是"松动的耦合"，很容易修改系统并删除故障点。
微服务的其他方面需要详细讨论。A 的前提帮助我理解与微服务保持一致的概念是比例立方体模型。
我认为您的问题是修辞。显然，如果系统取决于所有服务，则任何服务都是单个失败点。如果单个服务下降，则系统将不会"服务目的"。拥抱微服务不会自动从单点失败的问题中解放出您。
大多数微服务的支持者都会告诉您，您应该以整个系统不依赖任何一项服务的方式设计系统。但是，这样的系统对我来说听起来像是独角兽。这与说"如果删除代码的一部分，该应用程序应该继续工作"
是一样的。实际上，您可以设计一个系统，如果任何一项服务都会下降，则剩下一些实用程序。但是，我怀疑当缺少其重要组件之一时，有任何系统可以正常运行。当系统确实在没有其组件之一的情况下正常运行时，需要进行额外的错误检查等等，这是可怕的。
但是，这不是微服务的设计。这只是人们吹捧的所谓好处之一。只有当您设计系统以允许故障时，好处才会出现。但是，您无需使用微服务来做到这一点。
偶尔建立连接的客户可能是避免单点故障的另一种方法。git是一个很好的例子。如果Github失败了，您就不会有人坐在周围说："哦，看起来我今天不必做任何工作"。
注意：可以将负载平衡器扔到任何服务的前 将服务（'b'）视为平行道路或处理渠道的集合。一旦这些道路建造为设计（代码），他们将坐在那里运行。设计不会改变，因此处理不会改变，正如您所说的。但是，考虑道路会发展出非设计故障 - 硬件故障。道路表面在物理上是不可能的。交通无法流动，但是幸运的是，我们有许多平行道路可以吸收这种交通！如果我们只有1（宽）的道路，那么整个道路已经关闭以重新铺设，以免流量流动。 您可以进一步进行。想象一下，您的平行道路上的交通正在增加，道路处于容量状态。修建另一条单车道很容易。这并不多，但是一旦构建，您就可以允许它以最大的容量运行。但是土地租金花费金钱！因此，当交通减少时，我们可以轻松地退役这条小路而不支付租金。 您可以将其进一步采用 - 说您想出了新的道路设计，因此您可以在现有道路上构建Next
服务的不同部分在线上有不同的在线 - 能力需求。故障模式分析对于真正了解您需要在哪里分离服务并使它们更具弹性至关重要。例如，如果C分开是否对订购工作流程不合格，则可能没有用，但是由于它是如此重要，因此它应该获得其自己的额外弹性（多个主机上的多个失败工人）。
另一方面，如果C是一个履行系统（将挑选票发送到仓库），则不需要这种弹性水平，并且可以负担得起。这是关于确定失败点的位置，以及预防失败的价值。
除了故障模式外，还有要考虑的能力问题。信用卡处理可能与库存上市服务具有完全不同的规模需求。也许客户非常频繁地要求价格，因此，您可能需要支持比信用卡处理服务更大的容量。因此，您需要为服务的那部分建立更多的扩展能力。同样，该服务的失败可能比实际订单处理服务中的失败更容易接受（收入可能与投机性相比）。无论如何，您需要了解每种服务的价值，并找到使它们分开的方法，使您可以独立扩展其能力和弹性。
服务组成是微服务最困难的部分之一。没有阅读几本书，这里有一些准则。如果您正在寻找以下一些好处，那么闯入独立服务可能会很有意义：
- 重用逻辑。在您的示例中，如果其他服务也调用了服务C：d-> e-> C。当A和B下降时。
- deoupele tem。如果您是一支小型团队，则可能不需要数百个服务。但是，写下您的逻辑，以便以后可以将其分开。即使您一开始就没有将逻辑分解为独立的运行服务，也最好拥有"微服务"心态。
- 确保逻辑分离。当您的代码在整体中时，很容易作弊。如果您确实需要强迫自己或您的团队将两件事视为"分开"，以便您可以重新使用它，那么另一项服务可以强制这一点。
- 优化执行模式。如果您的系统必须同步响应，请进行异步工作，请处理大量的工作洪水（几分钟之内从0 rps到10,000 RPS），您可能希望将服务分开。轻巧的服务仅接收REST API调用并将其排队以进行实际工作，这可能正是您可以处理能够负担得起或异步响应的入站工作洪水所需的。轻量级服务可以以毫秒的速度旋转，从而可以快速响应不稳定的需求。如果您有12GB的Java野兽，那么扩展可能需要一段时间。
我还建议您明智地选择数据存储。可以花费大量时间来优化编码服务和随附的基础架构的可靠性，但是您仍然可以在数据库体系结构（或网络或负载均衡器或DNS或...）中使用单点进行失败。p>