带有 API 和后台工作人员的微服务命名约定（MessageBus/ScheduledTasks）

Question

扩展这个现有问题微服务：工作者角色、API 或两者兼而有之？：

我见过将微服务实现为工作者角色处理队列外请求和/或 API (REST) 的混合示例。

支持异步场景，可以使用队列，通过一个简单的哑队列监听器将请求转发到微服务 REST API，而同步场景将直接调用 REST API。

我认为微服务这个术语的定义很模糊；人们是否将它们视为 API（例如 RESTful 服务）或任何抽象服务处理请求，但提供了该请求？

我们将使用什么命名约定来区分作为 API 运行的服务，或作为后台工作线程运行的服务（从消息队列中提取或每隔一段时间运行任务）？

区分这一点很重要，以便明确意图，因为 Web 应用程序的托管技术允许多个工作线程并行扩展，而我们可能希望在任何时间运行单个工作线程来执行预定的维护任务。

更多信息如下。

预定的后台工作者或 ServiceProxy

在某些情况下，我们可能会代理调度的后台工作人员来调用服务，即：

1. 运行工人
2. 不关机时出队
3. 发布到服务 -> https://myservice.example.com/assets/123?uptime=100&cpu=54

我们怎么称呼这样的ServiceProxy后台工作人员？我想如果我们担心并发问题和多个这些后台工作人员并行运行，那么这可以在调用服务本身时解决。

客户端库

我建议使用一个客户端库来包含：

1. 调用服务获取信息的方法
2. 发布到服务的方法（通过网络服务，在函数内透明处理）
3. 发布到服务的方法（通过消息总线，在函数内透明处理）

对于上面的第 2 点和第 3 点，除了有关如何发送数据的详细信息的函数名称之外，没有其他指示，即RegisterEndPoint(Guid id, string name)在内部使用标准的 WebAPI 调用和SendUpdate(Guid id, HealthPoco stats)使用消息总线……客户端将使用该库而不用担心细节。

项目结构

到目前为止，我有一个项目结构：

1. ExampleSolution.Assets.Service - 对于 WebAPI 或 gRPC 服务，其中多个可以并行运行
2. ExampleSolution.Assets.ServiceProxy - 这是一个后台工作者，通常我们想要一个运行
3. ExampleSolution.Assets.Client - 这是允许与服务通信的客户端库
4. ExampleSolution.Assets.Common - 相关的公共信息，如数据合同
5. ExampleSolution.EndPoint.CoreAgentApp - 在 Windows 或 Linux 工作站上运行的端点应用程序，还会有其他服务，例如 ExampleSolution.Warranty.* 等，为 Service/Client/Common 等重复
6. ExampleSolution.Managagement.Common - 通用数据库
7. ExampleSolution.Managagement.App - 调用每个单独的服务以建立视图的功能
8. ExampleSolution.Managagement.Website- 实际托管的 Asp.net MVC 应用程序，包括所有网页，调用 ExampleSolution.Managagement.App函数来检索视图和执行操作

我可能会将ExampleSolution.Managagement.*和ExampleSolution.EndPoint.CoreAgentApp项目放在一个单独的文件夹中，以表明这些是“应用程序”并与“服务”分开。

我已经看到https://github.com/dotnet-architecture/eShopOnContainers很清楚服务的组织方式，但不清楚计划任务将如何运行：

和https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-microservice-architecture

显示服务和 SignalrR 或其他消息总线服务及其项目命名约定的项目将很有用。

我不想发布主题或违反规则，如果有任何含糊不清或问题的意图不清楚，请告诉我，我会进一步扩展。