从模块化到微服务化
从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>