ServiceFabric代理的初始调用非常缓慢。

Question

每当我从一个Service Fabric服务调用另一个服务时，代理的第一次调用非常慢，即比所有后续调用慢100倍。我在记录调用之前和服务方法被调用时的时间，并且这很容易超过60秒！ Service Fabric集群是在12个节点/虚拟机上运行的独立集群。

有趣的是，第一次调用所需的时间似乎与节点数相关，即如果我停用了一半的节点，则时间会缩短（但不会减半）。此外，当在我的本地PC上运行开发集群上完全相同的代码时，第一次调用所需的时间通常约为8秒，而两个系统上的后续调用都需要小于10ms。此外，在同一客户端进程中创建到同一服务的另一个代理仍会导致快速调用时间，似乎代理工厂（我认为SF每个客户端进程缓存）在代理首次使用时创建并花费很长时间。

有趣的是，没有抛出任何异常，服务实际上可以正常工作！

因此，我的问题是，为什么使用ServiceProxy.Create()创建的代理进行从一个服务到另一个服务的调用时，第一次调用需要这么长时间？

- BazMan

Answer 1

根据SF远程文档（见下文，重点在于），ServiceProxy.Create是ServiceProxyFactory的包装器，第一次调用还涉及设置工厂以进行后续调用。

ServiceProxyFactory是一个工厂，用于创建不同的远程接口代理。 如果您使用API ServiceProxy.Create来创建代理，则框架会创建单例ServiceProxyFactory。 当您需要覆盖IServiceRemotingClientFactory属性时，手动创建一个很有用。 工厂是昂贵的操作。 ServiceProxyFactory维护通信客户端的缓存。 最佳实践是尽可能长时间地缓存ServiceProxyFactory。

- Stephen O

Answer 2

我从未遇到过像你那样的缓慢解析问题，不过我会在API服务启动时使用依赖注入创建代理。

我的系统设置方式是无状态API服务（asp.net core）与后端SF服务通信。

也许我实际上经历了更长时间的延迟，但当我开始使用应用程序时，解析过程已经开始并完成，而不是在我发出第一个请求时才开始解析。

    private void InitializeContainer(IApplicationBuilder app)
    {
        // Add application presentation components:
        Container.RegisterMvcControllers(app);
        Container.RegisterMvcViewComponents(app);

        // Add application services.
        Container.Register(() => ServiceProxy.Create<IContestService>(FabricUrl.ContestService), Lifestyle.Transient);
        Container.Register(() => ServiceProxy.Create<IFriendService>(FabricUrl.FriendService), Lifestyle.Transient);
        Container.Register(() => ServiceProxy.Create<IUserService>(FabricUrl.UserService), Lifestyle.Transient);
        Container.Register(() => ServiceProxy.Create<IBillingService>(FabricUrl.BillingService), Lifestyle.Transient);
        Container.RegisterSingleton(AutoMapperApi.Configure());

        // Cross-wire ASP.NET services (if any). For instance:
        Container.RegisterSingleton(app.ApplicationServices.GetService<ILoggerFactory>());
        // NOTE: Prevent cross-wired instances as much as possible.
        // See: https://simpleinjector.org/blog/2016/07/
    }

- The Muffin Man