ソフトウェア＆コンポーネントによって使用される一般的なマイクロサービスアーキテクチャ：

ドッキングウィンドウ（成熟したアプリケーション）

春のブート％春の雲（技術動向）

サービスファブリック（新星の背後には、マイクロソフトのクラウドドライブの一部です）

四一般的に使用されるマイクロサービスアーキテクチャソリューションは、ZeroC IceGrid、春の雲、キューベースのメッセージングおよびドッカースウォームです。

実際の生産モデルのほとんどは、たとえば、ベストプラクティスは、使用の組み合わせである雲+ドッカ春。

マイクロサービス特性 - 継続的インテグレーション（ジェンキンス、スナップ-CI）、建物（Mavenの、のGradle）、展開（ドッカー）、連続送達（ジェンキンス）、ログ集合（ELK、Splunkの）、操作および保守（のZabbix、Nagiosの警告モニタ）

2017.3。24で、MicrosoftのAzureのサービスファブリックの公式ブログでは、ファブリック.NET SDKは、オープンソースを行くブログサービスを公開し、コミュニティの最大音量の声サービスファブリックのオープンソースの場合や現在の状況、その後のサービスファブリックを開くを記述する。 NET SDKの一部、コミュニティが正式サービスファブリックを開くことを楽しみにしており、年間の長い待ち時間の後、2018年3月14日には、Microsoftが最終的にはサービスファブリックを開き、MITライセンスの下でオープンソースであり、公式ブログhttps://blogs.msdn.microsoft.com/azureservicefabric/2018/03/14/service-fabric-is-going-open-sourceを発表しました。

MicrosoftがGithubのアドレスにオープンソースに現在ある基本的なテストを実行して、Linuxのサービスファブリックの現在の建物コードhttps://github.com/Microsoft/service-fabricである、あなたは、上記のWindowsをPRの問題を提出し、という問題がありますCIビルド環境だけでなく、完全な環境が移行されていません。Windowsサービスファブリックインテリアは内部サービスのほぼ十年を開発している、そのような私たちは、Microsoftの内部ツールのほぼ十年を持っていることを意味しOffice365、Azureのスタックプラットフォームなど、マイクロソフトのプラットフォーム内のほとんどの時間は、移行する前に移行を完了することができますプロセスの微細化、徐々にすべてのオープンソースは、すべての開発作業の後、オープンソースモデルの下で開発されます。

サービスファブリックの基本概念：ノード、アプリケーション、サービス、パーティション/レプリカ

Azureのサービスファブリックは、ユーザーが簡単にパッケージ化、展開、および信頼性の高いマイクロ管理サービスとスケーラブルなコンテナを容易にすることができ、分散システム・プラットフォームです。開発者や管理者は、単に厳しいミッションクリティカルなワークロード、それらの、スケーラブルで信頼性が高く、管理しやすいワークロードを達成することに焦点を当て、複雑なインフラストラクチャの問題を解決する必要はありません。

このセクションでは、作業のメカニズムAzureのサービスファブリックなどのマイクロサービス、ノードタイプ、ノード、およびなどの関連コンポーネントの基本的な概念を紹介します。名前はAzureのサービスファブリックプラットフォームと呼ばれているが、それはAzureプラットフォーム自体よりもはるかに多くを適用することができますが、我々は、具体的な利用シナリオの以降の章では、主要なサービスファブリックプラットフォームでの作業のすべてのフォームを説明します。

マイクロソフトのAzureサービスファブリックは、高可用性、スケーラブルなクラウドサービスをサポートするフレームワークのMicrosoftの開発で、システムのコアは、スケーラブルで信頼性の高いアプリケーションを構築するための分散型プラットフォームです。パッケージでは、同時にコードを容易に高い複雑、低遅延、データ集約型な状況に対処するためのクラウドプラットフォームを介してそれらを伸ばすために、ステートレスとステートフルマイクロサービスの作成をサポートするために展開することができます。開発者やシステム管理者は、インフラの問題から複雑な、構築されたアプリケーションを達成するために多くの努力を扱うことができます。

マイクロサービスMicroservice

具体的な説明サービスファブリックの前に、マイクロサービスに言及していたと思いました。ため、サービスファブリックの設計と開発プロセスを使用した開発プロセスの微細なサービスです。サービスファブリックを使用すると、あなただけの展開の後に多くの思考スケーラビリティと可用性の問題もなくマイクロサービス機能の開発を検討する必要があり、これらの問題は、あなたが達成するためにサービスファブリックを手渡しすることができます。

