.NET micro services中的舱壁示例

在Sam Newman的“构建微服务”（O'Reilly）中，有一节名为舱壁，这是一章的一部分，该章讨论了如何防止阻塞的微服务干扰整个系统

如本节所述，舱壁的一个示例是有单独的连接池连接到每个下游服务

作者讨论的是对下游服务的同步调用，因此我将以上内容理解为“HTTP客户端池”

但是，在.NET中，为了提高可伸缩性，越来越多的人认为使用单例HTTP客户端是最佳实践

我是否认为在.NET中，这种舱壁不适用

如果有其他类型的舱壁，我们应该更关注哪些类型的舱壁

---

我想解释一些事情，这样你们就可以有完整的图片来更好地理解这个模式

套接字和Tcp

假设您有3个服务A、B、C。对于每个客户端请求，您都需要使用http调用它们。每次创建http客户端时，都会创建tcp连接并打开套接字。套接字的数量有硬限制，如果您有非常多的http调用，您可能最终会破坏所有套接字连接。这就是为什么需要重用单个http客户机。在.NETCore中，您可以使用HttpClientfactory来实现这一点。因此，如果您有3个服务要通过http调用，您可以在下面打开3个单独的http连接（套接字），它们将被重用

线程池

另一部分是关于线程池。即使使用共享/单例http客户端连接调用，您仍然必须为该连接分配线程。假设您总共有100个线程可用于满足客户端请求。任何超过100个请求都将排队。现在假设您正在使用连接池为100个线程的http独立调用三个服务。在快乐路径中，每个服务将及时返回，当线程完成工作（http请求完成）时，它将返回到池中，以完成队列中的下一个客户端请求。在此期间，100个线程正在使用3个共享httpclient实例调用外部服务，下面只有3个套接字。所以在这一点之前我们都很好

服务失败

现在让我们假设一个服务要么慢，要么慢。因为线程池（本例中为100）是共享的，并且您正在调用慢/慢服务，但是线程需要更长的时间来响应。其他两个服务仍然正常，可以响应，但由于服务降级，任何调用降级服务的线程都需要更长的时间来完成请求，或者在返回线程池之前最终超时。这意味着越来越多的clinet请求正在排队。此时，消费者对其他（健康）服务的请求将受到影响。最终，消费者不再能够向其他服务发送请求，而不仅仅是原始的无响应服务。所有可用的线程都被降级的服务卡住，队列仍在增长。其他使用者不再能够使用该服务，从而导致级联故障效应

舱壁救援

这就是舱壁来营救的地方。根据使用者负载和可用性要求，将服务实例划分为不同的组。此设计有助于隔离故障，并允许您为某些使用者（即使在故障期间）维持服务功能

使用者还可以对资源进行分区，以确保用于调用一个服务的资源不会影响用于调用另一个服务的资源。例如，调用多个服务的消费者可以为每个服务分配一个连接池。如果服务开始失败，它只会影响为该服务分配的连接池，从而允许使用者继续使用其他服务

所以，从上面的示例中，您会说请为每个服务分配33个线程。现在，失败的服务只会影响分配给它的线程。健康的服务将继续使用其分配的线程而不会出现任何问题，并将继续满足客户机请求

.Net Core和Polly

波利是处理这种情况的著名图书馆。Polly自然适合.NETCore，您可以将多个策略分配给http客户机，包括隔板

你可以找到更多关于波利的信息

希望有帮助