上一篇我们说了Identity Service，因为其基于IdentityServer4开发的，所以知识点不是很多，今天我们来看下Catalog Service，今后的讲解都会把不同的、重点的拿出来讲，希望大家明白。

源码分析

我们先看下它的目录结构，很标准的webapi目录：

首先看下Program，跟IdentityService类似，多了一个UseWebRoot(“Pics”)，把pics这个目录设置成了webroot，其他都一样。

在Startup的构造方法中，我们也看到了使用了secret manager tool，但是多了一个参数，在这里我们看到的是Assembly类型，其实secret只需要其中的userSecretsId而已。

在ConfigureServices中，我们看到如下代码：

services.AddMvc(options =>
{   options.Filters.Add(typeof(HttpGlobalExceptionFilter));
}).AddControllersAsServices();

添加了一个filter，这个HTtpGlobalExceptionFilter可以在项目中找到，大概的意思就是遇到抛出CatalogDomainException类型的错误时，返回特定的错误码。

AddControllersAsServices这个扩展方法是把项目中的Controller都注册到Services中，我们看下源码：

 public static IMvcCoreBuilder AddControllersAsServices( this IMvcCoreBuilder builder){       var feature = new ControllerFeature();builder.PartManager.PopulateFeature(feature);            foreach (var controller in feature.Controllers.Select(c => c.AsType())){builder.Services.TryAddTransient(controller,  controller);}builder.Services.Replace(ServiceDescriptor.Transient<IControllerActivator, ServiceBasedControllerActivator>());            return builder;
}

中间那段foreach就是，这样我们在项目中通过依赖注入方式都能方便的访问到各个controller了。