思想は、同じ機能は、管理サービスの複数の分解が互いに通信インタフェースとの間で合意することができる場合には、個々のサービスのアプリケーションの複数に切り離さマイクロサービス複合一体です。この方法では達成するために単一の困難を使用して機能をコーディングするためのモジュール式のソリューションを提供します。単一のサービスを開発し、維持するために簡単にすることができるからです。各単一のサービスを開発する専門チームを持つことができるように、このアーキテクチャのアプローチは、各チームは、インターフェースの規則を介して互いに通信するために、自らの技術的な専門知識を開発することを選択できます。各サービスは、テスト、展開、独立して実施し、アップグレードすることができ、開発者は、もはや他のサービス展開のサービスへの影響を心配する必要はありません。ABテストは継続的インテグレーション継続的な展開を実現するために、展開のスピードを加速します。サーバリソースの利用率を最大化するように、全体としてすべてのマイクロサービスは、サービス、リソースのための彼らのニーズに応じて各マイクロサービスとは独立してスケーリングをユーザーに提供します。

戻るサービスファブリック、サービスの数によって開発されたサービスファブリックアプリケーションは、それぞれのサービスは、個人だけでは、スケールのように変更し、管理、および管理するための完全なアプリケーションに従うことができますすることができます。サービスファブリックの設計目標は、複雑なアプリケーションを構築するプロセスを簡素化するためにマイクロサービスを使用することです。

クラスタのクラスタ

クラスタは、自分のマイクロサービスがクラスタにデプロイされたネットワークを介して接続された仮想または物理ホストのグループであり、クラスタサイズはホストの数千に拡張することができます。

ノードノード

集群中的一台机器或者VM称为Node, 每个Node会被分配一个名称（string字符串）。Node还有其他一些属性，比如位置属性placement properties。可以通过每台机器或者VM都有一个自启动Windows系统服务FabricHost.exe，它随系统启动后会执行另外两个程序：Fabric.exe 和 FabricGateway.exe，这两个程序就组成了一个完整的Node。出于测试目的，有时单台机器上也可以通过运行多个Fabric.exe 和 FabricGateway.exe的实例来拥有多个Node。

一个集群中的所有Node相互之间平等且可以直接互相通信。Node除了宿主在物理主机或VM中，还可以宿主在基于Windows的Docker容器中、本地部署的服务器中、其他公有云和私有云中，我们会在后续Service Fabric的使用场景中为大家详细介绍这一内容。

应用程序Application：Application Type和Service Type

Service Fabric应用程序（Application）是一组服务(service)的集合，其中一个service是为Application提供指定功能的单元。您将通过定义一个Application Type和对应的几个Service Type来构建一个Service Fabric的Application. 当Application被部署到Service Fabric Cluster里面时，这些类型会被相应地初始化成application实例和service实例。这里类似我们OO地思想。

Application Type和Named Application: Application Type包含一组Service Type的集合，对应上文中的Service Fabric应用程序（Application）是一组服务(service)的集合。 Application Type的name和version定义在ApplicationManifest.xml文件中。在部署的时候，ApplicationManifest.xml会被拷贝到Service Fabric的image store中。通过在Cluster中创建Named Application来初始化Application的实例。Named Application通过"fabric:/MyNamedApp"的形式来命名。

Service Type和Named Service: Service Type的name和version定义在ServiceManifest.xml文件中。当创建好一个Named Application后，就可以创建Named service. 例如您在 "MyNamedApp" Named Application中创建一个 "MyDatabase" Named Service， Name Service被命名为 "fabric:/MyNamedApp/MyDatabase".

分区Partitions和复制replicas

一个service可以包含多个分区Partition，Service Fabric通过使用分区作为扩展的机制来将工作分布到不同的service实例上。

一个分区Partition可以包含一个或者多个复制replicas。Service Fabric通过使用复制来实现可用性。一个分区可以有一个主复制和多个从复制，多个复制之间的状态可以自动同步。当主复制出现错误时，其中一个从复制被自动提升为主复制，以保证系统的可用性。然后将从复制的个数恢复到正常水平，保证足够的从复制冗余。

使用Visual Studio+Service Fabric运行Spring Boot微服务

