作为后续这个问题 https://stackoverflow.com/questions/64560997/servicestack-messaging-api-can-it-make-a-broadcast，我想了解如何改进我对服务的手动调用。这比我想要的要长，但我觉得需要背景信息。
在执行 pub/sub（广播）时，不使用消息 API 中的正常顺序和流程，而是在收到 pub/sub 消息时使用 IRedisClient、IRedisSubscription 获得回调：
_subscription.OnMessage = (channel, msg) =>
{
onMessageReceived(ParseJsonMsgToPoco(msg));
};
那个行动onMessageReceived然后，将依次调用普通的 .NET/C# 事件，如下所示：
protected override void OnMessageReceived(MyRequest request)
{
OnMyEvent?.Invoke(this, new RequestEventArgs(request));
}
这可行，我收到了我的请求以及所有这些，但是，我希望将其简化为另一个流程，即消息传递 API 中的流程，这意味着请求找到了进入Service类实现，并且所有正常的样板文件和依赖项注入都像使用消息传递 API 一样发生。
因此，在我的事件处理程序中，我手动调用该服务：
private void Instance_OnMyEvent(object sender, RequestEventArgs e)
{
using (var myRequestService = HostContext.ResolveService<MyRequestService>(new BasicRequest()))
{
myRequestService.Any(e.Request);
}
}
并且确实找到了 MyRequestService 并调用了 Any，并且依赖项注入适用于该服务。
问题一：
- 方法如
OnBeforeExecute, OnAfterExecute等，不会被调用，除非我手动调用它们，例如：myRequestService.OnBeforeExecute(e)等等。管道的哪些部分丢失了？是否可以通过某种简单的方式恢复它，这样我就不必按顺序手动调用它们中的每一个？
问题2：
我认为当我这样做时我弄乱了 DI 系统：
using (var myRequestService = HostContext.ResolveService<MyRequestService>(new BasicRequest()))
{
myRequestService.OnBeforeExecute(e.Request);
myRequestService.Any(e.Request);
myRequestService.OnAfterExecute(e.Request);
}
我看到的效果是我注册的注入依赖项container.AddScoped，没有范围，但看起来是静态的。我看到这一点是因为我在注入的类中有一个 Guid，并且在这种情况下该 Guid 始终相同，而每个请求的 Guid 应该不同。
container.AddScoped<IRedisCache, RedisCache>();
OnBeforeExecute（Service 的后代）类似于：
public override void OnBeforeExecute(object requestDto)
{
base.OnBeforeExecute(requestDto);
IRedisCache cache = TryResolve<IRedisCache>();
cache?.SetGuid(Guid.NewGuid());
}
因此，IRedisCache Guid 每次都应该不同，但事实并非如此。然而，当我“从头到尾”使用 Messaging API 时，这工作得很好。看来，如果我在 AppHostBase 后代中调用 TryResolve，则会忽略 AddScoped，并将一个实例放置在容器中，然后永远不会删除。
