有关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. weed-fs参数列表

    weed-fs没有详细的帮助文档,为了方便阅读,特意把有用的参数帮助罗列出来.未列出的两个命令为version(版本查询) 及shell(这个命令在0.45版本只有回显功能)nerc@Ubuntu:~ ...

  2. notepad++如何设置自动换行

    视图(View)——>自动换行(Word wrap)

  3. webform注册和Repeater

    一.注册1.日期(1)年月日用三DropDownList个,分别循环写入数字 代码写在后台  Page_Load中的代码 if (IsPostBack == false) { //年绑定数据 ; i- ...

  4. 《Cracking the Coding Interview 》之 二叉树的创建 与 遍历(非递归+递归version)

    #include <iostream> #include <cstdio> #include <vector> #include <stack> #de ...

  5. Bridge(桥接)-对象结构型模式

    1.意图 将抽象部分与它的实现部分分离,使它们都可以独立地变化. 2.动机 在抽象类与它的实现之间起到桥梁作用,使它们可以独立地变化. 3.适用性 不希望在抽象和它的实现部分之间有一个固定的绑定关系. ...

  6. JS打印页面

         打印 整个html页面(PS:样式要写在页面里面才能打印(就是用内部样式))             <a id="dayi" runat="server ...

  7. 技术英文单词贴--D

    D detail 细节,详情 deploy 配置,部署

  8. Oracle中Lpad函数和Rpad函数的用法

     http://blog.csdn.net/woshixuye/article/details/17262307 一.Lpad函数 lpad函数将左边的字符串填充一些特定的字符其语法格式如下:lpad ...

  9. 使用 IntraWeb (40) - 自定义 Session 数据

    修改 UserSessionUnit 单元: unit UserSessionUnit; interface uses IWUserSessionBase, SysUtils, Classes, IW ...

  10. DSS中间件介绍

    DSS中间件采用HTTP协议,终端可以是任何的支持Http协议的设备,开发工具和语言均不受限制 DMS消息服务, 采用类似HTTP的协议 DSS-API介绍(持续更新) http://www.dioc ...