Service Fabric是微软提供的微服务管理框架，经过了微软Cosmos DB等多个产品的验证。

Service Fabric官方文档只提供了Visual Studio + .net + C#的开发部署方案和Linux + Eclipse + Java的部署方案，但没有Visual Studio+Eclipse+Java的部署方法，通过摸索和文档，发现微软提供了这样的途径，微软真是比以前开放多了。

1. 首先在Visual Studio中创建Service Fabric工程，

2. 选择来宾可执行文件，输入第一个微服务的名称,选择可执行的jar包所在文件目录，Work Folder选为CodeBase,

3. 在VS项目树中，选择Jar包，同时将java运行环境包复制/粘贴到code目录中，

4. 打开"ServiceManifest.xml"，更改以下参数，

Program: This should point to java.exe file in JRE folder that was copied.
Arguments: This should contain the -jar and path of the JAR filename relative to java.exe. They are arguments passed to java.exe when it starts.
WorkingFolder: This should be CodeBase.
Endpoint: Name a endpoint and provide protocol as HTTP and port no (8080) along with type(input)

5. 点击Start按钮，就可以将此微服务部署搭配本地Service Fabric Cluster上了。

【案例深度讲解】利用Service Fabric承载eShop On Containers

从模块化到微服务化

从Pet Shop 到eShop on Container都是Microsoft在技术演进的路径上给开发者展示.Net的开发能力和架构能力的Sample工程，Petshop的时候更多的是展现应用的分层架构，设计的抽象与模块间的通讯。到了eShop on Container更多的关注在架构设计与微服务化的，下面我们先来看看eshop on Container的架构图

在上图，我们可以看到后端服务分成了

Identity microservice(验证服务)
Catalog microservice（商品分类服务）
Ordering microservice（订单服务）
Basket microservice（购物车服务）
Marketing microservice（市场营销服务）
Locations microservice（地理位置信息服务）

在以前的分层架构中，通常这些服务都是以某一模块来体现的，为什么现在要将他们拆分成了各个服务呢？当我们从业务场景上面来看这些服务时，我们会发现每个服务的访问峰值时间区间、容量规划都是不一样的，甚至实现这些服务最方便最简单的技术栈都有可能是不一样的（当然强大的.net core无所不能，但是公司内不同业务线上的技术储备不一样，就有可能选择不同的技术实现）。这是因为如果我们都将这些模块整合到了一个程序或者服务中的时候，就会碰到在不同时间内服务高峰期扩展系统容量困难，要不就是资源不足，要不就是资源过剩。譬如抢购业务开始前大家提前个半小时登录了系统，这时候系统最忙的是登录模块，到了开始抢购时间，系统最忙的是订单模块。不采用微服务架构的话，半小时前准备给登录模块使用的资源不一定能够及时的释放出来给订单模块。如果两个模块都使用单一程序架构的话，很可能出现的情况就是抢购的业务把所有资源都占满了了，连其他正常访问系统的用户资源都被占用掉，导致系统崩溃。在讲究Dev/Ops的今天，开发人员和架构师需要更多的考虑硬件架构层面对程序应用带来的影响。

用Service Fabric来承载eShop on Container微服务的方法一，通过Service Fabric直接管理Docker

首先我们先到Azure上申请一个Container Registry来承载eShop各个微服务程序的镜像(image).创建Azure Docker Registry可以参考官方文档：https://docs.microsoft.com/zh-cn/azure/container-registry/

现在最新版本Service Fabric已经可以直接管理编排Docker了。

1.创建一个类型为Container的Service

2.在servicemanifest.xml中描述清楚image所在路径

<CodePackage Name="Code" Version="1.0.0">

    <!-- Follow this link for more information about deploying Windows containers to Service Fabric: https://aka.ms/sfguestcontainers -->
    <EntryPoint>
  
      <ContainerHost>
        <ImageName>eshopsample.azurecr.io/catalog:latest</ImageName>       
      </ContainerHost>      
    </EntryPoint>
    <!-- Pass environment variables to your container: -->   
    <EnvironmentVariables>
      <EnvironmentVariable Name="HttpGatewayPort" Value=""/>
    </EnvironmentVariables>
  </CodePackage>

这里非常简单，指定了image所在位置就好了，如果本身Docker Image里需要很多配置信息譬如：数据库链接串、其他服务的地址等等都可以在EnvironmentVariables里面去配置。

