我认为从来没有完全任何解决方案可以 100% 确定永远在两方之间丢失消息。即使您在两个服务之间有一个服务总线，也总是有机会（可能非常小，但绝不会为空）服务总线出现故障，或者与服务总线的通信出现故障。话虽如此，当然有些模型不太可能很少丢失消息，但您无法完全解决您仍然必须在客户端处理错误的事实。
事实上，Service Fabric 故障处理主要是围绕客户端重试通信而设计的，而不是让服务或中介来做这件事。这有很多原因（我猜），但其中之一是分布式、复制、可靠服务的性质。如果主服务出现故障，副本将承担责任，但它不会知道主服务在它死亡的那一刻正在做什么（除非它复制了它的状态，但它可能在此之前就已经死亡）。在这种情况下，唯一真正知道自己想要做什么的是客户端。客户端知道它在做什么，并且可以对服务中的不同故障场景做出反应。在 Fabric Transport 中，大多数已知的可能“自然”发生的异常，例如服务中断或网络电缆被管理员切断，实际上都会自动重试。这包括重新解析地址，以防万一主服务被替换为辅助服务。
对于引入第三个服务或服务总线的场景实际上也是如此。如果在消息完全到达服务之前网络出现故障怎么办？在这种情况下，只有客户端知道出了什么问题以及它打算发送什么。如果它在到达服务之后但在响应发送之前发生了故障怎么办？在这种情况下，客户端必须假设消息从未到达并尝试重新发送它。这也是为什么建议服务方法是幂等的 - 同一个客户端可以多次调用同一个调用。
即使您要引入辅助部件（如服务总线），仍然存在服务总线出现故障的风险，或者更可能是连接到服务总线的网络出现故障。因此，客户端需要重试，并且当它重试多次时，它所能做的就是将消息放入失败消息的队列中，或者只是将其记录下来，或者将异常抛出回原始调用者（在您的场景中，浏览器）。
好吧，那是我很悲观。但它可能会发生。以上所有的事情，只是有些不太可能发生。但它们可能会发生。
关于您的问题：
1) 使无状态服务有状态的问题是您现在必须在调用者中处理分区。您可以为有状态服务设置 Http 侦听器，但您必须在 Uri 中包含分区和副本信息，这不适用于负载均衡器，因此在这种情况下浏览器在调用 API 时必须选择分区。不是一个理想的解决方案。
2) 是的，您可以这样做，即在为您排队消息之间引入 something else。没有什么可以说服务总线或数据库比具有可靠队列的有状态服务更可靠，这取决于您选择最适合的方式。我会选择有状态服务，这样我就可以轻松地将所有内容保存在我的 SF 应用程序中。但同样，这并不是 100% 保护心怀不满的看门人用剪刀，因为您仍然需要能够处理故障的客户端。
3) 确保您有一种方法来处理错误（重试）并使用客户端（服务 1）记录或存储失败的消息（重试后）。
3.a) 一种方法是让它本地存储在它正在运行的节点上，并定期（例如 RunAsync）尝试重新运行那些失败的消息。在运行它的节点完全被核破坏并丢失数据的情况下，这可能是危险的，但是该数据不会被复制。
3.b) 另一种方法是将语义日志与 ETW 结合使用，并在事件中包含足够的数据，以便能够从日志中重新创建消息并构建一些功能，即手动 UI也许，您可以从记录的信息中重新运行它。就像您在服务总线中的错误队列上重试失败的消息一样。
3.c) 将失败的消息存储到不会失败的任何其他地方（数据库、服务总线、队列），原因与与服务 2 的通信相同。
我在这里的主要观点是（我可能已经开始了）是有很多场景只有客户知道足以处理这种情况。因此，请确保您有处理客户端故障的策略。