Я хотел бы объяснить несколько вещей, чтобы у вас была полная картина, чтобы лучше понять эту модель.
Розетки и Tcp
Скажем, у вас есть 3 услуги A, B, C. При каждом запросе клиента Вам необходимо звонить по http. Каждый раз, когда вы создаете http-клиент, под ним создается TCP-соединение и открывается сокет. Количество сокетов имеет жесткое ограничение, и если у вас очень большое количество http-вызовов, вы можете закончить проверкой всех соединений сокетов. Вот почему один HTTP-клиент должен быть повторно использован. В ядре .net вы можете использовать HttpClientfactory для достижения этой цели. Поэтому, если у вас есть 3 службы для вызова через http, вы можете открыть 3 отдельных http-соединения (сокета), которые будут использоваться повторно.
Пул потоков
Другая часть касается пула потоков. Даже когда вы звоните с использованием общего / единственного соединения с http-клиентом, вы все равно должны выделить поток для этого соединения. Допустим, у вас есть 100 потоков, которые можно использовать для удовлетворения запросов клиентов. Все, что превышает 100 запросов, будет поставлено в очередь. Теперь предположим, что вы вызываете три службы независимо, используя http с пулом соединений из 100 потоков. В счастливом пути каждый сервис вернется в прошлое, когда поток завершит работу (http-запрос завершен), он вернется в пул для выполнения следующего клиентского запроса из очереди. За все это время 100 потоков используют 3 общих экземпляра httpclient для вызова внешних служб, а под ними только 3 сокета. Так что мы хороши до этого момента.
Сбой службы
Теперь допустим, что одна служба работает медленно или не работает. Поскольку пул потоков (в нашем случае 100) является общим, и вы вызываете службу замедления / замедления, но потокам требуется больше времени для ответа. Другие 2 службы все еще в порядке и могут отвечать, но из-за ухудшенной службы любому потоку, вызывающему ухудшенную службу, потребуется больше времени для завершения запроса или в конечном итоге истечет время ожидания, прежде чем он вернется в пул потоков. что означает, что все больше и больше запросов в клинике стоят в очереди. На этом этапе запросы потребителя к другим (здоровым) услугам затрагиваются. В конце концов, потребитель больше не может отправлять запросы другим службам, а не только исходному не отвечающему сервису. Все ваши доступные потоки застряли в ухудшенном сервисе, и очередь все еще растет. Другие потребители больше не могут использовать эту услугу, вызывая эффект каскадного сбоя.
Переборка для спасения
Именно здесь переборка приходит на помощь. Разделите экземпляры службы на разные группы, основываясь на потребностях потребителей и доступности. Такая конструкция помогает изолировать сбои и позволяет поддерживать функциональность сервиса для некоторых потребителей даже во время сбоя.
Потребитель также может разделять ресурсы, чтобы ресурсы, используемые для вызова одной службы, не влияли на ресурсы, используемые для вызова другой службы. Например, потребителю, который вызывает несколько служб, может быть назначен пул соединений для каждой службы. Если служба начинает отказывать, она влияет только на пул соединений, назначенный для этой службы, что позволяет потребителю продолжать использовать другие службы.
Итак, из приведенного выше примера вы могли бы выделить 33 потока для каждой службы. Теперь сбойный сервис будет влиять только на потоки, выделенные для него. Работающие сервисы будут продолжать использовать выделенные им потоки без каких-либо проблем и будут продолжать выполнять клиентские запросы.
.Net Core и Polly
Полли - очень известная библиотека для обработки подобных ситуаций. Polly естественным образом согласуется с .Net Core, и вы можете назначить несколько политик http-клиентам, включая переборку.
Вы можете найти больше о Полли https://github.com/App-vNext/Polly
Надеюсь, это поможет!