3.配置Registry的访问账号密码,需要在ApplicationManifest.xml上面来配置

<ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="CatalogService_Pkg"  ServiceManifestVersion="1.0.1" />      
    <Policies>
      <ContainerHostPolicies CodePackageRef="Code" Isolation="hyperv">
        <RepositoryCredentials AccountName="youraccount" Password="xxxxxxxxxxxxx" PasswordEncrypted="false"/>
        <PortBinding ContainerPort="80" EndpointRef="CatalogServieEndpoint"/>
      
      </ContainerHostPolicies>
    </Policies>
  </ServiceManifestImport>

整个过程不会太复杂，只要配置好了Catalog microserivce的ServiceManifest.xm和ApplicationManifest.xml文件之后，我们可以用同样的方法将其他服务一一配置完成，然后我们就可以将Service Fabric的配置Publish到Cluster上面了。

Service Fabric会自动根据配置在Cluster上面Pull Image和将Docker运行起来。非常简单

用Service Fabric承载eShop on Container微服务的方法二：用Service Fabric的Runtime运行eShop on Container的微服务

Service Fabric本身就是个微服务的开发框架，现在已经直接支持了.net Core 2.0了所以，我们更新了Service Fabric的SDK之后就可以直接创建.net core的服务了

eShop on Container的代码都已经是一份成型的.net core 2.0的代码，所以不需要重新编写服务。

1.通过nuget添加最新的Service Fabric最新的SDK。

2.修改programe.cs,启动ServiceFabric Runtime而不是直接启动Asp.net WebHost

public static void Main(string[] args)
        {

            try
            {
                // ServiceManifest.XML 文件定义一个或多个服务类型名称。
                // 注册服务会将服务类型名称映射到 .NET 类型。
                // 在 Service Fabric 创建此服务类型的实例时，
                // 会在此主机进程中创建类的实例。

                ServiceRuntime.RegisterServiceAsync("Catalog.API",
                    context => new CatalogAPI(context)).GetAwaiter().GetResult();

                ServiceEventSource.Current.ServiceTypeRegistered(Process.GetCurrentProcess().Id, typeof(CatalogAPI).Name);

                // 防止此主机进程终止，以使服务保持运行。 
                Thread.Sleep(Timeout.Infinite);
            }
            catch (Exception e)
            {
                ServiceEventSource.Current.ServiceHostInitializationFailed(e.ToString());
                throw;
            }
}

3.编写

CatalogAPI 类用于启动WebHost

internal sealed class CatalogAPI : StatelessService
    {
        public CatalogAPI(StatelessServiceContext context)
            : base(context)
        { }

        /// <summary>
        /// Optional override to create listeners (like tcp, http) for this service instance.
        /// </summary>
        /// <returns>The collection of listeners.</returns>
        protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
        {
            return new ServiceInstanceListener[]
            {
                new ServiceInstanceListener(serviceContext =>
                    new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
                    {
                        ServiceEventSource.Current.ServiceMessage(serviceContext, $"Starting WebListener on {url}");
                                                return new WebHostBuilder()
                                         .UseKestrel()
                                    .ConfigureServices(
                                        services => services
                                            .AddSingleton<StatelessServiceContext>(serviceContext))
                                    .UseContentRoot(Directory.GetCurrentDirectory())
                                    .ConfigureAppConfiguration((builderContext, config) =>
                                    {
                                        IHostingEnvironment env = builderContext.HostingEnvironment;

                                        config.AddJsonFile("settings.json", optional: false, reloadOnChange: true)
                                            .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);
                                       
                                    })
                                    .UseStartup<Startup>()
                                    .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                                    .UseUrls(url)
                                    .UseWebRoot("Pics")
                                    .Build();                  
                    }))
            };
        }
    }

4.编写serviceManifest.xml描述服务端口等信息

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="Catalog.APIPkg"
                 Version="1.0.3"
                 xmlns="http://schemas.microsoft.com/2011/01/fabric"
                 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ServiceTypes>
        <StatelessServiceType ServiceTypeName="Catalog.API" />
  </ServiceTypes>

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.3">
    <EntryPoint>
      <ExeHost>
        <Program>Catalog.API.exe</Program>
        <WorkingFolder>CodePackage</WorkingFolder>
      </ExeHost>
    </EntryPoint>
    <EnvironmentVariables>
      <EnvironmentVariable Name="ASPNETCORE_ENVIRONMENT" Value="Development"/>
    </EnvironmentVariables>
  </CodePackage>


  <ConfigPackage Name="Config" Version="1.0.1" />

  <Resources>
   
    <Endpoints>   
  
      <Endpoint Protocol="http" Name="ServiceEndpoint"  Type="Input"  Port="5101" />
    </Endpoints>
  </Resources>
