進擊的.NET 在雲原生時代的蛻變

你必定看過這篇文章 《進擊的 Java ，雲原生時代的蛻變》,  本篇文章的靈感來自於這篇文章。北京時間9.24 就將正式發佈.NET Core 3.0, 因此寫下這篇文章讓你們全面認識.NET Core。

.NET 生態系統是一個不斷變化的生態圈，我相信它正在朝着一個偉大的方向發展。正好 最近 InfoQ 上發佈了一篇文章《.NET 生態系統概覽》，有了開源和跨平臺這兩個關鍵優先事項，咱們就能夠放心了。 下面咱們來參考文章《進擊的 Java ，雲原生時代的蛻變》對雲原生對應用運行時的不一樣需求，說明一個.NET Core 3.0 在雲原生時代所完成的蛻變：

• 體積更小：對於微服務分佈式架構而言，更小的體積意味着更少的下載帶寬，更快的分發下載速度，.NET Core 的鏡像體積都很小，alpine的鏡像更小，帶上應用程序一般80M。
• 啓動速度更快：對於傳統單體應用，啓動速度與運行效率相比不是一個關鍵的指標。緣由是，這些應用重啓和發佈頻率相對較低。然而對於須要快速迭代、水平擴展的微服務應用而言，更快的的啓動速度就意味着更高的交付效率，和更加快速的回滾。尤爲當你須要發佈一個有數百個副本的應用時，緩慢的啓動速度就是時間殺手。對於Serverless 應用而言，端到端的冷啓動速度則更爲關鍵，即便底層容器技術能夠實現百毫秒資源就緒，若是應用沒法在 500ms 內完成啓動，用戶就會感知到訪問延遲。這裏我拿AWS Lambda來舉例，由於各大雲廠商都是以AWS是模仿的目標，AWS Lambda中可用的全部語言都是高級的，而不是像Assembler，C / C ++或Objective C那樣。從腳本語言到JavaScript和Python，再到像Java和C＃到Go這樣被編譯爲二進制文件的託管運行時的語言，全部語言都是他們有本身的長處。在基準測試中，最重要的.NET Core是 冠軍，具體參看https://react-etc.net/entry/aws-lambda-benchmarks-node-js-python-java-c-go-dotnet-core
• 佔用資源更少：運行時更低的資源佔用，意味着更高的部署密度和更低的計算成本。.NET Core的 CLR啓動速度很是快，下降啓動時資源消耗，能夠減小資源爭搶，更好保障其餘應用 SLA。
• 支持水平擴展：.NET Core 3.0默認更好的支持Docker資源限制，官方團隊也在努力讓.NET Core成爲真正的容器運行時，使其在低內存環境中具備容器感知功能並高效運行。 具體能夠參看文章《從CLR GC到CoreCLR GC看.NET Core對雲原生的支持》，隨着內存成本的降低和虛擬化的流行，大內存配比已經成爲趨勢。因此咱們通常是採用水平擴展的方式，同時部署多個應用副本，在一個計算節點中可能運行一個應用的多個副原本提高資源利用率。

.NET Core 3.0 新增功能 大部分的功能特性已經公開，能夠經過網頁：https://docs.microsoft.com/zh-cn/dotnet/core/whats-new/dotnet-core-3-0，其中有幾個特性是很是期待應用到生產的，不少人都在等待着明天的正式發佈。

默承認執行文件

.NET Core 如今默認生成依賴於框架的可執行文件，這個行爲是和.NET Framework保持一致了。 對於使用全局安裝的 .NET Core 版本的應用程序而言，這是一種新行爲。 之前，僅獨立部署會生成可執行文件。

在 dotnet build 或 dotnet publish 期間，將建立一個與你使用的 SDK 的環境和平臺相匹配的可執行文件。 和其餘本機可執行文件同樣，可使用這些可執行文件執行相同操做，例如：

• 能夠雙擊可執行文件。
• 能夠直接從命令提示符啓用應用程序，如 Windows 上的 myapp.exe，以及 Linux 和 macOS 上的 ./myapp。

單文件可執行文件

dotnet publish 命令支持將應用打包爲特定於平臺的單文件可執行文件。 該可執行文件是自解壓縮文件，包含運行應用所需的全部依賴項（包括本機依賴項）。 首次運行應用時，應用程序將根據應用名稱和生成標識符自解壓縮到一個目錄中。 再次運行應用程序時，啓動速度將變快。 除非使用了新版本，不然應用程序無需再次進行自解壓縮。

若要發佈單文件可執行文件，請使用 dotnet publish 命令在項目或命令行中設置 PublishSingleFile：

<PropertyGroup>
   <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
   <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

或者

dotnet publish -r win10-x64 /p:PublishSingleFile=true

這個單文件是你們一直期待的go 特性，.NET Core 3.0正式有了，更詳細的信息參看 https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

程序集連接

.NET core 3.0 SDK 隨附了一種工具，能夠經過分析 IL 並剪裁未使用的程序集來減少應用的大小。

自包含應用包括運行代碼所需的全部內容，而無需在主計算機上安裝 .NET。 可是，不少時候應用只須要一小部分框架便可運行，而且能夠刪除其餘未使用的庫。

.NET Core 如今包含一個設置，將使用 IL 連接器工具掃描應用的 IL。 此工具將檢測哪些代碼是必需的，而後剪裁未使用的庫。 此工具能夠顯著減小某些應用的部署大小。

