1.Self-HostKestrel1。在vs2017新建一个dotnetcore2.0webapi项目ApiService2。参考官方文档，https://docs.microsoft.com/en-us/aspnet/core/publishing/linuxproduction?tabs=aspnetcore2x在app.UseForwardedHeaders(newForwardedHeadersOptions{ForwardedHeaders=ForwardedHeaders.XForwardedFor|ForwardedHeaders.XForwardedProto})中添加启动;配置运行Url，在Program.cs3.发布工程文件，通过FTP上传到linux服务器。一个新的core2.0webapi项目发布后只有几百kb。4.切换目录，dotnetApiService.dll5。运行成功，打开服务器端口，但是目前运行在Kestrel的selfhost状态。2.需要代理。新开发的KestrelServer负责ASP.NETCore的运行环境，IIS回落到HTTP监听器的角色。对于用户之间的信息转发工作，微软官方推荐在Linux服务器上使用Nginx、Haproxy等代理KestrelServer。了解dotnetcorehost最重要的一点是它独立运行。不在IIS中运行，也不需要IIS运行。它有一个独立的自托管WebServer，并在内部使用自托管服务器来处理请求。但是仍然可以把IIS放在自托管服务器前面作为前端代理，因为Kestrel是一个只有原始功能的web服务器，没有像IIS那样完整的web服务器功能，比如Kestrel没有支持单个ip在Internet上，多个应用绑定到80端口。IIS还可以提供静态文件服务，gzip压缩，静态文件缓存等高级功能。IIS处理请求的效率很高，所以利用这一点很有必要。您可以让iis处理它真正擅长的任务，并将动态任务传递给核心应用程序。所以在windows上，iis依然继续扮演着非常重要的角色。在传统的经典Asp.Net应用中，所有内容都托管在iis工作进程（w3wp.exe）中，也就是我们常说的应用程序池。并且应用程序通过IIS内置的宿主函数加载实例化，通过worker进程加载aspnet_isapi.dll，.Net运行时加载aspnet_isapi。IIS工作进程中的应用程序池加载应用程序域。经过一系列的工作，PR方法被ISAPIRuntime对象调用，封装HttpWorkerRequest对象，传递给HttpRuntime创建HttpApplication实例，然后进行一系列的HttpApplication初始化和管道事件执行。当然，加载运行时、应用域等都只是第一个请求到达后要做的事情。dotnetcore的不同之处在于，core不会运行在iisworker进程中，而是运行在它自己的Kestrel组件中。通过名为AspNetCoreModule的本机IIS模块执行外部应用程序。Kestrel是dotnetweb服务器的一个实现，它针对吞吐量性能进行了大量优化。它快速地将网络请求传递给您的应用程序，但它只是一个原始的Web服务器，没有像IIS这样全面的Web管理服务。尽管IIS站点仍然需要应用程序池，但应将其设置为非托管代码。由于应用程序池仅用作转发请求的代理，因此无需实例化.net运行时。所以在linux上也是一样，我们需要一个自托管的前端代理，这里参考使用nginx。3.nginx作为代理找到/etc/nginx配置nginx.confserver{listen80;location/{proxy_passhttp://localhost:5000;proxy_http_version1.1;proxy_set_headerUpgrade$http_upgrade;proxy_set_headerConnectionkeep-alive;proxy_set_headerHost$host;proxy_cache_bypass$http_upgrade;}}我把nginx的用户root5000改成我自己的10000创建服务文件nano/etc/systemd/system/apiservice.service服务文件内容，官方例子：1[Unit]2Description=Example.NETWebAPIApplicationrunningonUbuntu34[Service]5WorkingDirectory=/var/aspnetcore/hellomvc6ExecStart=/usr/bin/dotnet/var/aspnetcore/hellomvc/hellomvc.dll7Restart=always8RestartSec=10#Restartserviceafter10secondsifdotnetservicecrashes9SyslogIdentifier=dotnet-example10User=www-data11Environment=ASPNETCORE_ENVIRONDy-target=Production1214[InstallBuser]13修改将用户设置为root。我还修改了工作目录，就是我的工程文件通过ftp上传后的目录。ExecStart的dotnet目录并没有修改dll目录，而是改为target要执行的dll的目录，然后enableserviceexecutesystemctlenablekestrel-hellomvc.servicestart并验证servicesystemctlstartkestrel-的状态hellomvc.servicesystemctlstatuskestrel-hellomvc.service监控访问80端口，证明服务成功。4.同样做负载均衡我们再部署一个10001，修改nginx，配置负载均衡。访问证明我们配置成功。5.创建DockerImage官方提供的dotnetcoreimagebitmicrosoft/dotnet。docker的基本命令就不说了，刚开始用的时候就学背了。根据下面的microsoft/dotnet图像创建您自己的图像。为了快速运行多个docker镜像，配置更多的负载均衡，而不需要手动复制到每个服务器去配置环境，也就是说，不管我们创建几十个甚至上百个，如果我们有自己的dockerhub，创建它是速度非常快，而且不会出现在本服务器上不可用，在另一台服务器上也不会出现其他问题。下面只是我自己在学习过程中的一个例子，离最佳实践方法还差得很远。希望对阅读散文的朋友有所帮助。由于nginx也放在各个镜像的apiService前面，所以核心应用在各个容器中采用自托管的形式，运行在Kestrel上。前端通过nginx代理docker暴露的端口号。在发布的网站目录下创建一个Dockerfile。保存后，执行dockerbuild，使用当前目录下的Dockerfile创建镜像。dockerbuild-timage/apiservice-v3。请注意，有一个.最后（使用当前目录）dockerimages查看镜像，我们可以发现新建的docker镜像比我们的FROMmicrosoft/dotnetsize大了一点。下面运行四行命令运行我们刚刚创建的四个imagedockerrun-d-p:81:20000image/apiservice-v3dockerps-a查看正在运行的image进程接下来配置nginx负载均衡然后servicenginxreload,实验完成了。接下来使用dockerkill将docker容器一个一个停止，停止后访问，确认负载均衡成功??。当所有四个容器都停止时，nginx返回502错误。
