当考虑NServiceBus中的服务时，您何时开始质疑服务处理的消息数量是多少并开始将这些消息分解为新服务？
请考虑以下事项：我有一个销售服务，目前可以分为几个不同的业务组件，这些是销售订单验证，销售订单处理，采购订单验证和采购订单处理。
目前，该服务中使用了大约20个消息处理程序和2个sagas。我担心的是，在我网站的大量流量中，这可能导致消息的初始峰值跳到数百个。考虑到消息需要按照从队列中取出的顺序进行处理，这可能导致队列中最后一个消息的延迟（取决于每个消息的处理方式）。
当将服务中的问题分成较小的业务组件时，我发现这会使事情变得容易一些。当然，这是一个合乎逻辑的分离，但它似乎提供了一层清晰和理解。对我而言，似乎比创建新服务更容易做到这一点，最终我拥有的服务越多，我需要做的维护就越多。
有没有人对此有任何类似的担忧？
答案 0 :(得分：1)
我认为你实际上回答了你自己的问题：）
只要消息量达到滞后成为问题的点，您就可以查看端点的实例。您不一定需要减少处理程序的数量。您可以简单地安装该服务多次，并通过映射将特定的消息类型发送到相关的端点。
因此，它成为一个简单的实例安装和一些配置更改的问题。因此，您可以在发送时拆分消息，以便来自特定源的消息最终在消息类型的特定端点（可能是优先级）或上。
我碰巧在以前的项目（不使用NServiecBus）上做同样的事情，我们需要来自UI的文档转换消息尽快处理。我们只是使用自己的一组队列再次安装转换服务，并更改了UI配置以将转换消息发送到新端点。后台转换消息仍然转到前一个端点。所以这里的来源确定了分离。