使用 Asp.net core的分析
完全的跨平臺，一套代碼可以多個平臺開發和運行
運行在跨平臺.NET核心框架上的輕量級ASP.NET Core應用程序非常適合精簡容器部署
與傳統的ASP.NET框架相比，主要的好處是：
跨平臺的開發和部署
作為一項功能的重點在性能
簡化的託管模式
更快的版本
開源
模塊化功能
瞭解跨平臺應用程序的侷限性非常重要 - 並不是所有的.NET Framework API都可以在.NET Core中使用。很可能您需要的大多數API將隨著時間的推移而逐漸進入.NET Core，但是需要注意的一點很重要。
以前的ASP.NET框架的託管模式是相對複雜的，依靠Windows Internet Information Services（IIS）提供Web服務器託管。在跨平臺的環境中，這種共生關係是不可能的，而且已經採用了另一種主機模式，它將Web應用程序與底層主機分開。Kestrel是一個可以運行ASP.NET Core的快速跨平臺HTTP服務器，因此這個機會得到了發展。
如下圖ASP.NET應用程序是一種控制檯應用程序，它可以自主託管一個Web服務器並直接處理請求，而不是以前的設計，即IIS調用應用程序的特定點。從概念上講要簡單得多，並允許您從命令行測試和調試您的應用程序，儘管它並不刪除在生產環境中運行IIS（或等效）的需要。
ASP.NET（頂部）和ASP.NET Core（底部）之間託管模型的區別。在以前的ASP.NET版本中，IIS與應用程序緊密耦合，為請求的不同階段調用特定的公開方法。ASP.NET Core中的主機模型比較簡單，IIS將請求轉交給ASP.NET Core應用程序中的自託管Web服務器，並接收響應，但對應用程序沒有更深入的瞭解。
將主機模型更改為使用內置的HTTP Web服務器已經創造了另一個機會。過去，性能一直是ASP.NET應用程序的一個難點。有可能構建高性能的應用程序 - 堆棧溢出（http://stackoverflow.com）是證明 - 但Web框架本身並沒有設計性能作為優先事項，並可能最終成為一個障礙。
為了成為具有競爭力的跨平臺，ASP.NET團隊最近專注於盡可能快地製作Kestrel HTTP服務器。TechEmpower（www.techempower.com/benchmarks）幾年來一直在運行各種語言的Web框架的基準測試。在十三個純文本基準測試中，TechEmpower宣佈，使用Kestrel的ASP.NET Core已成為當前速度最快的主流的Fullstack Web框架，並且是所有框架中前十名中最快的！
Web服務器 - 命名事情很難
目前網絡編程的難點之一是混淆了一些常常相互衝突的術語。例如，如果您以前使用過IIS，則可能將其描述為Web服務器，或可能是Web主機。相反，如果您曾經使用node.js構建過應用程序，那麼您可能也會將該應用程序稱為Web服務器。或者，您可能已經調用了應用程序運行Web服務器的物理機器！
同樣，您可能已經為互聯網構建了一個應用程序，並將其稱為網站或Web應用程序，可能根據其顯示的活力水平而有些任意。
在本文中，當我在ASP.NET Core的上下文中說“web server”時，我指的是作為ASP.NET Core應用程序的一部分運行的HTTP服務器。默認情況下，這是Kestrel Web服務器，但不是必需的。如果你願意的話，可以寫一個替代的Web服務器，並用它代替Kestrel。
Web服務器負責接收HTTP請求並生成響應。在以前的ASP.NET版本中，IIS擔當了這個角色，但在ASP.NET Core中，Kestrel是Web服務器。
我將只使用術語Web應用程序來描述ASP.NET Core應用程序，而不管它們是僅包含靜態內容還是完全動態的。無論哪種方式，他們是通過網絡訪問的應用程序，這個名字似乎是適當的！
對Kestrel所做的許多性能改進並不是來自ASP.NET團隊本身，而是來自GitHub開源項目的貢獻者。開放式開發意味著您通常應該看到修補程序和功能部件的生產速度要比以前版本的ASP.NET更快，而ASP.NET以前的版本依賴於.NET Framework，因此具有較長的發佈週期。
相比之下，ASP.NET Core完全與底層.NET平臺分離。整個Web框架都是作為模塊化NuGet包來實現的，它們可以獨立進行版本化和更新（從構建它們的底層平臺）。
為了實現這一點，ASP.NET Core被設計為高度模塊化的，儘可能少地耦合到其他功能。這種模塊化本身就是一種付費遊戲的依賴方式，您可以從一個簡單的應用程序開始，只添加您需要的附加庫，而不是以前的ASP.NET應用程序的廚房接收器方法。即使MVC是一個可選的包！但是不要擔心，這種方法並不意味著ASP.NET Core缺乏功能; 這只是意味著你需要選擇這些功能。一些關鍵的基礎設施改進包括：
中間件“管道”用於定義應用程序的行為
內置支持依賴注入
結合了UI（MVC）和API（Web API）基礎結構
高度可擴展的配置系統
使用異步編程默認可擴展為雲平臺
在以前的ASP.NET版本中，每個功能都是可能的，但是需要大量額外的工作來設置。有了ASP.NET Core，他們就在那裡，準備好並等待著連接！
微軟完全支持ASP.NET Core，如果你想建立一個新的系統，沒有什麼重要的理由不這樣做。您可能遇到的最大障礙是第三方庫阻止您，因為他們只支持舊的ASP.NET功能，或者他們還沒有轉換到.NET Core的工作。
移植舊程序的難點:
您的應用程序使用ASP.NET Web窗體
您的應用程序建立在Web頁面，WCF，SignalR或VB.NET上
您的應用程序很大，具有許多“高級”MVC功能
什麼是ASP.NET Core？
ASP.NET Core的動機是希望創建一個具有四個主要目標的Web框架：
要運行和開發跨平臺
有一個模塊化的架構，更容易維護
作為開源軟件完全開發。
適用於Web開發的當前趨勢，如客戶端應用程序和部署到雲環境。
為了實現所有這些目標，Microsoft需要一個平臺，可以提供用於創建諸如列表和詞典之類的基本對象的基礎庫，並執行簡單的文件操作。到目前為止，ASP.NET開發一直專注於並依賴於僅限於Windows的.NET Framework。對於ASP.NET Core，Microsoft創建了一個在Windows，Linux和macOS上運行的輕量級平臺，稱為.NET Core，如圖1.2所示。
ASP.NET Core，ASP.NET，.NET Core和.NET Framework之間的關係 ASP.NET Core在.NET Framework和.NET Core上運行，因此可以運行跨平臺。相反，ASP.NET僅在.NET Framework上運行，因此與Windows OS綁定。
.NET Core與.NET Framework共享許多相同的API，但它更小，目前只實現了.NET Framework提供的一部分功能，目的是提供更簡單的實現和編程模型。它是一個全新的平臺，而不是.NET Framework的一個分支，雖然它為許多API使用非常類似的代碼。
單獨使用.NET Core可以構建跨平臺的控制檯應用程序。微軟創建了ASP.NET Core作為控制檯應用程序的附加層，因此轉換為Web應用程序只需簡單地添加和組合庫，如圖所示。
ASP.NET核心應用程序模型。.NET Core平臺為運行命令行應用程序提供了一個基本控制檯應用程序模型。添加Web服務器庫將其轉換為ASP.NET Core Web應用程序。其他功能，如配置和日誌記錄，通過附加庫添加。
通過將ASP.NET Core Web服務器添加到.NET Core應用程序，您的應用程序可以作為Web應用程序運行。ASP.NET Core由許多小型庫組成，您可以從這些小型庫中為應用程序提供不同的功能。你很少需要所有可用的庫，你只需要添加你需要的東西。有些庫是非常常見的，幾乎會出現在您創建的每個應用程序中，例如用於讀取配置文件或執行日誌記錄的應用程序。其他庫建立在這些基本功能之上，以提供應用程序特定的功能，例如通過Facebook或Google進行的第三方登錄。
定義
反向代理是負責接收請求並將其轉發到適當的Web服務器的軟件。反向代理直接暴露給互聯網，而底層Web服務器只暴露給代理。這個設置有幾個好處，主要是Web服務器的安全性和性能。
ASP.NET核心應用程序如何處理請求。從反向代理中的bowser收到請求，該請求將請求傳遞給運行自託管Web服務器的ASP.NET Core應用程序。Web服務器處理請求並將其傳遞給應用程序的主體，該應用程序生成響應並將其返回給Web服務器。Web服務器將其中繼到反向代理，反向代理將響應發送到瀏覽器。
請求從反向代理轉發到您的ASP.NET Core應用程序。每個ASP.NET Core應用程序都有一個內置的Web服務器，Kestrel默認情況下負責接收原始請求並構建數據的內部表示，這個HttpContext對象可以被其他應用程序使用。
從這個表示中，你的應用程序應該有它需要的所有細節來創建一個適當的請求響應。它可以使用存儲的詳細信息HttpContext生成適當的響應，這可能是生成一些HTML，返回“拒絕訪問”消息或發送電子郵件，這些都取決於您的應用程序的要求。
一旦應用程序處理完請求，它就會將響應返回給Web服務器。ASP.NET Core Web服務器會將表示形式轉換為原始HTTP響應，並將其發送回反向代理，反向代理將轉發給用戶的瀏覽器。
這個過程對於用戶來說似乎與前面圖1.7所示的通用HTTP請求相同 - 用戶發送了一個HTTP請求並收到一個HTTP響應。所有的差異都是服務器端，在我們的應用程序內。
您可能會認為有一個反向代理和一個Web服務器有點多餘。為什麼不只是有一個或另一個？那麼好處之一是你的應用程序從底層操作系統中解耦。相同的ASP.NET Core Web服務器Kestrel可以跨平臺，並且可以在各種代理之後使用，而不會對特定實現施加任何限制。或者，如果您編寫了一個新的ASP.NET Core Web服務器，則可以使用它替代Kestrel，而無需更改應用程序的其他任何內容。
反向代理的另一個好處是它可以抵禦來自公共互聯網的潛在威脅。他們通常負責其他方面，例如重新啟動已經崩潰的進程。Kestrel可以作為一個簡單的HTTP服務器，而不必擔心這些額外的功能，當它在反向代理後面使用。把它看作是一個簡單的問題分離; Kestrel關心的是生成HTTP響應，反向代理關心處理與互聯網的連接。
您已經看到請求和響應如何找到自己的方式來自和從ASP.NET核心應用程序，但我還沒有涉及如何產生的響應。在本書的第1部分中，我將展示組成典型ASP.NET Core應用程序的各種組件，以及它們如何組合在一起。很多內容都是在ASP.NET Core中產生響應，通常在幾分之一秒內完成，但是在本書的過程中，我們將慢慢地逐步介紹一個應用程序，詳細介紹每個組件。
在我們介入之前，您需要為您的第一個ASP.NET Core應用程序選擇一個底層平臺，並設置一個構建它的開發環境。
總結：
ASP.NET Core是一個以現代軟件架構實踐和模塊化為重點的新型Web框架。
最好用於新的“綠地”項目，外部依賴很少。
現有的技術，如WCF，SignalR和VB.NET目前不能用於ASP.NET Core，但正在進行整合它們的工作。
獲取網頁涉及發送HTTP請求並接收HTTP響應。
ASP.NET Core允許動態構建對給定請求的響應。
ASP.NET核心應用程序包含一個Web服務器，作為請求的入口點。
反向代理服務器將ASP.NET Core應用程序從互聯網上保護，反向代理服務器將請求轉發給應用程序。
ASP.NET Core可以在.NET Framework和.NET Core上運行。如果您需要Windows註冊表等特定於Windows的功能，則應使用.NET Framework，但無法運行跨平臺。否則，請選擇.NET Core作為最大覆蓋範圍和託管選項。
OmniSharp項目為許多流行的編輯器提供了C＃編輯插件，包括跨平臺的Visual Studio代碼編輯器。
在Windows上，Visual Studio提供了最完整的一體化ASP.NET Core開發體驗，但使用命令行和編輯器進行開發與其他平臺一樣簡單。
閱讀更多 哥們兒是程序猿 的文章
