从Pet Shop 到eShop on Container都是Microsoft在技术演进的路径上给开发者展现.Net的开发能力和架构能力的Sample工程,Petshop的时候更多的是展示应用的分层架构,设计的抽象与模块间的通信。到了eShop on Container更多的关注在架构设计与微服务化的,下面咱们先来看看eshop on Container的架构图git
在上图,咱们能够看到后端服务分红了github
在之前的分层架构中,一般这些服务都是以某一模块来体现的,为何如今要将他们拆分红了各个服务呢?当咱们从业务场景上面来看这些服务时,咱们会发现每一个服务的访问峰值时间区间、容量规划都是不同的,甚至实现这些服务最方便最简单的技术栈都有多是不同的(固然强大的.net core无所不能,可是公司内不一样业务线上的技术储备不同,就有可能选择不一样的技术实现)。这是由于若是咱们都将这些模块整合到了一个程序或者服务中的时候,就会碰到在不一样时间内服务高峰期扩展系统容量困难,要不就是资源不足,要不就是资源过剩。譬如抢购业务开始前你们提早个半小时登陆了系统,这时候系统最忙的是登陆模块,到了开始抢购时间,系统最忙的是订单模块。不采用微服务架构的话,半小时前准备给登陆模块使用的资源不必定可以及时的释放出来给订单模块。若是两个模块都使用单一程序架构的话,极可能出现的状况就是抢购的业务把全部资源都占满了了,连其余正常访问系统的用户资源都被占用掉,致使系统崩溃。在讲究Dev/Ops的今天,开发人员和架构师须要更多的考虑硬件架构层面对程序应用带来的影响。数据库
首先咱们先到Azure上申请一个Container Registry来承载eShop各个微服务程序的镜像(image).建立Azure Docker Registry能够参考官方文档:https://docs.microsoft.com/zh-cn/azure/container-registry/json
如今最新版本Service Fabric已经能够直接管理编排Docker了。后端
1.建立一个类型为Container的Serviceapi
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里面去配置。app
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上面了。less
Service Fabric会自动根据配置在Cluster上面Pull Image和将Docker运行起来。很是简单
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; } }
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