有关Hosting的基础知识

Hosting是一个非常重要,但又很难翻译成中文的概念。翻译成:寄宿,大概能勉强地传达它的意思。我们知道,有一些病毒离开了活体之后就会死亡,我们把那些活体称为病毒的宿主。把这种概念应用到托管程序上来,CLR不能单独存在,它必须依赖于某一个进程,我们把这种状况称之为:CLR必须寄宿于某一个进程中,而那个进程就是宿主。

ASP.NET Core的一个大的改变就是就是将Web应用程序改成了自寄宿。什么意思呢?我们知道,在之前的ASP.NET版本中,ASP.NET的Web应用程序都是深度依赖IIS和Windows Server,以至于ASP.NET只能在Windows Server上运行。之所以出现这种情况,就是应为我们开发的所有Web应用程序都是寄宿在IIS进程中的。一般来说,一个进程只能加载一个CLR(不同进程之间可以加载不同的版本的CLR),为了托管多个Web应用程序,IIS使用了应用程序池这种东西来模拟进程的行为,从而为不同的Web程序加载不同的运行时来托管它们。

有关CLR和寄宿的知识,如果有兴趣,可以参阅《CLR via C#》。

我们可以查看一下以前版本的ASP.NET程序,它是没有Main()函数的,也就是说它没有程序入口点,不是单独的进程。对于应用程序开发来说,这个问题并不大,因为开发者在意的Web程序的逻辑、数据安全等问题,而不是应用程序如何被加载。但对于一个Web框架来说,这个问题非常严重,因为它高度依赖IIS和Windows Server,减少了它的适用范围。如果我们查看ASP.NET Core的程序,你会发现它本质上就是一个控制台程序,如果我们把那些在Main()函数中自动生成的代码都删掉(VS2015的模板会自带一些代码),加上Console.WriteLine("Hello World!"); 它就会在控制台中打出Hello World!由于ASP.NET Core的程序自身有程序入口点,所以自身就是一个进程,它可以为自己加载合适的CLR来运行Web应用,这种情况就是自寄宿。这么做的最大的好处就是可以脱离IIS,从而脱离Windows Server的桎梏。只要对应操作系统上有符合CLR规范的运行时,那ASP.NET Core的应用就可以部署在那个操作系统上。.NET Core里包含了微软开发的跨平台CLR运行时,可以运行在Windows,Linux和OSX上,借助它ASP.NET Core的应用程序就可以部署在这些操作系统上。

说到这里,就只能下最后一个问题,IIS还扮演什么角色?当应用部署在Windows上时,微软推荐将IIS通过ASP.NET Core Module(之前的HttpPlatformHandler)模块作为Web应用的反向代理服务器(reverse-proxy server)。这个服务器的作用就是将请求转发到Web应用真正的服务器:

  • WebListener (只能在Windows平台)
  • Kestrel         (跨平台服务器,比WebListener功能稍弱)

服务器的问题会在下一篇文章中说明。前面上了那么多开胃菜,终于可以上正菜了。以下出现的所有源码都可以在Microsoft.AspNetCore.Hosting项目中找到。

Main函数里发生了什么

如果新建一个ASP.NET Core应用,那么最先和我们打交道的就是Main函数中的WebHostBuilder,我们先来看看它的源码:

     //所有方法删除了错误处理,只保留主逻辑
