通常情况下服务器的防火墙通常都是开启的状态,所以我们需要保证我们部署应用程序的端口是开启了相应的访问权限,否则我们的应用程序将无法被外界进行访问。这里为了快速测试应用程序的端口连通性,我们使用比较方便的Telnet工具进行测试,该工具的安装包内置在Windows操作系统中,所以使用起来比较方便。
打开“控制面板”,在“程序和功能”部分,单击“打开或关闭 Windows 功能”。然后在“Windows 功能”列表中,选择“Telnet 客户端”,然后单击“确定”。
在电脑中打开CMD命令窗口,然后输入该格式的命令:“Telnet IP 端口号”。在输入完命令后进行回车后,如果能够跳转到“全黑无内容”的窗口则表示该端口可以正常访问。
如果Telnet提示连接失败,我们则需要为服务器开通指定端口的访问权限,开启的步骤如下:
1.我们进入到“控制面板”找到“Windows防火墙”单击打开,然后在Windows防火墙窗口左侧找到“高级设置”,单击后进入“入站规则”界面;
2.右击左侧栏的“入站规则”节点,点击“新建规则”进入到“新建入站规则向导”界面,创建规则类型选择“端口”单击下一步;
3. 规则应用选择TCP,规则应用的端口勾选“特定本地端口”,然后在输入框中填写我们要开通的端口,然后单击下一步;
4.在操作步骤中选择“允许连接”,在配置文件步骤中勾选所有选项(域、专用、公用);
5.输入自定义规则名称,单击【完成】,即可完成创建;
端口只有在指定分配相应的“服务或站点”后,计算机侦听端口列表才会包含相应的端口,telnet才能够测试相应端口的连通性。可以使用:“netstat -na”命令查看计算机侦听的网络信息。
如果我们在开通端口权限之前,我们的应用程序没有部署在指定端口上,那么我们在命令窗口使用telnet测试端口连通性的时候也是无法连接的。这是因为telnet的功能主要是连接到“服务或站点”的端口,所以前提条件是你开通的端口有指定相应的“服务或站点”。
对于部署之后的ASP.NET Core应用而言,如果是程序在为启动之前发生的异常,通常可能是因为环境配置等原因导致应用程序无法启动,并且我们无法通过程序日志获取到详细的异常信息,导致我们很难排查解决问题的原因。
应用程序在启动之前首先会加载Startup.cs类的ConfigureServices方法以便配置相关的服务,在生产环境中,ConfigureServices方法中使用到了配置文件(appsettings.json)中的某个参数,并且该参数我们忘记配置到服务器环境中的配置文件(appsettings.json),这个时候我们访问站点就会发现,浏览器显示500的状态码且没有详细的错误信息,由于是启动时候的发生的异常,我们日志程序也没有相应的记录。
该案例是我实际工作中遇到的一个比较典型的案例,这种异常的情况也比较好复现出来。在排查问题原因的时候,为此投入了很多的时间和精力。当然可以在本地开发环境中进行调式查看开发异常信息,但是对于项目上线场景的重要性和紧急程度而言,对于这种情况我们的项目必须要采取相应的应对措施,以便快速定位问题原因进行解决。
在排查问题的过程中发现了一个“一劳永逸”的方法,就是“Opw.HttpExceptions.AspNetCore”这个第三方组件。该组件可以帮助我们在应用程序无法启动的时候,以JSON格式返回详细的异常原因。下面介绍使用该组件的步骤:
A.安装 nuget 包 Opw.HttpExceptions.AspNetCore
<PackageReference Include="Opw.HttpExceptions.AspNetCore" Version="2.3.0" />
B.在Startup类的ConfigureServices方法中找到注册MVC服务的代码,在后面新增调用方法AddHttpExceptions。注册MVC服务的方式每个项目可能各有不同,找到相应的位置新增调用方法即可。
C.在Startup类中的Configure方法块的首行添加 UseHttpExceptions方法。
至此在加入Opw.HttpExceptions.AspNetCore组件后,项目已经具备了在应用程序未启动出现异常反馈错误信息的能力,反馈的错误信息格式如下图:
通过返回的JSON格式错误信息,我们可以清楚知道程序配置启动缺失一个“ClientId”参数,有关Opw.HttpExceptions.AspNetCore组件更多的使用方式请详见官方文档:https://libraries.io/nuget/Opw.HttpExceptions.AspNetCore
我们常常在项目上线的过程中,在完成站点的发布和部署之后,访问进入应用程序时,往往会发生一些意料之外的程序功能的异常,如点击页面操作某个功能或者进行登录时。如果部署后的应用程序无法正常运行项目的业务功能,那么这意味着我们的部署工作是不成功的,我们必须要快速解决在上线过程中出现的任何程序异常。
对于生产环境上的ASP.NET Core应用在产生程序异常时,默认情况下我们是无法看到详细的异常信息的,页面只是返回一个500的状态码,这样情况显然对于我们排查问题和用户体验都是不利的,所以我们需要一种应对方式,既能捕获详细的异常信息又能展示出友好的界面提示用户。
在完成ASP.NET Core应用站点的上线部署后,通过指定的URL访问站点,站点能够成功响应请求并返回登录页面。然而在执行登录操作的时候,由于之前数据库账号的密码发生了改变,而配置文件的连接字符串没有做出相应的调整,导致登录时出现异常。然后应用程序并没有在代码中做出相应的异常处理,导致服务器返回状态码500,并且页面没有任何的异常信息,我们也并不知道是因为错误的数据库连接字符串导致的。
为了应对这种情况,我们将使用一种在ASP.NET Core中实现全局异常处理的方式来解决这种问题,该方式能够捕获到详细的异常信息,并且能够将错误信息友好的呈现到视图中。
在项目创建之初Startup.cs类的Configure方法中就存在了一个“UseDeveloperExceptionPage”的中间件,虽然它也可以捕获异常信息,但是只能用在非生产环境中,而对于生产环境中的异常处理我们这可以选择“UseExceptionHandler”中间件进行处理。
具体的实现方式如下:
A.在Startup.cs类的Configure方法中添加UseExceptionHandler方法的调用,UseExceptionHandler方法需要传入一个路由规则参数,该方法捕获到异常时会跳转到对应参数的控制器中,在控制器中我们可以针对异常做出相应的处理,比如进行日志的记录、跳转到呈现错误的视图。
B.根据UseExceptionHandler方法传入的参数(路由规则),创建对应的控制器和Action,并在Action中定义处理异常的具体措施,本文的措施是将异常信息呈现到视图页面并记录到日志。
C.创建呈现程序异常信息的视图页面。
在配置好“UseExceptionHandler”的使用方式后,我们再次复现本段落中出现的案例情况(上线部署后站点能够正常访问,但是登录时出现异常),看看能否呈现出详细的异常信息。
上图已经通过UseExceptionHandler中间件的作用,成功反馈了异常信息,很明显一条关于数据库连接的错误,这样一来我们就可以有针对性的去排查异常的原因,从而避免“无的放矢”的局面。
Web应用的部署看似流程标准化,但是部署人员经常会在这项工作中出现不可预知的风险,严重程度直接影响到客户对项目的验收。所以我们需要尽可能的去规避上线部署的风险,这其中规避风险的方式包括:网络的连通性检查、程序的异常日志处理、上线演练等方式。