要啓用此工具，請使用項目中的 <PublishTrimmed> 設置併發布自包含應用：

<PropertyGroup>
   <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

或者

dotnet publish -r <rid> -c Release

例如，包含的基本「hello world」新控制檯項目模板在發佈時命中大小約爲 70 MB。 經過使用 <PublishTrimmed>，其大小將減小到約 30 MB，這個特性能夠用於進一步的減少應用程序的大小。請務必考慮到使用反射或相關動態功能的應用程序或框架（包括 ASP.NET Core 和 WPF）一般會在剪裁時損壞。

分層編譯

.NET Core 3.0 中默認啓用了分層編譯 (TC)。 此功能使運行時可以更適應地使用實時 (JIT) 編譯器來得到更好的性能，這也是一個能夠加速應用啓動的選項。

TC 的主要優點是使（從新）實時編譯方法可以要麼犧牲代碼質量以更快地生成代碼，要麼以較慢的速度生成更高質量的代碼。 這有助於提升應用程序在從啓動到穩定狀態的各個執行階段的性能。 這與非 TC 方法徹底不一樣，其中每種方法均以單一方式進行編譯（與高質量層相同），這種方法偏向於穩定狀態而不是啓動性能。

若要啓用快速 JIT（第 0 層實時編譯的代碼），請在項目文件中使用此設置：

<PropertyGroup>
   <TieredCompilationQuickJit>true</TieredCompilationQuickJit>
</PropertyGroup>

ReadyToRun 映像

能夠經過將應用程序集編譯爲 ReadyToRun (R2R) 格式來改進.NET Core 應用程序的啓動時間。 R2R 是一種預先 (AOT) 編譯形式，這也是一項加速應用啓動時間的選項。

R2R 二進制文件經過減小應用程序加載時實時 (JIT) 編譯器須要執行的工做量來改進啓動性能。 二進制文件包含與 JIT 將生成的內容相似的本機代碼。 可是，R2R 二進制文件更大，由於它們包含中間語言 (IL) 代碼（某些狀況下仍須要此代碼）和相同代碼的本機版本。僅當發佈面向特定運行時環境 (RID)（如 Linux x64 或 Windows x64）的自包含應用時 R2R 纔可用。

主要版本前滾

.NET Core 3.0 引入了一項選擇加入功能，該功能容許應用前滾到 .NET Core 最新的主要版本。 此外，還添加了一項新設置來控制如何將前滾應用於應用。 這能夠經過如下方式配置：

• 項目文件屬性：RollForward
• 運行時配置文件屬性：rollForward
• 環境變量：DOTNET_ROLL_FORWARD
• 命令行參數：--roll-forward

必須指定如下值之一。 若是省略該設置，則默認值爲「Minor」 。

• LatestPatch
  前滾到最高補丁版本。 這會禁用次要版本前滾。
• Minor
  若是缺乏所請求的次要版本，則前滾到最低的較高次要版本。 若是存在所請求的次要版本，則使用 LatestPatch 策略。
• Major
  若是缺乏所請求的主要版本，則前滾到最低的較高主要版本和最低的次要版本。 若是存在所請求的主要版本，則使用 Minor 策略。
• LatestMinor
  即便存在所請求的次要版本，仍前滾到最高次要版本。 適用於組件託管方案。
• LatestMajor
  即便存在所請求的主要版本，仍前滾到最高主要版本和最高次要版本。 適用於組件託管方案。
• Disable
  不前滾。 僅綁定到指定的版本。 建議不要將此策略用於通常用途，由於它會禁用前滾到最新補丁的功能。 該值僅建議用於測試。

Docker 和 cgroup 內存限制

從預覽版 3 開始，在 Linux 上使用 Docker 運行 .NET Core 3.0 時，能夠更好地處理 cgroup 內存限制。 運行具備內存限制的 Docker 容器（例如使用 docker run -m）會更改 .NET Core 的行爲方式。

• 默認垃圾回收器 (GC) 堆大小：最大爲 20 MB 或容器內存限制的 75%。
• 能夠將顯式大小設置爲絕對數或 cgroup 限制的百分比。
• 每一個 GC 堆的最小保留段大小爲 16 MB。 此大小可減小在計算機上建立的堆數量。

垃圾回收堆大小減少

垃圾回收器的默認堆大小已減少，以使 .NET Core 使用更少的內存。 此更改更符合具備現代處理器緩存大小的第 0 代分配預算。

垃圾回收大型頁面支持

大型頁面（也稱爲 Linux 上的巨型頁面）是一項功能，其中操做系統可以創建大於本機頁面大小（一般爲 4K）的內存區域，以提升請求這些大型頁面的應用程序的性能。

如今可使用 GCLargePages 設置將垃圾回收器配置爲一項選擇加入功能，以選擇在 Windows 上分配大型頁面。

.NET 技術在雲原生時代也在不停地進化。.NET Core 做爲.NET 生態的很是重要的一員，在對現有 .NET 應用保持高度兼容的同時，對啓動速度和內存佔用作了細緻的優化，比較適於微服務架構配合使用, 在以kubernetes 爲表明的雲原生應用開發平臺上發生蛻變。

在雲原生時代，咱們要可以在橫向的應用開發生命週期中，將開發、交付、運維過程進行有效的分割和重組，提高研發協同效率；而且要能在整個縱向軟件技術棧中，在編程模型、應用運行時和基礎設施等多層面進行系統優化，實現 radical simplification，提高系統效率。