public class WebHostBuilder : IWebHostBuilder
{
private readonly IHostingEnvironment _hostingEnvironment;
private readonly List<Action<IServiceCollection>> _configureServicesDelegates;
private readonly List<Action<ILoggerFactory>> _configureLoggingDelegates; private IConfiguration _config = new ConfigurationBuilder().AddInMemoryCollection().Build();
private ILoggerFactory _loggerFactory;
private WebHostOptions _options; //_config里面存储的是每个应用都有的东西,比如根目录,StartUp类的程序集公钥等。
public IWebHostBuilder UseSetting(string key, string value)
{
_config[key] = value;
return this;
}
public IWebHostBuilder ConfigureServices(Action<IServiceCollection> configureServices)
{
_configureServicesDelegates.Add(configureServices);
return this;
}
public IWebHost Build()
{
var hostingServices = BuildHostingServices();//在字段中,服务是以委托的形式存在,这个方法将配置的服务放入ServiceCollection,同时加入很多其他服务。
var hostingContainer = hostingServices.BuildServiceProvider(); var host = new WebHost(hostingServices, hostingContainer, _options, _config);//构造一个WebHost host.Initialize();//这个方法很重要,后面讲 return host;
}
//在这个方法中,_options会根据_config字段生成,StartUp类会以IStartUp->StartUp的形式注册到依赖注入容器中,即使StartUp不实现接口
//注意这个方法只在Build()方法中被调用,所以UseStartUp()方法应该在Build()方法之前被调用
private IServiceCollection BuildHostingServices(){...}

在每个ASP.NET Core程序的Main函数里面,都有很多UseXXX()的扩展方法,这些方法最终会调用WebHostBuilder.UseSetting()或者ConfigureService()方法。这两个东西的区别在于,_config里面存的东西是每个Web程序都有的部分,比如应用的根目录,StartUp类的程序集信息等等;而Service是Web应用的可选部分,比如UseKestrel()最终调用的是ConfigureServices,因为服务器并不是必须的,可以开发符合Owin规范的程序使应用部分和服务器部分分开来。还有一个区别在于_config中的内容比较简单,比如存储的应用根目录这些东西不必以服务的形式存在,当然有关StartUp的信息还是会以服务的形式注册到依赖注入容器。

WebHostBuilder的这些信息最终会传给WebHost,注意构造WebHost之后,还调用了它的Initialize()方法。我们来看看WebHost类的源码。