Going down:

  services.AddDbContext<CatalogContext>(options =>{options.UseSqlServer(Configuration["ConnectionString"],sqlServerOptionsAction: sqlOptions =>{sqlOptions.MigrationsAssembly(typeof(Startup).GetTypeInfo().Assembly.GetName().Name);                                         //Configuring Connection Resiliency: https://docs.microsoft.com/en-us/ef/core/miscellaneous/connection-resiliency sqlOptions.EnableRetryOnFailure(maxRetryCount: 5, maxRetryDelay: TimeSpan.FromSeconds(30), errorNumbersToAdd: null);});                     // Changing default behavior when client evaluation occurs to throw. // Default in EF Core would be to log a warning when client evaluation is performed.            options.ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning));                //Check Client vs. Server evaluation: https://docs.microsoft.com/en-us/ef/core/querying/client-eval});

对DBContext的配置的时候，这里使用了Connection Resiliency（弹回连接）的方式，其中可以看到使用migration的时候，它使用了MigrationsAssembly(AssemblyName)，这种方式跟我之前讲的FluentNhibernate有点类似,EnableRetryOnFailure设置了这个Action的失败尝试机制，如果Migration的时候遇到Failure，就会自动重试，这种方式避免了app与database分离造成的连接偶尔失败造成的影响。为什么会有这个机制呢？因为当我们的database在云端的时候，比如Azure SQL，不可避免的会出现网络连接问题，即使我们把app和database放在一个数据中心中，我相信偶尔也会有这个问题，我们现在可以通过配置，使其如果遇到失败就会重新操作，一定程度避免了网络偶尔造成的问题。你也可以设置一些策略，使其能够在运行命令的时候能够进行重试EF默认情况下只是记录client evaluation中的warns，我们可以通过ConfigureWarnings使其抛出这个警告，你也可以配置成忽略。

接下来我们看到如下代码：

services.Configure<CatalogSettings>(Configuration);

我们可以在eShop的各个项目中都能找到类似的语句，它会把一些项目相关的Settings注册到services中，使其成为环境变量，我们可通过setting.json进行配置。除了通过setting.json进行配置，我们还能通过Docker run –e 进行灵活化配置。

在这里我们的CatalogSetting含有一个ExternalCatalogBaseUrl属性，我们在docker run的时候可以输入如下命令：

docke run -e "ExternalCatalogBaseUrl=http://localhost:5011/" ....

这样就能灵活的通过docker命令进行配置了，非常方便，我们也可以通过-e对我们setting.json中的变量进行赋值，比如ConnectionString,你可以通过点击了解更多相关内容。

            // Add framework services.services.AddSwaggerGen();services.ConfigureSwaggerGen(options =>{options.DescribeAllEnumsAsStrings();options.SingleApiVersion(new Swashbuckle.Swagger.Model.Info(){Title = "eShopOnContainers - Catalog HTTP API",Version = "v1",Description = "The Catalog Microservice HTTP API. This is a Data-Driven/CRUD microservice sample",TermsOfService = "Terms Of Service"});});services.AddCors(options =>{options.AddPolicy("CorsPolicy",builder => builder.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader().AllowCredentials());});

上面两段代码，分别配置了SwaggerGen和Cors（跨域）策略，SwaggenGen是一个非常实用的框架，它能自动把我们的api转为web方式呈现在我们眼前，还能进行调试，非常好用。Cors的配置这里用的不好，它允许了所有请求，建议还是按照实际需求来吧，否则没有跨域设置的意义了。

接下来我们看到了一系列的add service的操作，都是关于EventBus的，稍微看了下，发现目前只做了log的动作，我们看下代码：

if (raiseProductPriceChangedEvent) // Save and publish integration event if price has changed{    //Create Integration Event to be published through the Event Busvar priceChangedEvent = new ProductPriceChangedIntegrationEvent(catalogItem.Id, productToUpdate.Price, oldPrice);    // Achieving atomicity between original Catalog database operation and the IntegrationEventLog thanks to a local transactionawait _catalogIntegrationEventService.SaveEventAndCatalogContextChangesAsync(priceChangedEvent);    // Publish through the Event Bus and mark the saved event as publishedawait _catalogIntegrationEventService.PublishThroughEventBusAsync(priceChangedEvent);
}

上面的代码意思是在价格有变动的时候，我们就调用EventService进行保存，同时对操作进行了记录。PublishThroughEventBusAsync方法则对这条记录的State更改为published。目前来说我不太清楚为何要用这种方式，也不知道为何取名为EventBus，不过我在项目的issue中已经提出了这个问题，希望项目的开发者们能给我一个答案。我有查看了Basket.Api，在这个项目中会有订阅行为，具体的等到下一章我们再仔细看看。

ok，我们再看下Configure方法，下面一段代码我们可以学习下：

var context = (CatalogContext)app.ApplicationServices.GetService(typeof(CatalogContext));WaitForSqlAvailability(context, loggerFactory);

我们看到在这里它调用了之前注册的CatalogContext，它并没有通过new进行实例化，而是通过GetService的方式获取之前的注册，这样context所依赖的其他实例也一并带进来了，非常方便好用。

WaitForSqlAvailability方法是对数据库可用进行尝试，因为后面它需要进行数据迁移。

CatalogService包含了2个Controller，一个是PicController，一个是CatalogController，PicController仅仅是根据ID获取了图片，CatalogController展示了用webapi如何做CURD。

运行部署

如果你要运行Catalog.Api，你必须安装MSSQL和RabbitMQ，这次我把我的系统换成了Win10 Pro，并在电脑上使用Docker安装了MSSQL-Server-Linux和RabbitMQ。安装这2个非常简单，仅仅需要输入几条命令即可：

docker run --name mssql -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=Pass@word' -p 5433:1433 -d microsoft/mssql-server-linuxdocker run -d --hostname my-rabbit --name rabbitmq -p 8080:15672 -p 5672:5672 rabbitmq:3-management

ok，我们使用docker创建了mssql和rabbitmq，这里注意一下，我把mssql的端口映射到了本机的5433上，还有rabbitmq的管理页面，我映射到了本机的8080端口，你可以通过http://localhost:8080 进行访问。

上一篇我们说过我们可以通过iisexpress/Kestrel或者docker的形式运行因为牵涉到配置，所以这两种方式的运行有些不同。

一、iisExpress或Kestrel方式下，因为刚刚我们把mssql和rabbitmq的端口都映射到了本机，所以我们只需要在setting.json中把数据库连接和rabbitmq的地址指向本机即可，如下：

{  "ConnectionString": "Server=tcp:127.0.0.1,5433;Initial Catalog=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=Pass@word",  "ExternalCatalogBaseUrl": "http://localhost:5101",  "EventBusConnection": "localhost",  "Logging": {    "IncludeScopes": false,    "LogLevel": {      "Default": "Debug",      "System": "Information",      "Microsoft": "Information"}}
}

ok，Ctrl+F5，运行一下看看：

当看到上面这个页面，说明你的运行正常了，你还得测试下api是否运行正常，比如Pic，比如Items。

二、docker中运行，参照上一篇的方式，先publish再build image，不过这里要注意一点，因为你之前的ConnectionString和EventBusConnection都是指向本机（127.0.0.1）的，所以这里必须改一下，改成主机的ip地址或者是对应容器的ip也可以，如果您不想更改的话，也可以通过docker -e进行设置，比如：

docker run -p 8899:80 --name catalog -e "EventBusConnection=172.17.0.2" -d catalog:01

我这里的172.17.0.2是我rabbitmq容器的ip地址，你可以通过docker inspect containerId 进行查看容器的ip。

如果一切配置都正确的话，你就可以通过浏览器http://localhost:8899 进行浏览了。

当然，除了正常浏览外，你还需测试下api是否正常。

困惑

在这个项目中有一些疑惑，希望大家能够给我答案。

Connection Resiliency，我看了很久，字面意思是弹性连接，但我觉得用弹性好像不太适合，一般来讲我们说的弹性都是指架构或者系统的伸缩性，我一开始也是从这个角度去了解，但看了很多文章，觉得它只是让我们在启动的时候，设置一些重试策略，在后面调用中可使用此策略，策略会根据你设置的重试次数、延迟时间等去自动重试，避免因为偶尔的错误造成的影响，所以觉得用弹回比较恰当。

EventBus，我感觉很奇怪，为什么一定要取这个名字呢？在Android中，很明确的，它是进行订阅发布，消息传递，可以解耦发布者和订阅者，但在Catalog.Api里，变成了记录操作，没有看到解耦，也没有看到订阅。在我的理解中，应该在Startup进行订阅操作，发布者CatalogController在进行update操作的时候，订阅者进行add log动作，但在这个实例中，我看到的是同步进行了这些操作，所以很不解。

Mssql-server-linux，当你用Docker安装了以后，你却不能使用visual studio 2017的sql server data tools进行查询（只能进行连接），为了查看效果，还需要安装Microsoft Sql Server Management Studio（必须17版本以后）进行查看数据。

写在最后

这次的文章来的比较晚，一方面有点忙，另一方面就是上面提到的困惑，面对困惑我试着去解答，但有时候真的无法解答，所以提出来集思广益。

后面可能会比较慢，需要学习的东西真多，一边写一边学习成为这次系列的乐趣，现在每天坚持6公里快走，夜走能够是我保持头脑清晰，思考项目中的疑问，现在发觉生活越发有趣。

或许有很多人觉得只看了Startup就够了吗？其实真不够，我目前先把框架的源码过一遍，后面会分篇讲述，比如Connection Resiliency。

最后应大家要求，我建了一个QQ群：376248054，大家可以进来一起探讨，一起学习！

事件总线（Event Bus）知多少
Identity Service - 解析微软微服务架构eShopOnContainers（二）
开篇有益-解析微软微服务架构eShopOnContainers（一）

原文地址：http://www.cnblogs.com/inday/p/catalog-service-eshopOnContainers.html

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注

Catalog Service - 解析微软微服务架构eShopOnContainers（三）相关推荐

Identity Service - 解析微软微服务架构eShopOnContainers（二）
接上一篇,众所周知一个网站的用户登录是非常重要,一站式的登录(SSO)也成了大家讨论的热点.微软在这个Demo中,把登录单独拉了出来,形成了一个Service,用户的注册.登录.找回密码等都在其中进行 ...
EventBus In eShop -- 解析微软微服务架构eShopOnContainers（四）
引言大家好像对分析源码厌倦了,说实在我也会厌倦,不过不看是无法分析其后面的东西,从易到难是一个必要的过程. 今天说下EventBus,前几天园里的大神已经把其解刨事件总线(Event Bus)知多少 ...
开篇有益-解析微软微服务架构eShopOnContainers（一）
为了推广.Net Core,微软为我们提供了一个开源Demo-eShopOnContainers,这是一个使用Net Core框架开发的,跨平台(几乎涵盖了所有平台,windows.mac.linux ...
Health Check in eShop -- 解析微软微服务架构Demo（五）
引言 What is the Health Check Health Check(健康状态检查)不仅是对自己应用程序内部检测各个项目之间的健康状态(各项目的运行情况.项目之间的连接情况等),还包括了应 ...
微服务架构基础(三)
微服务架构基础(三) 持续更新- 继续前面的基础二工程进行扩展服务降级.服务熔断和服务限流基本概念理解服务雪崩多个服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又 ...
Service Discovery 与微服务架构有什么关系？
一.应用层在简单的 3 层结构中,Web 服务层既要处理请求,又要承载业务功能: 而更优的结构是把 Web 层与应用层(也叫平台层)分开: 优势在于: 能够单独扩展应用层:允许独立加机器.换专用机器 ...
深入研究微服务架构——第三部分
目录介绍背景什么是NancyFx? 什么是领域专用语言? 托管Nancy NancyFx与ASP.Net Core Web API NancyFx Hello World 使用代码为自主机配置 ...
基于微服务架构、运行于容器中的.NET Core示例应用eShopOnContainers
eShopOnContainers 是 <.NET Microservices – Architecture for Containerized .NET Applications>这本微 ...
阿里巴巴资深架构师深度解析微服务架构设计之SpringCloud+Dubbo
微服务软件架构是一个包含各种组织的系统组织,这些组件包括Web服务器,应用服务器,数据库,存储,通讯层),它们彼此或和环境存在关系.系统架构的目标是解决利益相关者的关注点. 编辑切换为居中添加 ...

Catalog Service - 解析微软微服务架构eShopOnContainers（三）

源码分析

运行部署

困惑

写在最后

Catalog Service - 解析微软微服务架构eShopOnContainers（三）相关推荐

最新文章

热门文章