簡介面向C#開發(fā)者的WebApi服務(wù)示例重點(diǎn)演示如何通過自托管模式構(gòu)建不依賴IIS的服務(wù)解決跨平臺部署與微服務(wù)擴(kuò)展中的環(huán)境依賴問題。壓縮包共188個(gè)文件、約5.92MB除cs源文件與csproj工程文件外還包括較多dll動(dòng)態(tài)庫、xml文檔、nupkg依賴包、pdb調(diào)試符號、config配置文件以及項(xiàng)目依賴與運(yùn)行環(huán)境配置等覆蓋編譯、運(yùn)行、調(diào)試與文檔所需的主要工程素材。目前已有747人學(xué)習(xí)下載適合希望擺脫Windows自帶IIS束縛、嘗試跨平臺發(fā)布WebApi服務(wù)的.NET開發(fā)者。借助完整Demo讀者可深入理解自托管WebApi服務(wù)的啟動(dòng)、停止與生命周期管理學(xué)習(xí)基于客戶端-服務(wù)器模式的通信方案、RESTful接口設(shè)計(jì)、HTTP標(biāo)準(zhǔn)方法與JSON數(shù)據(jù)交換方式同時(shí)可參考項(xiàng)目中輕量級Web服務(wù)器如HttpListener或Kestrel的集成思路補(bǔ)全安全通信、身份驗(yàn)證與授權(quán)控制等擴(kuò)展設(shè)計(jì)為容器化部署或微服務(wù)架構(gòu)落地提供可改造藍(lán)本。整個(gè)資源目錄從工程配置到核心代碼排列清晰既適合初學(xué)者對照學(xué)習(xí)也方便開發(fā)者進(jìn)行二次拓展。 我們搞.NET開發(fā)的前幾年一提WebApi腦子里默認(rèn)就是建個(gè)ASP.NET項(xiàng)目然后右鍵發(fā)布到IIS上接著去IIS管理器里建站點(diǎn)、配應(yīng)用池一套流程固定得很。但最近這幾年越來越多的項(xiàng)目開始把WebApi從IIS里抽出來用自宿主Self-Host的方式跑再讓IIS在前面做一層反向代理。這個(gè)思路就是我們常說的“C#構(gòu)建與IIS解耦的WebApi服務(wù)Demo”。這篇東西我打算講得細(xì)一點(diǎn)把為什么解耦、解耦之后架構(gòu)怎么變、Kestrel在里邊扮演什么角色、以及IIS反向代理怎么配全部串一遍。不管你是被領(lǐng)導(dǎo)要求把老項(xiàng)目遷出去還是做上位機(jī)開發(fā)時(shí)想給Vue前端提供接口但不想裝IIS這篇都適合你。我會附上完整的Demo工程思路和部署步驟保證你看完能直接照著落地。1. 為什么要把WebApi從IIS里解耦出來1.1 傳統(tǒng)IIS托管模式到底有什么痛點(diǎn)先聊痛點(diǎn)。IIS托管WebApi最常見的問題是進(jìn)程回收。IIS的應(yīng)用池默認(rèn)空閑超時(shí)是20分鐘超過這個(gè)時(shí)間沒有請求工作進(jìn)程直接給你回收掉。等到下一個(gè)請求進(jìn)來IIS重新拉起進(jìn)程這個(gè)過程中所有的靜態(tài)變量、內(nèi)存緩存、后臺定時(shí)任務(wù)全部歸零。做硬件對接、上位機(jī)通信這類項(xiàng)目時(shí)這個(gè)特性非常致命。比如我用C#寫了一個(gè)掃碼槍服務(wù)掃碼槍通過串口或網(wǎng)口持續(xù)報(bào)送數(shù)據(jù)服務(wù)端在內(nèi)存里緩存了最近收到的數(shù)據(jù)包。IIS一回收緩存清空上位機(jī)那邊的一個(gè)簡單的“查詢當(dāng)前批次數(shù)據(jù)”請求拿到的卻是空結(jié)果排查半天才發(fā)現(xiàn)是進(jìn)程被回收了。另外一個(gè)痛點(diǎn)就是部署環(huán)境。早些年IIS只支持Windows想部署到Linux服務(wù)器上根本沒門。雖然現(xiàn)在.NET Framework也支持Windows Container了但那種靈活性和裸金屬Linux上跑一個(gè)Kestrel進(jìn)程比起來還是差了很多。還有一點(diǎn)是IIS作為托管宿主的時(shí)候應(yīng)用程序和服務(wù)器環(huán)境是強(qiáng)耦合的。IIS管理器里幾十個(gè)配置項(xiàng)什么應(yīng)用程序池、管道模式、身份驗(yàn)證、URL重寫任何一個(gè)配置錯(cuò)了服務(wù)就起不來。出了問題還得一邊查Windows事件日志一邊查IIS日志兩邊來回折騰。1.2 解耦之后的服務(wù)架構(gòu)長什么樣解耦之后的架構(gòu)核心思想就是把“Web服務(wù)器”和“應(yīng)用程序”徹底分開。應(yīng)用程序自己充當(dāng)一個(gè)獨(dú)立的進(jìn)程監(jiān)聽端口處理HTTP請求這就是自宿主模式。在ASP.NET Core時(shí)代這個(gè)自宿主進(jìn)程默認(rèn)就是Kestrel。Kestrel是一個(gè)跨平臺的、基于libuv后來換成了自研的Socket基礎(chǔ)設(shè)施的HTTP服務(wù)器它內(nèi)嵌在應(yīng)用程序里。發(fā)布出來的程序本質(zhì)上就是一個(gè)控制臺程序跑起來之后開始監(jiān)聽端口跟IIS毫無關(guān)系。這個(gè)架構(gòu)下我通常這樣部署WebApi服務(wù)Kestrel自宿主監(jiān)聽一個(gè)內(nèi)網(wǎng)端口比如5000。IIS只扮演反向代理把公網(wǎng)或局域網(wǎng)進(jìn)來的請求轉(zhuǎn)發(fā)到5000端口。前端Vue等請求直接走IIS的80/443端口通過反向代理轉(zhuǎn)發(fā)到后端的5000。這樣一拆好處非常明顯。IIS那邊再出什么應(yīng)用池回收、站點(diǎn)重啟的問題后端服務(wù)完全不受影響。反過來后端服務(wù)需要更新版本只要把DLL拷貝進(jìn)去然后重啟進(jìn)程就行IIS連動(dòng)都不用動(dòng)。2. 硬核拆解Kestrel和IIS在這套架構(gòu)里的分工2.1 Kestrel自宿主的技術(shù)原理很多從.NET Framework時(shí)代過來的人第一次接觸Kestrel會覺得有點(diǎn)懵。這里我打個(gè)比方。傳統(tǒng)的IIS托管模式就好像你租了一個(gè)商場的柜臺。商場IIS負(fù)責(zé)開門關(guān)門、打掃衛(wèi)生、安保巡邏。你的柜臺WebApi只管賣東西其他一律不用操心。但問題在于商場一旦說“我要關(guān)門改造20分鐘”你這個(gè)柜臺也得跟著停業(yè)。而Kestrel自宿主呢就相當(dāng)于你自己租了個(gè)臨街店鋪?zhàn)约豪婇l、自己裝門鎖、自己做安保。你的生存完全自理商場管不著你。代價(jià)就是你得自己處理很多之前由IIS承擔(dān)的雜事。Kestrel在做這個(gè)“臨街店鋪”的時(shí)候有幾個(gè)技術(shù)點(diǎn)是必須清楚的。第一個(gè)是端口監(jiān)聽。Kestrel通過UseUrls或者配置文件里的applicationUrl參數(shù)來設(shè)置監(jiān)聽地址。比如我要監(jiān)聽本機(jī)的5000端口就設(shè)置http://0.0.0.0:5000。0.0.0.0是必須的表示監(jiān)聽所有網(wǎng)絡(luò)接口不然外部機(jī)器根本訪問不到。第二個(gè)是請求處理管道。ASP.NET Core的中間件管道Middleware Pipeline是完全由Kestrel來驅(qū)動(dòng)的。請求到達(dá)Kestrel之后按照你在Startup.cs或者.NET 6的Program.cs里注冊的中間件順序依次處理。這個(gè)管道模型和IIS的管道模型不一樣但邏輯上更清晰——從靜態(tài)文件到認(rèn)證授權(quán)所有的事情都在應(yīng)用程序進(jìn)程內(nèi)解決不需要經(jīng)過IIS的那些模塊。第三個(gè)是進(jìn)程生命周期管理。Kestrel進(jìn)程是一個(gè)獨(dú)立進(jìn)程所以你需要一個(gè)守護(hù)方案。Windows下可以用Windows ServiceLinux下可以用systemd或者用Docker方式跑。這個(gè)比IIS省心的是你的服務(wù)進(jìn)程完全在你的掌控范圍內(nèi)你不需要去理解IIS那一大套工作進(jìn)程和回收機(jī)制。2.2 IIS在這里的新角色反向代理解耦之后IIS變成一個(gè)反向代理但很多人其實(shí)沒弄清這里的關(guān)鍵。我一直跟同事講反向代理的核心工作是“轉(zhuǎn)發(fā)”而不是“托管”。在IIS的世界里做反向代理需要兩個(gè)模塊配合缺一不可。第一個(gè)是Application Request RoutingARR。這個(gè)模塊主要提供代理能力它能把請求轉(zhuǎn)發(fā)到指定的后端服務(wù)器地址。ARR的安裝包可以直接從微軟官網(wǎng)下載裝好之后在IIS管理器的根節(jié)點(diǎn)會多出一個(gè)“Server Farm”圖標(biāo)。第二個(gè)是URL Rewrite。這個(gè)模塊負(fù)責(zé)做地址重寫它的作用是把進(jìn)來的請求URL按照規(guī)則重寫。比如說前端請求的是http://www.example.com/api/loginURL Rewrite把路徑里的/api提取出來重寫成http://localhost:5000/api/login然后交給ARR去轉(zhuǎn)發(fā)。這兩個(gè)模塊的工作順序是這樣的請求先進(jìn)入IIS網(wǎng)站的主機(jī)頭到達(dá)URL Rewrite模塊URL Rewrite規(guī)則判斷這個(gè)URL是不是需要代理如果需要就重寫URL并把這個(gè)請求交給ARRARR根據(jù)服務(wù)器場的配置把請求轉(zhuǎn)發(fā)到后端的Kestrel進(jìn)程。這套反向代理模式的好處在于IIS仍然可以處理靜態(tài)文件、HTTPS證書、域名綁定這些“邊緣”事務(wù)動(dòng)態(tài)邏輯則在Kestrel進(jìn)程里處理。換句話說IIS變成了一個(gè)端口守衛(wèi)和證書管家業(yè)務(wù)進(jìn)程的負(fù)擔(dān)被完全解放了。3. 實(shí)操落地一步步搭建解耦的WebApi服務(wù)3.1 創(chuàng)建ASP.NET Core WebApi項(xiàng)目手把手這部分我假設(shè)你用的是Visual Studio 2022或者直接用命令行。用命令行創(chuàng)建項(xiàng)目是最快的。打開終端執(zhí)行dotnet new webapi -n DecoupledWebApi cd DecoupledWebApi這里-n參數(shù)指定項(xiàng)目名。dotnet new webapi模板生成的時(shí)候是空殼子帶一個(gè)默認(rèn)的天氣接口我們直接改造成自己的。如果你堅(jiān)持用VS2022操作路徑是這樣的新建項(xiàng)目 - 選擇“ASP.NET Core Web API”模板 - 項(xiàng)目名稱填DecoupledWebApi- 框架選.NET 8.0或者.NET 6.0看你的環(huán)境然后“身份驗(yàn)證類型”選“無”把“配置HTTPS”勾選去掉——因?yàn)檫@個(gè)Demo跑在內(nèi)網(wǎng)用HTTP就夠了。項(xiàng)目創(chuàng)建好之后打開Program.cs你會看到var builder WebApplication.CreateBuilder(args); builder.Services.AddControllers(); var app builder.Build(); app.UseAuthorization(); app.MapControllers(); app.Run();這是一個(gè)非常精簡的純Kestrel宿主管道。我們在這個(gè)基礎(chǔ)上加兩個(gè)接口——一個(gè)上傳文件接口、一個(gè)下載文件接口。新建一個(gè)FileController.cs文件代碼如下using Microsoft.AspNetCore.Mvc; [ApiController] [Route(api/[controller])] public class FileController : ControllerBase { private readonly IWebHostEnvironment _env; public FileController(IWebHostEnvironment env) { _env env; } [HttpPost(upload)] public async TaskIActionResult Upload(IFormFile file) { if (file null || file.Length 0) { return BadRequest(文件不能為空); } var uploadPath Path.Combine(_env.ContentRootPath, Uploads); if (!Directory.Exists(uploadPath)) { Directory.CreateDirectory(uploadPath); } var filePath Path.Combine(uploadPath, file.FileName); using (var stream new FileStream(filePath, FileMode.Create)) { await file.CopyToAsync(stream); } return Ok(new { fileName file.FileName, size file.Length }); } [HttpGet(download/{fileName})] public async TaskIActionResult Download(string fileName) { var filePath Path.Combine(_env.ContentRootPath, Uploads, fileName); if (!System.IO.File.Exists(filePath)) { return NotFound(文件不存在); } var bytes await System.IO.File.ReadAllBytesAsync(filePath); return File(bytes, application/octet-stream, fileName); } }這個(gè)接口在后面的前后端聯(lián)調(diào)中很有用特別是“如何保持文件名不變”這件事我們用return File(bytes, application/octet-stream, fileName)返回fileName參數(shù)直接指定下載文件名瀏覽器會嚴(yán)格按照這個(gè)名字來做不會出現(xiàn)把blob當(dāng)文件名的情況。3.2 修改監(jiān)聽端口和啟動(dòng)設(shè)置Kestrel默認(rèn)端口是5000但我習(xí)慣在開發(fā)環(huán)境用5200、生產(chǎn)環(huán)境用5300這樣區(qū)分度比較高。在appsettings.json里加一個(gè)節(jié)點(diǎn){ Urls: http://0.0.0.0:5200, Logging: { LogLevel: { Default: Information, Microsoft.AspNetCore: Warning } }, AllowedHosts: * }如果你用的是.NET 6及以上版本Kestrel會自動(dòng)讀取Urls這個(gè)配置節(jié)點(diǎn)。用0.0.0.0而不是localhost或者127.0.0.1原因很簡單——localhost只監(jiān)聽本機(jī)回環(huán)地址外部設(shè)備比如手機(jī)、另一臺電腦是訪問不到你的服務(wù)的。注意AllowedHosts設(shè)置為*表示允許任何Host請求進(jìn)入開發(fā)環(huán)境無所謂生產(chǎn)環(huán)境如果域名固定建議改成你的域名避免被掃描器用IP地址直接訪問。另外如果你項(xiàng)目中有Properties/launchSettings.json這里面的applicationUrl優(yōu)先級比較高。它是給開發(fā)調(diào)試用的VS按F5啟動(dòng)時(shí)讀的是這個(gè)文件。所以你也需要同步修改這個(gè)文件里的applicationUrl為http://0.0.0.0:5200。3.3 發(fā)布與直接運(yùn)行發(fā)布命令很簡單dotnet publish -c Release -o ./publish發(fā)布完成之后進(jìn)入publish文件夾你會看到一堆DLL文件、一個(gè)decoupledwebapi.dll、一個(gè)web.config。這個(gè)web.config是給IIS做反向代理用的后面細(xì)說?，F(xiàn)在直接在終端里運(yùn)行dotnet DecoupledWebApi.dll你會發(fā)現(xiàn)它就是一個(gè)控制臺程序打印出監(jiān)聽地址之后服務(wù)就起來了。你可以用瀏覽器訪問http://localhost:5200/api/file/download/test.txt試試Kestrel全程自己處理沒有IIS參與。4. IIS反向代理配置讓IIS做一道門衛(wèi)4.1 安裝ARR和URL Rewrite模塊IIS要配置反向代理首先必須安裝ARRApplication Request Routing和URL Rewrite這兩個(gè)模塊。IIS默認(rèn)是不帶這兩個(gè)的得單獨(dú)下載。下載地址我直接給兩條路避免你走彎路URL Rewrite在IIS管理器左邊的連接樹里點(diǎn)根節(jié)點(diǎn)服務(wù)器級別找到“管理”分組下的“功能視圖”如果沒有URL Rewrite進(jìn)入微軟官網(wǎng)搜索“IIS URL Rewrite Module”下載。ARR同樣在IIS根節(jié)點(diǎn)如果你沒有看到“服務(wù)器場”圖標(biāo)說明ARR未安裝。微軟官網(wǎng)搜索“IIS Application Request Routing”下載安裝。安裝順序沒有要求兩個(gè)都裝上就行。裝完之后如果你看到IIS根節(jié)點(diǎn)下多了“服務(wù)器場”和“URL重寫”這兩個(gè)圖標(biāo)說明模塊已經(jīng)就位。4.2 創(chuàng)建網(wǎng)站和配置服務(wù)器場首先給這個(gè)反代創(chuàng)建一個(gè)獨(dú)立的站點(diǎn)。打開IIS管理器右鍵“網(wǎng)站”-“添加網(wǎng)站”。站點(diǎn)名稱填DecoupledWebApiProxy物理路徑隨便指一個(gè)空文件夾比如C:\WebSites\DecoupledWebApiProxy綁定端口填8080——你可以用80端口但容易跟其他站點(diǎn)沖突開發(fā)環(huán)境用8080更穩(wěn)當(dāng)。然后到IIS根節(jié)點(diǎn)點(diǎn)擊“服務(wù)器場”右鍵“創(chuàng)建服務(wù)器場”。名稱填DecoupledServerFarm然后在“可用服務(wù)器”里添加服務(wù)器地址填localhost或者127.0.0.1端口填5200HTTP等設(shè)置不用動(dòng)按照向?qū)瓿?。?chuàng)建完成后ARR會彈出提示問你要不要?jiǎng)?chuàng)建一個(gè)URL重寫規(guī)則它默認(rèn)會生成一條“把所有請求都轉(zhuǎn)發(fā)到服務(wù)器場”的規(guī)則。這里的規(guī)則我們需要自定義所以暫時(shí)不要選“創(chuàng)建規(guī)則”后面手動(dòng)配。4.3 編寫URL Rewrite規(guī)則關(guān)鍵中的關(guān)鍵現(xiàn)在進(jìn)入到“URL重寫”配置頁面。找到你剛才創(chuàng)建的那個(gè)站點(diǎn)比如DecoupledWebApiProxy然后雙擊“URL重寫”。在右側(cè)操作面板點(diǎn)擊“添加規(guī)則”選“空白規(guī)則”。填入以下配置。規(guī)則名稱填ProxyToKestrel。匹配URL部分“請求的 URL”選擇“與模式匹配”“使用”選“正則表達(dá)式”“模式”填(.*)條件部分這個(gè)規(guī)則默認(rèn)是所有請求都匹配不需要額外添加條件。注意如果你想限制只有/api路徑的請求做代理可以設(shè)置模式為^api/(.*)$。服務(wù)器變量不需要設(shè)置。操作部分“操作類型”選“重寫”“重寫為”填http://DecoupledServerFarm/{R:1}“停止規(guī)則重寫”勾選“是”配好之后點(diǎn)“應(yīng)用”規(guī)則立即生效。這里的原理是當(dāng)請求地址是http://localhost:8080/api/file/upload時(shí)正則表達(dá)式(.*)捕獲整個(gè)路徑api/file/upload然后重寫到http://DecoupledServerFarm/api/file/upload。DecoupledServerFarm是之前建的服務(wù)器場名稱ARR會自動(dòng)在這個(gè)服務(wù)器場的所有服務(wù)器之間做負(fù)載均衡這里只有一臺就轉(zhuǎn)發(fā)到localhost:5200。注意重寫為字段里的DecoupledServerFarm不要加端口號這是引用服務(wù)器場的名字。如果你不想用服務(wù)器場也可以直接寫http://localhost:5200/{R:1}效果一樣走的是URL Rewrite模塊直接轉(zhuǎn)發(fā)但用服務(wù)器場的好處是可以配置健康檢查、會話保持等高級功能。配置完之后在瀏覽器訪問http://localhost:8080/api/file/upload你看到的不再是IIS的歡迎頁而是Kestrel返回的404因?yàn)镚ET請求不支持上傳說明IIS已經(jīng)把請求轉(zhuǎn)發(fā)到Kestrel了。4.4 通過web.config直接配置反代備選方案有時(shí)候你不想配服務(wù)器場覺得有點(diǎn)重。那可以直接在站點(diǎn)的web.config里寫規(guī)則。其實(shí)IIS的“URL重寫”界面配置最終也是落到web.config文件里的所以你完全可以手動(dòng)編輯。在站點(diǎn)物理路徑下新建一個(gè)web.config文件內(nèi)容如下?xml version1.0 encodingUTF-8? configuration system.webServer rewrite rules rule nameProxyToKestrel stopProcessingtrue match url(.*) / action typeRewrite urlhttp://localhost:5200/{R:1} / /rule /rules /rewrite /system.webServer /configuration這個(gè)配置的意思是所有匹配(.*)的URL全部重寫到http://localhost:5200/路徑下。{R:1}是正則表達(dá)式第一個(gè)捕獲組的引用也就是原始請求的完整路徑。提示如果你要代理的站點(diǎn)和Kestrel監(jiān)聽的端口在同一個(gè)機(jī)器上用localhost就行。如果Kestrel跑在另一臺服務(wù)器上把localhost:5200改成那臺服務(wù)器的IP和端口。這里要注意跨服務(wù)器的防火墻設(shè)置確保反向代理服務(wù)器IIS所在機(jī)器能訪問后端Kestrel所在機(jī)器的5200端口。5. 和上位機(jī)聯(lián)動(dòng)的實(shí)戰(zhàn)經(jīng)驗(yàn)掃碼槍、文件下載與Vue對接5.1 掃碼槍和C#的配合這個(gè)Demo雖然是一個(gè)WebApi服務(wù)但它的實(shí)際場景往往不是單純的互聯(lián)網(wǎng)應(yīng)用更多是給上位機(jī)提供服務(wù)接口。比如你有個(gè)C#寫的上位機(jī)程序需要把掃碼槍掃描到的數(shù)據(jù)通過HTTP請求提交到WebApi服務(wù)怎么做我們的做法是在上位機(jī)側(cè)寫一個(gè)掃碼槍事件處理器。掃碼槍通過串口或者USB模擬鍵盤輸入當(dāng)有掃碼事件發(fā)生時(shí)C#程序捕獲到完整的掃碼字符串然后構(gòu)造一個(gè)POST請求發(fā)到WebApi的接口。這里的關(guān)鍵點(diǎn)在于掃碼槍的輸入是有分隔符的。如果你用串口接收你需要在代碼里判斷幀頭和幀尾把完整的一包數(shù)據(jù)拼出來。如果你用USB模擬鍵盤模式那么直接用一個(gè)全局鍵盤鉤子捕獲即可但要注意掃描速度很多掃碼槍一次掃描會觸發(fā)多個(gè)鍵盤事件你需要把所有字符收集起來直到遇到回車鍵。上位機(jī)收集到掃碼數(shù)據(jù)后調(diào)用我們Demo里的接口類似POST http://localhost:8080/api/scan/receive傳一個(gè)JSON字符串WebApi接收到之后把數(shù)據(jù)寫入數(shù)據(jù)庫或者內(nèi)存隊(duì)列。因?yàn)閃ebApi已經(jīng)在Kestrel進(jìn)程里獨(dú)立運(yùn)行不依賴IIS上位機(jī)的請求即使再頻繁也不會觸發(fā)IIS進(jìn)程回收導(dǎo)致數(shù)據(jù)丟失。5.2 Vue前端與后端接口聯(lián)調(diào)做Vue前端聯(lián)調(diào)的時(shí)候解耦架構(gòu)的好處更明顯。前端開發(fā)人員只需要知道WebApi的地址是http://localhost:8080然后所有請求都走這個(gè)域名就行。代理規(guī)則由IIS統(tǒng)一管理后端服務(wù)的內(nèi)部地址http://localhost:5200完全對前端透明。前端上傳文件的代碼需要注意FormData的傳參名要和后端[FromForm]的參數(shù)名字一致。舉個(gè)例子const formData new FormData(); formData.append(file, file); axios.post(/api/file/upload, formData, { headers: { Content-Type: multipart/form-data } });這里append的第一個(gè)參數(shù)file必須和后端接口的參數(shù)名IFormFile file對應(yīng)上否則后端收到的是null。前端下載文件時(shí)也有一個(gè)經(jīng)典問題——文件名保持。很多人在請求下載接口時(shí)直接用axios然后拿到一個(gè)blob用URL.createObjectURL創(chuàng)建地址下載但發(fā)現(xiàn)下載下來的文件是一個(gè)隨機(jī)字符串。解決方法是從后端返回的響應(yīng)頭里拿Content-Disposition字段解析出filename然后手動(dòng)指定const disposition response.headers[content-disposition]; let fileName download.txt; if (disposition) { const match disposition.match(/filename?([^])?/); if (match) fileName match[1]; } const url window.URL.createObjectURL(new Blob([response.data])); const link document.createElement(a); link.href url; link.setAttribute(download, fileName); document.body.appendChild(link); link.click();這個(gè)方法百試百靈關(guān)鍵是后端的return File(bytes, application/octet-stream, fileName)已經(jīng)設(shè)置了正確的響應(yīng)頭前端解析Content-Disposition就能保證文件名不變。5.3 隱藏IIS響應(yīng)頭的小技巧解耦部署之后前端通過IIS代理訪問響應(yīng)頭里會帶有Server: Microsoft-IIS/10.0這樣的服務(wù)器版本信息。做硬件對接時(shí)很多客戶對安全掃描很敏感這個(gè)版本信息暴露在外網(wǎng)怎么看都不太舒服最好去掉。去掉IIS響應(yīng)頭的方法是在IIS的web.config里加上system.webServer httpProtocol customHeaders remove nameX-Powered-By / /customHeaders /httpProtocol security requestFiltering removeServerHeadertrue / /security /system.webServer其中customHeaders里的remove nameX-Powered-By /可以去掉ASP.NET默認(rèn)添加的X-Powered-By響應(yīng)頭。而requestFiltering removeServerHeadertrue可以讓IIS不發(fā)送Server響應(yīng)頭。注意removeServerHeader屬性需要IIS 7.5及以上版本才支持。如果你還在用IIS 7.0這個(gè)屬性不生效得用URL Rewrite的serverVariables去手動(dòng)刪除。6. 常見問題與排查技巧實(shí)錄6.1 訪問站點(diǎn)提示503 Service Unavailable這是最常見的坑。IIS代理模式下ARR轉(zhuǎn)發(fā)目標(biāo)不可用時(shí)會報(bào)503。先確認(rèn)Kestrel進(jìn)程是否在監(jiān)聽5200端口。排查方法在IIS所在的機(jī)器上打開瀏覽器訪問http://localhost:5200/api/file/download/test.txt如果能正常返回說明后端是通的如果不能說明Kestrel沒起來或者防火墻攔截了。如果localhost能訪問但通過IIS代理之后報(bào)503那大概率是ARR到服務(wù)器場的轉(zhuǎn)發(fā)問題。在IIS根節(jié)點(diǎn)點(diǎn)開“服務(wù)器場”選中DecoupledServerFarm雙擊“代理”檢查“HTTP端口”是不是填寫的5200還可在右側(cè)面板點(diǎn)“重啟”應(yīng)用健康檢查。6.2 響應(yīng)頭里出現(xiàn)兩條Server信息那多半是你還保留了舊版本的靜態(tài)文件服務(wù)器。注意一個(gè)細(xì)節(jié)解耦之后IIS和Kestrel都在處理HTTP請求如果Kestrel也開啟了Server頭而IIS沒來得及移除響應(yīng)頭就會疊加。解決方法是同時(shí)關(guān)掉Kestrel和IIS的Server頭。Kestrel關(guān)閉Server頭的方法是在Program.cs里配置var builder WebApplication.CreateBuilder(args); builder.WebHost.ConfigureKestrel(options { options.AddServerHeader false; });然后IIS側(cè)按5.3的方法移除自己的Server頭這樣兩層都干凈了。6.3 上傳大文件失敗默認(rèn)情況下Kestrel的請求體大小限制是30MB左右IIS的也有限制。做上位機(jī)上傳日志、相機(jī)拍照圖片的場景很容易就超出這個(gè)限制。Kestrel側(cè)修改限制在Program.cs里builder.Services.ConfigureFormOptions(options { options.ValueLengthLimit int.MaxValue; options.MultipartBodyLengthLimit int.MaxValue; });IIS側(cè)的限制在web.config里設(shè)置system.webServer security requestFiltering requestLimits maxAllowedContentLength524288000 / /requestFiltering /security /system.webServer這里面maxAllowedContentLength的單位是字節(jié)524288000就是500MB。兩邊的限制都要改否則哪一個(gè)先攔截都會導(dǎo)致上傳失敗。特別說一句MultipartBodyLengthLimit默認(rèn)是128MB這個(gè)值經(jīng)常被忽略。很多人在IIS那邊改了限制發(fā)現(xiàn)大文件還是傳不上去其實(shí)就是Kestrel這邊卡住了。6.4 前端請求跨域CORS問題解耦模式下IIS代理的域名和Kestrel自宿主的域名不一樣如果前端直接用axios請求Kestrel的5200端口必然觸發(fā)跨域。雖然在我們的方案里前端都走IIS的8080端口但在開發(fā)階段很多前端工程師習(xí)慣直連后端。為了解決聯(lián)調(diào)階段的跨域問題后端需要啟用CORS。在Program.cs里加上var builder WebApplication.CreateBuilder(args); builder.Services.AddCors(options { options.AddPolicy(AllowAll, policy { policy.AllowAnyOrigin() .AllowAnyMethod() .AllowAnyHeader(); }); }); // ... app.UseCors(AllowAll);注意生產(chǎn)環(huán)境不建議用AllowAnyOrigin這等于允許任意網(wǎng)站調(diào)用你的接口。如果接口只在內(nèi)部用建議配置為WithOrigins(http://localhost:8080, http://192.168.1.100)等具體的來源地址。6.5 發(fā)布之后配置文件沒生效不少人會把a(bǔ)ppsettings.json遺忘在發(fā)布目錄之外。dotnet publish命令默認(rèn)會把a(bǔ)ppsettings.json復(fù)制到輸出目錄但如果你改了文件內(nèi)容卻沒重新發(fā)布運(yùn)行的時(shí)候讀的還是舊的配置。判斷方法在運(yùn)行目錄下打開DecoupledWebApi.dll旁邊的appsettings.json看里面的Urls配置是不是想要的端口如果不對手動(dòng)改一下再重啟服務(wù)就行——這是自宿主模式一個(gè)特有的便利不用重新編譯改完配置文件直接重啟進(jìn)程就生效了。7. 實(shí)際操作中的幾點(diǎn)體會寫到這里關(guān)于這個(gè)方案我想再做幾點(diǎn)補(bǔ)充。在硬件測試、上位機(jī)開發(fā)這個(gè)圈子里解耦WebApi的思路越來越流行。我們之前一套設(shè)備機(jī)箱里的工控機(jī)運(yùn)行著C#寫的上位機(jī)軟件同時(shí)又跑著一個(gè)WebApi給MES系統(tǒng)上報(bào)數(shù)據(jù)。以前這個(gè)WebApi部署在IIS里用戶改完配置點(diǎn)了一下“回收應(yīng)用程序池”整個(gè)MES通信中斷了十幾秒產(chǎn)線報(bào)警。后來改成Kestrel自宿主Windows服務(wù)注冊重啟時(shí)間和MES斷線問題就再也沒出現(xiàn)過了。第二個(gè)體會是關(guān)于部署工具的選型。如果你面向的生產(chǎn)環(huán)境是Windows Server我特別推薦用Windows Service方式注冊Kestrel。在發(fā)布目錄里執(zhí)行一行命令就能注冊sc create DecoupledWebApi binPath C:\path\to\publish\DecoupledWebApi.exe start auto這樣開機(jī)自啟、異常重啟都由Windows服務(wù)控制控制臺程序掛掉還能自動(dòng)恢復(fù)運(yùn)維省心太多了。第三個(gè)體會是日志。自宿主模式的日志默認(rèn)打到哪里很多人搞不清。Kestrel默認(rèn)是寫到控制臺的如果你注冊成了Windows服務(wù)跑控制臺窗口根本不存在日志就丟了。我們實(shí)際項(xiàng)目里都是接Serilog輸出到文件或者數(shù)據(jù)庫這樣出了問題才能有據(jù)可查。這個(gè)點(diǎn)放在最后說是因?yàn)槲乙娺^太多人解耦之后說“服務(wù)掛了我都不知道為什么”其實(shí)就是日志沒配好。以上就是我從傳統(tǒng)IIS托管模式遷移到Kestrel自宿主反向代理模式的全過程。這套架構(gòu)不是銀彈但確實(shí)解決了很多實(shí)際的部署和維護(hù)問題。如果你也在做C#相關(guān)的服務(wù)端開發(fā)手里有硬件設(shè)備要對接強(qiáng)烈建議花一天時(shí)間照著Demo把流程跑一遍你會對“解耦”這兩個(gè)字的體會完全不一樣。本文還有配套的精品資源點(diǎn)擊獲取