所以我很难理解一些关于微服务和其间通信的概念。虽然我不希望得到特定于技术的答案，但如果这有助于回答我的问题，我正在使用asp.net核心web api。
场景
我的资源是一个小部件。此小部件可以通过以下两种方式之一进行更新：
- 由用户通过UI
- 通过外部事件(发布到总线的消息(
假设
基于各种文章、博客等，我也在以下假设下工作：
- 微服务应该拥有自己的数据。因此，在这种情况下，我应该只有一个微服务拥有小部件资源
- 用户的直接更新表示请求/响应通信，因此建议使用REST
- 事件消息表明我还应该连接到队列并处理来自总线的消息
- 消息使用者最好作为服务运行，而不是在IIS中托管的web项目中运行
问题
因此，基于上述内容，我考虑创建一个作为windows服务运行的ASP.NET Core项目。我知道.net核心2.1最近有一些变化，这让这变得更加容易。
这与只创建两个服务形成对比，一个用于处理其余调用，另一个用于消耗总线消息，这似乎违背了我的第一个假设，而且从长远来看更难维护。
所以我的问题是
- 我的假设有效吗
- 在这样的服务中混合通信方法是个好主意吗？还是应该创建两个服务(每种通信类型一个(
- 有没有其他方法更符合微服务背后的意识形态
- 如果我在node中这样做，那么让node处理来自总线的消息以及传入的REST调用的方法是否相似
记住为什么使用微服务。使用它们本身并不是一个目标。它们是实现某些目的的工具，例如强制模块化、独立部署和更多的并行开发。
对于它们的大小，没有通用的指导。让它们尽可能小并不是一个目标。相反，找到正确的大小。不是最小的尺寸。
因此，将直接和异步数据更新划分为两个服务似乎是可疑的。根本不需要驾驶。
由于微服务应该拥有自己的数据，因此这两个问题都由在该数据上运行的单个微服务来管理是很自然的。
此外，避免混合通信方法也是一个非目标。
消息使用者最好作为服务运行，而不是在IIS 中托管的web项目中运行
从技术上讲，这不是真的。为了实现冗余，您需要在每个队列上运行多个使用者。你永远不能依赖于有一个单一的消费者，或者总是至少有一个消费者。因此，windows服务不会给您带来任何好处。在我看来，在一个普通的web应用程序中这样做是没有问题的。它还可以为您节省对windows服务的需求。它们很难处理(部署有点麻烦(。
在我看来，为了满足某些抽象的指导，你把事情搞得过于复杂了。不要基于这种笼统的指导进行设计。建筑师针对具体情况。
据我所知，您所需要的只是一个承载IIS的ASP.NET web应用程序，它可以完成所有这些工作，包括数据处理。但是，如果您觉得有必要引入一项服务，那么您可以考虑将数据处理拆分为另一个ASP.NET web应用程序，该应用程序为UI应用程序提供服务。该服务将包括检索和更改数据的方法，以及异步更新的某种通知(如事件，但跨越服务边界(。