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