我发现跨队列链接工作流可能会创建比预期更复杂的工作流，而另一方面，创建更简单的消费者应用程序可以使代码更易于维护。
通过拆分前两个步骤，您的代码是否获得了可伸缩性或简单性？如果没有更详细的信息需要考虑，我可能不会拆分功能的前两个部分。我不认为直接存储抓取结果有什么问题。
我喜欢您的用于发送电子邮件的独立使用者，尽管您可能会考虑创建一个通用的电子邮件发送使用者，您的任何应用程序都可以使用它，并让消息格式包含适当的邮件部分，让使用者构造邮件并发送邮件。
我认为除了考虑找到简单性/复杂性、可伸缩性和可维护性之间的正确平衡之外，这里没有一个“正确”的答案。

微服务体系结构开始感到混乱和耦合。
通常，当你使用微服务时，你试图解耦的不是业务逻辑，而是它的组件/步骤的实现。你把你的业务逻辑应用程序变成一个分布式应用程序，但是应用程序的逻辑依赖和流程不一定改变，这就是为什么有时会感觉混乱。
通常与微服务解耦的是：

• • • 开发人员团队**
• • • 服务生命周期**（测试/发布/版本控制）
• • • 硬件依赖性**（例如，服务器中需要GPU或额外RAM等的服务）
• • • 软件依赖性**，如第三方软件包/dll/框架
• • • 运行时隔离**：在进程级别（容器）将一个服务与另一个服务分开。2避免一个组件的崩溃导致所有组件崩溃，并保护系统免受不安全/易受攻击的服务暴露所有组件的影响。
• • • 监测**：检查每个服务的日志消息、活动、运行状况数据、异常。
• • • 管理**：按服务扩展/重启/更新

作业计划

更具体地说，对于您的示例，我建议您研究作业调度解决方案，而不是消息代理。
两个好的框架是：

1. HangFire
2. Quartz.NET
   我主要使用HangFire之前，它不需要一个单独的专用服务器.

样品

Phoesion Glow中的This is a good sample of HangFire，Phoesion Glow是用于开发、部署和管理dotnet微服务的框架。在此示例中，Email Service接收作为作业*（消费者）* 的电子邮件请求，SampleService1创建/添加作业 （生产者）。
该示例还通过向Email Service发送请求和RemotePprocedureCall （RPC） 演示了服务间通信，Email Service负责添加作业并成功响应。（这不是必需的，因为SampleService1可以直接使用HangFire提交作业）

• 披露：我是Phoesion Glow * 的开发人员