我正在学习 Service Fabric，许多资源似乎都可以使用 Service Fabric 远程处理来促进服务间通信。
然而，有关微服务架构的许多其他资源都指出，应避免服务间通信，并且如果需要，理想情况下应仅以异步方式进行(例如通过事件中心或服务总线)。通过这种方式，服务只是松散耦合的。
Service Fabric 远程处理是否会促进服务之间更紧密的耦合，从而可能抵消微服务架构的一些优势并引入脆弱性？或者使用 Service Fabric 时这些缺点是否会以某种方式得到缓解？
最佳答案
如果目标服务之一变得不可用或不健康，则将服务与运行时依赖项耦合在一起会导致问题。
顺丰已内置strategies应对不健康状况并可以进行滚动升级，从而降低停机风险。
另一个方面是服务调用服务共享一个模式。这也是耦合的一种形式。更改服务的架构可能需要其调用者也进行更改。 SF 并没有缓解这个问题。
在 bounded context 内协同工作的服务和参与者通常会一起更改，因此在这个范围内，一些紧密耦合是可以接受的。
跨域通信时，我仍然建议使用 Event Driven方法。要么 within集群，或使用外部代理，如 Azure Service Bus .
关于Azure Service Fabric - 服务互通和耦合，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49516375/