威尔背景服务在kubernetes群集上很好地发挥作用

Question

我有一个kubernetes群集，我打算在吊舱中实现服务 - 该服务将接受GRPC请求，开始长期运行的过程，但返回到呼叫者，以表明该过程已经启动。调查表明， iHostedService （ backgroundService ）是这样做的方法。

我的问题是，将使用 backgroundService 与ASP.NET和K8S的各种整洁功能表现得很好：

• 将水平缩放理解，即使该服务将出现，服务即使将出现，服务都将过载并旋转新实例由于所有工作都是背景（我感谢可以实现的挂钩，我想知道默认行为是什么），
• 等待互换了，另一个与背景服务的运行正常（我只在收到一条消息的情况下经历了等待，因此可以处理另一条消息，但是背景服务不是消息传递上下文
• ） ASP.NET通常会管理限制太多请求，如果服务器太忙，请备份，但是如果“忙碌”是背景过程，则该请求仍然有效，
• 这是减轻超载服务的最佳方法（如果水平扩展为不是一个选项） - 我可以将GRPC调用reutrn“太忙”，但需要检测到它（不确定这是CPU绑定，内存还是仅仅是背景服务的数量），
• 我是否应该考虑除 backgroundServiceServiceserviceserviceserviceserviceserviceserviceservices服务。 对于此任务，

我希望答案是“一切都起作用”，但要确认它比希望...确认更好...

Answer 1

调查表明，iHostedService（BackgroundService）是这样做的方法。

i 强烈推荐带有单独的背景服务队列。分为两个图像，一个运行ASP.NET GRPC请求，另一个处理耐用队列的图像并不难（这可以是控制台应用程序 - 请参见VS中的服务工作者模板）。请注意，使用 non 的解决方案是不可靠的（即，每当pod重新启动或缩放时，工作可能会丢失）。这包括内存的队列，通常建议将其作为“解决方案”。

如果您确实在控制台应用程序中制作自己的背景服务，建议您应用几个调整（在我的博客上注明）：

• wrap executeasync in task.run 。
• 始终具有顶级<代码>在 executeasync 中尝试/ catch 。
• 调用 ihostapplicationlifetime.stopapplication 出于任何原因停止时。

将水平缩放了解，即使服务似乎没有待处理的GRPC请求，服务即使所有工作都是背景（我很感谢可以实现的挂钩），即使该服务似乎没有待处理的GRPC请求，也可以实现新实例的水平扩展。想知道什么是默认行为）

我更喜欢使用两个不同图像的原因之一是它们可以在不同的触发器上扩展：GRPC请求API和对工作人员的排队消息。根据您的队列，使用“排队消息”作为触发器可能需要自定义公制提供商。我确实更喜欢使用“排队消息”，因为它是工人形象的自然缩放机制。诸如CPU使用之类的开箱即用解决方案并不总是很好地工作 - 特别是对于您正在使用的异步处理器而言。

是否会等待允许当前过程进行交换，而另一项运行的工作也可以使用背景服务（我只在收到一条消息收到的命中率上等待着它，因此可以处理另一个消息，但是背景服务是不是消息传递上下文）

背景服务可以是异步的，而不会出现任何问题。实际上，批次获取消息并同时处理它们并不少见。

我认为ASP.NET通常会管理限制太多请求，如果服务器太忙，请备份，但是如果“忙碌”是背景过程，则任何一个仍然可以正常工作

编号ASP.NET只有节气门请求，则该请求仍然有效。背景服务确实在ASP.NET上注册，但这仅是 在优雅的关闭时提供最佳效果。 ASP.NET不知道背景服务有多忙，在待处理的队列项目，CPU使用或即将发出的请求方面。

减轻服务过载的最佳方法是什么（如果不是水平缩放的选项） - 我可以让GRPC调用REUTRN“太忙”，但需要检测到它（不确定这是否是CPU绑定，内存，内存，或仅数量的背景服务）

如果您使用耐用的队列 +独立的工作图像解决方案，则不是问题。 GRPC呼叫几乎总是可以在队列中添加另一个消息（非常简单且快速），并且K8可以根据您（可能是自定义的）“出色的队列消息”的指标自动估算。

Answer 2

通常，“一切都起作用”。
对于自动水平尺度，您需要一个自动制剂，请阅读以下内容：
但是您可以自己扩展（ kubectl量表部署您的删除 - replicas = 10 ）。

假设您将部署后端，这将从一个POD开始。您的Autoscaler会观看您的吊舱（例如使用CPU），并在您的负载高时为您启动一个新的豆荚。

将开始第二个吊舱。每个新请求都会发送到不同的POD（圆形旋转）。
没有必要，您的后端油门通话。它应该尽可能处理许多电话。