如何对 Service Fabric 应用程序进行版本化和分离？

Posted 2023-03-27

【中文标题】如何对 Service Fabric 应用程序进行版本化和分离？

【英文标题】：How to version and separate Service Fabric applications?

【发布时间】：2016-08-08 00:50:44

【问题描述】：

所有服务架构examples 都描述了单一解决方案服务架构示例。这似乎与微服务的哲学背道而驰，您希望在微服务之间实现完全的依赖隔离。虽然您可以手动遵循此模式，但更常见的做法是通过将每个服务设为自己的存储库和解决方案/项目来强制执行它。

您如何管理和部署 Service Fabric 服务，并使用多个解决方案（在多个 Git 存储库中）执行服务合同 (ServiceInferfaces)？

例如

Service Fabric Solution
      App1 - Customers
         - Service1 [Carts] From Other Solution
         - Service2 [LocationInfo]From Other Solution
         - Service3 [REST WebAPI for Admin] From Other Solution
      App2 - Products
         - Service4 [Status]From Other Solution
         - Service5 [Firmware]From Other Solution
         - Service6 [Event Stream] From Other Solution

External Solution
   - Service1
External Solution
   - Service2
External Solution
   - Service3

External Solution
   - Service4
External Solution
   - Service5
External Solution
   - Service6

1) 作为一名开发人员，我想检查并构建所有当前版本的应用程序/服务。我想启动管理所有清单的 Service Fabric 项目，并将其部署到我的本地开发集群。我想在解决方案之间强制执行相同的服务接口。我不明白你会怎么做，因为应用程序在服务之外。

2) 作为一个 DevOps 团队，我希望自动下载应用程序、构建它们并部署到 Azure。

我们如何通过单独的解决方案“强制”隔离，同时轻松地将它们整合在一起并部署到集群中，同时还可以轻松地制作管道以部署为 DEV、QA 和 PROD 环境单独配置的每个集群.

启用此功能的工作流/流程/项目结构是什么？有没有可能？

【问题讨论】：

一年过去了，这对你来说怎么样？我们正在考虑做类似的事情 - 但我无法弄清楚/找到如何做的例子。有什么可以给点建议的吗？

还想知道你是怎么做的吗？

【参考方案1】：

是的，有可能——我以前做过类似的事情。这些是立即浮现在脑海中的想法......

在每个 Service Fabric 解决方案中都有一个“公共”项目，其中仅包含您希望从该应用程序中的服务公开的接口。该项目的输出可以打包为 nuget 包并推送到私有存储库。我猜您可以将其称为“接口”项目，但如果您想将其中一些接口考虑到应用程序内部，则不必公开所有接口；这些可以在一个单独的、未公开的项目中定义。

想要引用其他应用程序公开的服务的其他解决方案只需拉下相关的 nuget 包以获取对服务接口的引用。

现在这并非没有问题：

消费应用程序仍然需要知道服务的地址，以便为它们构造代理。您可以将它们公开为在 nuget 包中某处定义的常量，或者如果您要走完整的 DI 路线并且不介意将自己耦合到任何地方的 DI 容器（或者想尝试将其抽象掉），您可以公开nuget 包中的一个模块，可以将服务接口注册为 lambda，它代表依赖的应用程序创建服务代理。 您更容易违反合同。您需要非常小心地更新方法签名，因为您现在负责应用程序/服务部署的粒度和协调。 您可能过于细化 - 正如您所提到的，Service Fabric 工具会引导您在一个解决方案中拥有多个服务。即使采用上述方法，我仍然会尝试在某种程度上对我的服务进行逻辑分组，即不要在应用程序和服务之间进行一对一的映射——这肯定会比它的价值更痛苦。

希望对您有所帮助。

编辑：

在 DI 模块中注册服务接口的示例，（Autofac 风格）...

这将是您从公共 nuget 包中公开的 DI 模块：

using System;
using Autofac;
using Microsoft.ServiceFabric.Services.Remoting.Client;

public class MyAppModule : Module

    protected override void Load(ContainerBuilder builder)
    
        builder.Register(component => ServiceProxy.Create<IMyService>(new Uri("fabric:/App/MyService"))).As<IMyService>();
        // Other services...
    

在您的消费应用程序的 Program.cs 中，您将包含以下内容：

public static void Main()

    try
    
        var container = ConfigureServiceContainer();

        ServiceRuntime.RegisterServiceAsync(
            "MyConsumingServiceType",
            context => container.Resolve<MyConsumingService>(new TypedParameter(typeof(StatefulServiceContext), context))).GetAwaiter().GetResult();
        ServiceEventSource.Current.ServiceTypeRegistered(Process.GetCurrentProcess().Id, typeof(MyConsumingService).Name);

        Thread.Sleep(Timeout.Infinite);
    
    catch (Exception e)
    
        ServiceEventSource.Current.ServiceHostInitializationFailed(e.ToString());
        throw;
    


private static IContainer ConfigureServiceContainer()

    var containerBuilder = new ContainerBuilder();

    // Other registrations...

    containerBuilder.RegisterModule<MyAppModule>();

    return containerBuilder.Build();

当然，这种方法只有在您不对服务进行分区时才有效...

【讨论】：

这很棒。我希望 MSDN/Azure 增加一些超出他们会议演示材料的 SF 示例。

你提到有一个包“可以将服务接口注册为一个 lambda 来创建服务代理......”你知道这个样板会是什么样子，或者可以指出我的权利吗方向？我对此的研究正在打开我已经点击的所有链接 =) 谢谢！

已编辑以包含一个简单的示例。

非常感谢您提供这个很棒的示例和您的回答。 @MikeGoatly 我想知道我们如何在微服务中对 BLL 进行版本控制？服务A需要调用服务B的v1，但是服务B已经升级到v2。 请注意，没有合同更改唯一的更改是服务 B 的 BLL。我们如何对这样的场景进行版本化？

@l--''''''---------'''''''''''' 这个答案中应该有足够的材料来提取回答你的场景。使用依赖注入（DI）结合服务结构版本控制机制，可能添加一些服务参数来引导 DI 解析

【参考方案2】：

您还可以使用耦合较少的协议，例如基于 http 的协议，使用 xml\wsdl 或 json\swagger 以及自动生成或手动创建的 httpclient 代理。

管理 nugget 库、nuspec 等的成本很高。

【讨论】：

如何对 BLL 进行版本控制？

BLL 你不需要......如果你的意思是数据实体是一个不同的问题并且取决于你的数据存储。