</ServiceManifest>

5.修改AppcationManifest.xml增加几个服务的描述信息

添加ServiceImport节

<ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="Catalog.APIPkg" ServiceManifestVersion="1.0.3" />
    <ConfigOverrides />
  </ServiceManifestImport>

在DefaultService中描述Service

<Service Name="Catalog.API" ServiceDnsName="catalog.fabric.api">
      <StatelessService ServiceTypeName="Catalog.API" InstanceCount="[Catalog.API_InstanceCount]">
        <SingletonPartition />
      </StatelessService>
    </Service>

这样我们就可以将Catalog这个服务改造成可以通过Service Fabric来管理的微服务了。通过Publish，我们可看到几个服务都已经在Service Fabric下面接受管理和编排了。

访问localhost:5100

学习Azure Service Fabric的总结：

Azure Service Fabric其实分为两块：Azure和Service Fabric。
Service Fabric只是一套软件分布式系统，理论上它可以使用在非Azure环境。也就是说：非Azure环境的机器集群，进行合理配置，也可以使用Service Fabric 构建分布式系统。
当我们在Azure门户上创建Azure Service Fabric时，会自动创建Azure Load Balancer, Azure Virtual Machine Scale Set, Azure Virtual Machine。这是因为这些组件都是在Azure环境中将Service Fabric接入公网必须的组件和平台。但是理论上如果今后有其他的产品，通过合理的负载均衡和配置逻辑，只要可以让服务器集群面向外部网络提供服务，Service Fabric都可以适用。
Service Fabric自行构建了一整套虚拟概念，包括后面会提及的Micro Service, Node type, Node等等。这些概念都是仅在Service Fabric范围内适用。例如Micro Service，可以用C#构建，也可以用Java实现。Node type可以是Azure VMSS, 也可是是硬件物理服务器。
Service Fabric帮助架构师将分布式系统和硬件进行脱耦。理想程度下，所有职责如下：
- 软件开发者只需要关系分布式微服务功能逻辑实现，微服务之间如何调用通过统一接口完成
- 应用部署者只需要关心如何将微服务部署至各个node，以及考虑应用的升级维护
- 硬件架构师只需要关心维护虚拟机和网络之间的部署关系，并且在虚拟机性能产生问题是增加虚拟机来分担压力

【参考资料】

1、大话微服务架构之微服务框架微软ServiceFabric正式开源（三） http://baijiahao.baidu.com/s?id=1595179278058800506

2、Service Fabric https://azure.microsoft.com/zh-cn/documentation/learning-paths/service-fabric/

3、DevOps 工具集成 | Microsoft Azure https://azure.microsoft.com/zh-cn/products/devops-tool-integrations/

4、【图文】微服务架构设计_https://wenku.baidu.com/view/eb6467d10408763231126edb6f1aff00bed570a3.html

5、微服务架构与实践摘要-电子发烧友网触屏版 http://m.elecfans.com/article/631884.html

6、微服务架构设计 - PetterLiu - 博客园 https://www.cnblogs.com/wintersun/p/6219259.html

7、微服务实践：从单体式架构迁移到微服务架构 https://blog.csdn.net/gaowenhui2008/article/details/70239716

8、微服务架构 - 老_张 - 博客园 https://www.cnblogs.com/imyalost/p/6792724.html

本文转自：https://blog.csdn.net/enweitech/article/details/80696225

ターン：マイクロソフトサービスファブリックマイクロサービスフレームワーク

サービスファブリックの基本概念：ノード、アプリケーション、サービス、パーティション/レプリカ

使用Visual Studio+Service Fabric运行Spring Boot微服务

从模块化到微服务化

用Service Fabric来承载eShop on Container微服务的方法一，通过Service Fabric直接管理Docker

用Service Fabric承载eShop on Container微服务的方法二：用Service Fabric的Runtime运行eShop on Container的微服务

おすすめ