这篇文章主要讲解了“怎么利用Service Fabric承载eShop On Containers”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么利用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的今天，开发人员和架构师需要更多的考虑硬件架构层面对程序应用带来的影响。
首先我们先到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所在路径
这里非常简单，指定了image所在位置就好了，如果本身Docker Image里需要很多配置信息譬如：数据库链接串、其他服务的地址等等都可以在EnvironmentVariables里面去配置。
3.配置Registry的访问账号密码,需要在ApplicationManifest.xml上面来配置
整个过程不会太复杂，只要配置好了Catalog microserivce的ServiceManifest.xm和ApplicationManifest.xml文件之后，我们可以用同样的方法将其他服务一一配置完成，然后我们就可以将Service Fabric的配置Publish到Cluster上面了。
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;
}
}
3.编写
CatalogAPI 类用于启动WebHost
internal sealed class CatalogAPI : StatelessService
{
public CatalogAPI(StatelessServiceContext context)
: base(context)
{ }
///
/// Optional override to create listeners (like tcp, http) for this service instance.
///
///
protected override IEnumerable
{
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
.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
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
.UseUrls(url)
.UseWebRoot("Pics")
.Build();
}))
};
}
}
4.编写serviceManifest.xml描述服务端口等信息
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">
5.修改AppcationManifest.xml增加几个服务的描述信息
添加ServiceImport节