     public class WebHost : IWebHost
{
private readonly IServiceCollection _applicationServiceCollection;//UseStartUp等服务
private IStartup _startup;//StartUp private readonly IServiceProvider _hostingServiceProvider;//上面那个服务集合生成的Provider
private readonly ApplicationLifetime _applicationLifetime;//为了异步能取消
private readonly WebHostOptions _options;
private readonly IConfiguration _config; private IServiceProvider _applicationServices; //StartUp ConfigureService方法生成的服务+原本applicationService
private RequestDelegate _application;
private IServer Server { get; set; } //服务器字段,包含了处理的请求的信息
//下面是相关方法
public void Initialize()//转发给BuildApplication()方法
{
if (_application == null)
{
_application = BuildApplication();
}
}
private void EnsureApplicationServices()//把在StartUp.ConfigureServices()方法中注册的服务加到集合中
{
if (_applicationServices == null)
{
EnsureStartup();
_applicationServices = _startup.ConfigureServices(_applicationServiceCollection);
}
}
private void EnsureStartup()//构造StartUp服务类
{
_startup = _hostingServiceProvider.GetRequiredService<IStartup>();
} //构造委托链_application ,ApplicationService存储现在注册的服务
private RequestDelegate BuildApplication()
{
try
{
EnsureApplicationServices();
EnsureServer(); var builderFactory = _applicationServices.GetRequiredService<IApplicationBuilderFactory>();
var builder = builderFactory.CreateBuilder(Server.Features);
builder.ApplicationServices = _applicationServices; var startupFilters = _applicationServices.GetService<IEnumerable<IStartupFilter>>();
Action<IApplicationBuilder> configure = _startup.Configure;
foreach (var filter in startupFilters.Reverse())
{
configure = filter.Configure(configure);//委托链
} configure(builder); return builder.Build();//Use方法最终都会ApplicationBuilder.Use()方法,以Fun<RequestDelegate, RequestDelegate>的形式存在List中
//Build的时候利用上面的List,会生成一个委托链。
//在每一个RequestDelegate中,会用反射生成对应的Middleware类,然后调用Invoke()方法
}
catch (Exception ex) when (_options.CaptureStartupErrors)
{//省略出错的处理,返回HTTP500状态码}
}

直接看BuildApplication()方法,

  1. 调用EnsureApplicationServices()方法,实际上就是调用StartUp.ConfigureServices()这个方法,这个方法大家肯定很熟,就是把那些在ConfigureServices()注册的服务放到_applicationServices字段里;
  2. 调用EnsureServer()方法,确保Server存在,并监听正确的端口,默认是 http://localhost:5000 ,这个方法这里没有列出。
  3. 构造一个ApplicationBuilder,并把注册的服务转移给它;
  4. 用StartUp.Configure以及StartUpFilters.Configure构造一个服务委托链;
  5. 引发服务委托链,相当于调用里面的UseXXX()方法,注意看我注释的解释,此时所有服务都以使用顺序、以Func<RequestDelegate, RequestDelegate>形式存储在一个ApplicationBuilder的List字段中;
  6. Invoke List字段中的所有对象,生成一个委托链,就是我们所说的请求管道(Pipeline)。

请求管道已经生成完毕,剩下的就是请HttpContext进入这个管道了,我们看看WebHost.Run()发生了什么

Host.Run()方法中发生了什么?

Host.Run()内部会调用Host.Start()方法,然后再在控制台输出一些信息,并且传入一个CancellationToken 允许随时中断程序。那么看来得去瞧瞧Host.Start()方法了。

         public virtual void Start()
{
//省略一些参数构造,以及有关logger的代码
Server.Start(new HostingApplication(_application, _logger, diagnosticSource, httpContextFactory)); //只有这句是关键
}

它调用了Server.Start()方法,从方法名上大概能猜出来是干嘛,具体细节留在有关Server的文章里面讲。去看看HostingApplication这个类:

     public class HostingApplication : IHttpApplication<HostingApplication.Context>
{
private readonly RequestDelegate _application;
private readonly ILogger _logger;
private readonly DiagnosticSource _diagnosticSource;
private readonly IHttpContextFactory _httpContextFactory; public Context CreateContext(IFeatureCollection contextFeatures){...}//创建一个上下文 public void DisposeContext(Context context, Exception exception){...} public Task ProcessRequestAsync(Context context)
{
return _application(context.HttpContext);
} public struct Context
{
public HttpContext HttpContext { get; set; }
public IDisposable Scope { get; set; }
public long StartTimestamp { get; set; }
}

显然它的作用就是配合Server去创建上下文,大概的过程就是

  1. 服务器把请求的信息放入一个IFeatureCollection的变量里面;
  2. 利用上面的信息构造上下文;
  3. 调用ProcessRequestAsync()方法处理请求,此时请求进入处理管道(Pipeline)。

总结

  1. 首先使用WebHostBuildler注册基本信息,比如用哪个服务器?根目录是哪个?StartUp的元数据等等;
  2. 在WebHost = WebHostBuildler.Build()过程中,添加大量基本服务+StartUp.ConfigureServices()方法中的服务;
  3. 在WebHost.Initialize()方法中,利用StartUp.Configure()方法中使用的服务+一些默认使用的服务组建请求管道,并存储在_application字段中;
  4. 使用_application构造一个HostingApplication,并传入WebHost.Run()->WebHost.Start()->Server.Start()方法;
  5. Server使用HostingApplication来构造HttpContext,并使用请求管线(Pipeline)处理它。

ASP.NET Core 源码阅读笔记(3) ---Microsoft.AspNetCore.Hosting的更多相关文章

  1. ASP.NET Core 源码阅读笔记(5) ---Microsoft.AspNetCore.Routing路由

    这篇随笔讲讲路由功能,主要内容在项目Microsoft.AspNetCore.Routing中,可以在GitHub上找到,Routing项目地址. 路由功能是大家都很熟悉的功能,使用起来也十分简单,从 ...

  2. ASP.NET Core 源码阅读笔记(1) ---Microsoft.Extensions.DependencyInjection

    这篇随笔主要记录一下ASP.NET Core团队实现默认的依赖注入容器的过程,我的理解可能并不是正确的. DependencyInjection这个项目不大,但却是整个ASP.NET Core的基础, ...

  3. ASP.NET Core 源码阅读笔记(2) ---Microsoft.Extensions.DependencyInjection生命周期管理

    在上一篇文章中我们主要分析了ASP.NET Core默认依赖注入容器的存储和解析,这一篇文章主要补充一下上一篇文章忽略的一些细节:有关服务回收的问题,即服务的生命周期问题.有关源码可以去GitHub上 ...

  4. ASP.NET Core源码学习(一)Hosting

    ASP.NET Core源码的学习,我们从Hosting开始, Hosting的GitHub地址为:https://github.com/aspnet/Hosting.git 朋友们可以从以上链接克隆 ...

  5. CI框架源码阅读笔记5 基准测试 BenchMark.php

    上一篇博客(CI框架源码阅读笔记4 引导文件CodeIgniter.php)中,我们已经看到:CI中核心流程的核心功能都是由不同的组件来完成的.这些组件类似于一个一个单独的模块,不同的模块完成不同的功 ...

  6. CI框架源码阅读笔记4 引导文件CodeIgniter.php

    到了这里,终于进入CI框架的核心了.既然是“引导”文件,那么就是对用户的请求.参数等做相应的导向,让用户请求和数据流按照正确的线路各就各位.例如,用户的请求url: http://you.host.c ...

  7. CI框架源码阅读笔记3 全局函数Common.php

    从本篇开始,将深入CI框架的内部,一步步去探索这个框架的实现.结构和设计. Common.php文件定义了一系列的全局函数(一般来说,全局函数具有最高的加载优先权,因此大多数的框架中BootStrap ...

  8. CI框架源码阅读笔记2 一切的入口 index.php

    上一节(CI框架源码阅读笔记1 - 环境准备.基本术语和框架流程)中,我们提到了CI框架的基本流程,这里再次贴出流程图,以备参考: 作为CI框架的入口文件,源码阅读,自然由此开始.在源码阅读的过程中, ...

  9. Three.js源码阅读笔记-5

    Core::Ray 该类用来表示空间中的“射线”,主要用来进行碰撞检测. THREE.Ray = function ( origin, direction ) { this.origin = ( or ...

随机推荐

  1. 第五百七十八、九天 how can I 坚持

    这样下去不行啊 ,昨天晚上回来捣鼓了一晚上手机,看个视频还经常开小差,得全力以赴了,不能抱着打酱油的心态了,加油. 今天和yj聊了聊,好多事啊,不能一心工作了,还得考虑结婚,也是醉了. 努力吧,先把考 ...

  2. Egret和Http请求 (Ajax、XMLHttpRequest、Post、Get)

    一  Http请求 二  AJax和XMLHttpRequest 三  一个Ajax例子 四 Egret中的egret.HttpRequest 五 Post和Get区别 一 Http请求 Http深入 ...

  3. Eclipse下修改工程名

    汇总下网上的方法. 一. 右键工程:Refactor->Rename,或选中工程按F2,修改名称 二. 右键工程:Properties->Web Project Settings,修改Co ...

  4. linux C学习笔记01--makefile

    不知不觉毕业五年了,以前学的linux基本都忘了,重新温习起来吧! 下面是自己写的makefile文件,供新手和自己回头时查阅 CC=gcc EXE=c.out CCC=g++ EEE=cc.out ...

  5. memcpy code

    memcpy #include <stddef.h> //#include <stdint.h> //uintptr_t is quoted.#include "st ...

  6. Ruby-调用windows窗体

    发现SharpDevelop 也支持Ruby ,特别是可以直接把winform的控件直接用在 require "mscorlib" require "System.Win ...

  7. Google上的Cookie Matching

    Cookie Matching This guide explains how the Cookie Matching Service enables you to make more effecti ...

  8. nginx反向代理编译异常

    cc1: warnings being treated as errors /root/nginx_tcp_proxy_module/ngx_tcp.c: 在函数‘ngx_tcp_add_addrs’ ...

  9. SQL Server Profiler使用方法

    一.SQL Server Profiler使用方法 1.单击开始--程序--Microsoft SQL Server 2005--性能工具--SQL Server Profiler,如下图:   2. ...

  10. R语言--数据预处理

    一.日期时间.字符串的处理 日期 Date: 日期类,年与日 POSIXct: 日期时间类,精确到秒,用数字表示 POSIXlt: 日期时间类,精确到秒,用列表表示 Sys.date(), date( ...