서비스 패브릭 애플리케이션의 버전을 지정하고 분리하는 방법은 무엇입니까?

서비스 패브릭 애플리케이션의 버전을 지정하고 분리하는 방법은 무엇입니까?

모든 서비스 패브릭 예제에는 단일 솔루션 서비스 패브릭 예제가 나와 있습니다.이는 서비스 간의 완전한 종속성 분리를 원하는 마이크로서비스의 철학에 반하는 것으로 보입니다.수동으로 이 패턴을 따를 수도 있지만, 일반적인 방법은 각 서비스를 자체 저장소 및 솔루션/프로젝트로 만들어 적용하는 것입니다.

여러 Git 저장소에서 여러 솔루션을 사용하여 서비스 패브릭 서비스를 관리 및 구현하고 서비스 계약(서비스 인터페이스)을 시행하는 방법은 무엇입니까?

예.

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

개발자로서, 저는 모든 최신 버전의 앱/서비스를 확인하고 구축하고 싶습니다.모든 매니페스트를 관리하는 서비스 패브릭 프로젝트를 시작하여 로컬 개발 클러스터에 배포하고 싶습니다.솔루션 간에 동일한 서비스 인터페이스를 적용하고자 합니다.애플리케이션이 서비스 외부에 있기 때문에 어떻게 이 작업을 수행하는지 이해할 수 없습니다.

DevOps 팀으로서 저는 앱을 자동으로 해체하고 구축하여 Azure에 배포하고 싶습니다.

어떻게 하면 별도의 솔루션을 통해 격리를 "시행"할 수 있을 뿐만 아니라, 솔루션을 하나로 묶어 클러스터에 구축하는 동시에 DEV, QA 및 PROD 환경에 맞게 고유하게 구성된 각 클러스터를 구현할 수 있는 파이프라인을 쉽게 만들 수 있을까요.

이를 가능하게 하는 워크플로우/프로세스/프로젝트 구조는 무엇입니까?그게 가능할까요?

네, 가능합니다. 저는 전에 이 노선을 따라 무언가를 해본 적이 있습니다.이런 생각들이 즉시 떠오릅니다...

각 서비스 패브릭 솔루션에는 해당 애플리케이션의 서비스에서 노출하려는 인터페이스만 포함된 "퍼블릭" 프로젝트가 있습니다.이 프로젝트의 출력은 너겟 패키지로 포장되어 개인 저장소로 푸시될 수 있습니다."인터페이스" 프로젝트라고 할 수도 있지만, 애플리케이션 내부의 인터페이스 중 일부를 고려하려면 모든 인터페이스를 노출시킬 필요가 없습니다. 이러한 인터페이스는 별도의 노출되지 않은 프로젝트로 정의할 수 있습니다.

다른 애플리케이션에 의해 노출된 서비스를 참조하려는 다른 솔루션은 서비스 인터페이스에 대한 참조를 얻기 위해 관련 nugget 패키지를 풀다운하기만 하면 되었습니다.

문제가 없는 것은 아닙니다.

• 사용 중인 애플리케이션은 여전히 서비스에 대한 프록시를 구성하기 위해 서비스의 주소를 알아야 합니다.당신은 그것들을 너겟 패키지의 어딘가에 정의된 상수로 노출시키거나, 만약 당신이 전체 DI 경로를 따라 가고 있다면, 모든 곳의 DI 컨테이너에 당신 자신을 결합하는 것을 개의치 않을 수 있습니다(또는 그것을 추상화하려고 시도하는 것을 상상할 수 있습니다)종속 애플리케이션을 대신하여 서비스 프록시 생성을 수행하는 람다로 서비스 인터페이스를 등록할 수 있는 모듈을 nuget 패키지에서 노출할 수 있습니다.
• 당신은 계약 파기에 훨씬 더 취약합니다.이제 애플리케이션/서비스 배포의 세분화 및 조정을 담당하기 때문에 메서드 서명을 업데이트하는 데 매우 주의해야 합니다.
• 말씀하신 것처럼 서비스 패브릭 툴링을 사용하면 하나의 솔루션에 여러 서비스를 포함할 수 있습니다.위의 접근 방식에도 불구하고 저는 여전히 어느 정도는 서비스를 논리적으로 그룹화하려고 노력할 것입니다. 즉, 애플리케이션과 서비스 간의 일대일 매핑을 시도하지 마십시오. 이는 분명히 가치보다 더 큰 고통이 될 것입니다.

도움이 되길 바랍니다.

편집:

DI 모듈에 서비스 인터페이스를 등록하는 예(Autofac 스타일)...

다음은 공개 너겟 패키지에서 노출하는 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();
}

물론 이 방법은 서비스를 파티션으로 분할하지 않는 경우에만 사용할 수 있습니다.

또한 xml\wsdl 또는 json\swagger를 사용하거나 자동 생성되거나 수동으로 생성된 httpclient 프록시를 사용하여 덜 느슨하게 결합된 프로토콜(예: http 기반)을 사용할 수 있습니다.

nugget lib, nusspec 등의 관리 비용이 높습니다.

언급URL : https://stackoverflow.com/questions/36657458/how-to-version-and-separate-service-fabric-applications