?2016-2026 Matools All rights reserved,
粵ICP備17059708號(hào)
你一定看過這篇文章 《進(jìn)擊的 Java ，云原生時(shí)代的蛻變
<https://mp.weixin.qq.com/s/x509eBHiDuasGmJupJKVow>》,? 本篇文章的靈感來自于這篇文章。北京時(shí)間9.24
就將正式發(fā)布.NET Core 3.0, 所以寫下這篇文章讓大家全面認(rèn)識(shí).NET Core。
.NET 生態(tài)系統(tǒng)是一個(gè)不斷變化的生態(tài)圈，我相信它正在朝著一個(gè)偉大的方向發(fā)展。正好 最近 InfoQ 上發(fā)布了一篇文章《.NET 生態(tài)系統(tǒng)概覽
<https://www.infoq.cn/article/A6XZ1b5XSZgGHgOjExr6>
》，有了開源和跨平臺(tái)這兩個(gè)關(guān)鍵優(yōu)先事項(xiàng)，我們就可以放心了。 下面我們來參考文章《進(jìn)擊的 Java ，云原生時(shí)代的蛻變
<https://mp.weixin.qq.com/s/x509eBHiDuasGmJupJKVow>》對(duì)云原生對(duì)應(yīng)用運(yùn)行時(shí)的不同需求，說明一個(gè).NET
Core 3.0 在云原生時(shí)代所完成的蛻變：
* 體積更?。簩?duì)于微服務(wù)分布式架構(gòu)而言，更小的體積意味著更少的下載帶寬，更快的分發(fā)下載速度，.NET Core
的鏡像體積都很小，alpine的鏡像更小，帶上應(yīng)用程序通常80M。
* 啟動(dòng)速度更快
：對(duì)于傳統(tǒng)單體應(yīng)用，啟動(dòng)速度與運(yùn)行效率相比不是一個(gè)關(guān)鍵的指標(biāo)。原因是，這些應(yīng)用重啟和發(fā)布頻率相對(duì)較低。然而對(duì)于需要快速迭代、水平擴(kuò)展的微服務(wù)應(yīng)用而言，更快的的啟動(dòng)速度就意味著更高的交付效率，和更加快速的回滾。尤其當(dāng)你需要發(fā)布一個(gè)有數(shù)百個(gè)副本的應(yīng)用時(shí)，緩慢的啟動(dòng)速度就是時(shí)間殺手。對(duì)于Serverless
應(yīng)用而言，端到端的冷啟動(dòng)速度則更為關(guān)鍵，即使底層容器技術(shù)可以實(shí)現(xiàn)百毫秒資源就緒，如果應(yīng)用無法在 500ms 內(nèi)完成啟動(dòng)，用戶就會(huì)感知到訪問延遲。這里我拿AWS
Lambda來舉例，因?yàn)楦鞔笤茝S商都是以AWS是模仿的目標(biāo)，AWS Lambda中可用的所有語言都是高級(jí)的，而不是像Assembler，C / C
++或Objective
C那樣。從腳本語言到JavaScript和Python，再到像Java和C＃到Go這樣被編譯為二進(jìn)制文件的托管運(yùn)行時(shí)的語言，所有語言都是他們有自己的長處。在基準(zhǔn)測試中，最重要的.NET
Core是 冠軍，具體參看
https://react-etc.net/entry/aws-lambda-benchmarks-node-js-python-java-c-go-dotnet-core
<https://react-etc.net/entry/aws-lambda-benchmarks-node-js-python-java-c-go-dotnet-core>
* 占用資源更少：運(yùn)行時(shí)更低的資源占用，意味著更高的部署密度和更低的計(jì)算成本。.NET Core的
CLR啟動(dòng)速度非常快，降低啟動(dòng)時(shí)資源消耗，可以減少資源爭搶，更好保障其他應(yīng)用 SLA。
* 支持水平擴(kuò)展：.NET Core 3.0默認(rèn)更好的支持Docker資源限制，官方團(tuán)隊(duì)也在努力讓.NET
Core成為真正的容器運(yùn)行時(shí)，使其在低內(nèi)存環(huán)境中具有容器感知功能并高效運(yùn)行。 具體可以參看文章《從CLR GC到CoreCLR GC看.NET
Core對(duì)云原生的支持 <https://www.cnblogs.com/edison0621/p/11041725.html>
》，隨著內(nèi)存成本的下降和虛擬化的流行，大內(nèi)存配比已經(jīng)成為趨勢。所以我們一般是采用水平擴(kuò)展的方式，同時(shí)部署多個(gè)應(yīng)用副本，在一個(gè)計(jì)算節(jié)點(diǎn)中可能運(yùn)行一個(gè)應(yīng)用的多個(gè)副本來提升資源利用率。
.NET Core 3.0 新增功能 大部分的功能特性已經(jīng)公開，可以通過網(wǎng)頁：
https://docs.microsoft.com/zh-cn/dotnet/core/whats-new/dotnet-core-3-0
<https://docs.microsoft.com/zh-cn/dotnet/core/whats-new/dotnet-core-3-0>
，其中有幾個(gè)特性是非常期待應(yīng)用到生產(chǎn)的，很多人都在等待著明天的正式發(fā)布。
默認(rèn)可執(zhí)行文件
.NET Core 現(xiàn)在默認(rèn)生成依賴于框架的可執(zhí)行文件
<https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index#framework-dependent-executables-fde>
，這個(gè)行為是和.NET Framework保持一致了。 對(duì)于使用全局安裝的 .NET Core 版本的應(yīng)用程序而言，這是一種新行為。 以前，僅獨(dú)立部署
<https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index#self-contained-deployments-scd>
會(huì)生成可執(zhí)行文件。
在 dotnet build 或 dotnet publish 期間，將創(chuàng)建一個(gè)與你使用的 SDK 的環(huán)境和平臺(tái)相匹配的可執(zhí)行文件。
和其他本機(jī)可執(zhí)行文件一樣，可以使用這些可執(zhí)行文件執(zhí)行相同操作，例如：
* 可以雙擊可執(zhí)行文件。
* 可以直接從命令提示符啟用應(yīng)用程序，如 Windows 上的 myapp.exe，以及 Linux 和 macOS 上的 ./myapp。
單文件可執(zhí)行文件
dotnet publish 命令支持將應(yīng)用打包為特定于平臺(tái)的單文件可執(zhí)行文件。
該可執(zhí)行文件是自解壓縮文件，包含運(yùn)行應(yīng)用所需的所有依賴項(xiàng)（包括本機(jī)依賴項(xiàng)）。 首次運(yùn)行應(yīng)用時(shí)，應(yīng)用程序?qū)⒏鶕?jù)應(yīng)用名稱和生成標(biāo)識(shí)符自解壓縮到一個(gè)目錄中。
再次運(yùn)行應(yīng)用程序時(shí)，啟動(dòng)速度將變快。 除非使用了新版本，否則應(yīng)用程序無需再次進(jìn)行自解壓縮。
若要發(fā)布單文件可執(zhí)行文件，請(qǐng)使用 dotnet publish 命令在項(xiàng)目或命令行中設(shè)置 PublishSingleFile：
<PropertyGroup>
?? <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
?? <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>
或者
dotnet publish -r win10-x64 /p:PublishSingleFile=true
這個(gè)單文件是大家一直期待的go 特性，.NET Core 3.0正式有了，更詳細(xì)的信息參看
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md
<https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md>
程序集鏈接
.NET core 3.0 SDK 隨附了一種工具，可以通過分析 IL 并剪裁未使用的程序集來減小應(yīng)用的大小。
自包含應(yīng)用包括運(yùn)行代碼所需的所有內(nèi)容，而無需在主計(jì)算機(jī)上安裝 .NET。 但是，很多時(shí)候應(yīng)用只需要一小部分框架即可運(yùn)行，并且可以刪除其他未使用的庫。
.NET Core 現(xiàn)在包含一個(gè)設(shè)置，將使用 IL 鏈接器 <https://github.com/mono/linker>工具掃描應(yīng)用的 IL。
此工具將檢測哪些代碼是必需的，然后剪裁未使用的庫。 此工具可以顯著減少某些應(yīng)用的部署大小。
要啟用此工具，請(qǐng)使用項(xiàng)目中的 <PublishTrimmed> 設(shè)置并發(fā)布自包含應(yīng)用：
<PropertyGroup>
?? <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>
或者
dotnet publish -r <rid> -c Release
例如，包含的基本“hello world”新控制臺(tái)項(xiàng)目模板在發(fā)布時(shí)命中大小約為 70 MB。 通過使用 <PublishTrimmed>，其大小將減少到約
30 MB，這個(gè)特性可以用于進(jìn)一步的減小應(yīng)用程序的大小。請(qǐng)務(wù)必考慮到使用反射或相關(guān)動(dòng)態(tài)功能的應(yīng)用程序或框架（包括 ASP.NET Core 和
WPF）通常會(huì)在剪裁時(shí)損壞。
分層編譯
.NET Core 3.0 中默認(rèn)啟用了分層編譯
<https://devblogs.microsoft.com/dotnet/tiered-compilation-preview-in-net-core-2-1/>
(TC)。 此功能使運(yùn)行時(shí)能夠更適應(yīng)地使用實(shí)時(shí) (JIT) 編譯器來獲得更好的性能，這也是一個(gè)可以加速應(yīng)用啟動(dòng)的選項(xiàng)。
TC 的主要優(yōu)勢是使（重新）實(shí)時(shí)編譯方法能夠要么犧牲代碼質(zhì)量以更快地生成代碼，要么以較慢的速度生成更高質(zhì)量的代碼。
這有助于提高應(yīng)用程序在從啟動(dòng)到穩(wěn)定狀態(tài)的各個(gè)執(zhí)行階段的性能。 這與非 TC
方法完全不同，其中每種方法均以單一方式進(jìn)行編譯（與高質(zhì)量層相同），這種方法偏向于穩(wěn)定狀態(tài)而不是啟動(dòng)性能。
若要啟用快速 JIT（第 0 層實(shí)時(shí)編譯的代碼），請(qǐng)?jiān)陧?xiàng)目文件中使用此設(shè)置：
<PropertyGroup>
?? <TieredCompilationQuickJit>true</TieredCompilationQuickJit>
</PropertyGroup>
ReadyToRun 映像
可以通過將應(yīng)用程序集編譯為 ReadyToRun (R2R) 格式來改進(jìn).NET Core 應(yīng)用程序的啟動(dòng)時(shí)間。 R2R 是一種預(yù)先 (AOT)
編譯形式，這也是一項(xiàng)加速應(yīng)用啟動(dòng)時(shí)間的選項(xiàng)。
R2R 二進(jìn)制文件通過減少應(yīng)用程序加載時(shí)實(shí)時(shí) (JIT) 編譯器需要執(zhí)行的工作量來改進(jìn)啟動(dòng)性能。 二進(jìn)制文件包含與 JIT 將生成的內(nèi)容類似的本機(jī)代碼。
但是，R2R 二進(jìn)制文件更大，因?yàn)樗鼈儼虚g語言 (IL) 代碼（某些情況下仍需要此代碼）和相同代碼的本機(jī)版本。僅當(dāng)發(fā)布面向特定運(yùn)行時(shí)環(huán)境 (RID)（如
Linux x64 或 Windows x64）的自包含應(yīng)用時(shí) R2R 才可用。
主要版本前滾
.NET Core 3.0 引入了一項(xiàng)選擇加入功能，該功能允許應(yīng)用前滾到 .NET Core 最新的主要版本。
此外，還添加了一項(xiàng)新設(shè)置來控制如何將前滾應(yīng)用于應(yīng)用。 這可以通過以下方式配置：
* 項(xiàng)目文件屬性：RollForward
* 運(yùn)行時(shí)配置文件屬性：rollForward
* 環(huán)境變量：DOTNET_ROLL_FORWARD
* 命令行參數(shù)：--roll-forward
必須指定以下值之一。 如果省略該設(shè)置，則默認(rèn)值為“Minor” 。
* LatestPatch
前滾到最高補(bǔ)丁版本。 這會(huì)禁用次要版本前滾。
* Minor
如果缺少所請(qǐng)求的次要版本，則前滾到最低的較高次要版本。 如果存在所請(qǐng)求的次要版本，則使用 LatestPatch 策略。
* Major
如果缺少所請(qǐng)求的主要版本，則前滾到最低的較高主要版本和最低的次要版本。 如果存在所請(qǐng)求的主要版本，則使用 Minor 策略。
* LatestMinor
即使存在所請(qǐng)求的次要版本，仍前滾到最高次要版本。 適用于組件托管方案。
* LatestMajor
即使存在所請(qǐng)求的主要版本，仍前滾到最高主要版本和最高次要版本。 適用于組件托管方案。
* Disable
不前滾。 僅綁定到指定的版本。 建議不要將此策略用于一般用途，因?yàn)樗鼤?huì)禁用前滾到最新補(bǔ)丁的功能。 該值僅建議用于測試。
Docker 和 cgroup 內(nèi)存限制
從預(yù)覽版 3 開始，在 Linux 上使用 Docker 運(yùn)行 .NET Core 3.0 時(shí)，可以更好地處理 cgroup 內(nèi)存限制。 運(yùn)行具有內(nèi)存限制的
Docker 容器（例如使用docker run -m）會(huì)更改 .NET Core 的行為方式。
* 默認(rèn)垃圾回收器 (GC) 堆大?。鹤畲鬄?20 MB 或容器內(nèi)存限制的 75%。
* 可以將顯式大小設(shè)置為絕對(duì)數(shù)或 cgroup 限制的百分比。
* 每個(gè) GC 堆的最小保留段大小為 16 MB。 此大小可減少在計(jì)算機(jī)上創(chuàng)建的堆數(shù)量。
垃圾回收堆大小減小
垃圾回收器的默認(rèn)堆大小已減小，以使 .NET Core 使用更少的內(nèi)存。 此更改更符合具有現(xiàn)代處理器緩存大小的第 0 代分配預(yù)算。
垃圾回收大型頁面支持
大型頁面（也稱為 Linux 上的巨型頁面）是一項(xiàng)功能，其中操作系統(tǒng)能夠建立大于本機(jī)頁面大?。ㄍǔ?
4K）的內(nèi)存區(qū)域，以提高請(qǐng)求這些大型頁面的應(yīng)用程序的性能。
現(xiàn)在可以使用 GCLargePages 設(shè)置將垃圾回收器配置為一項(xiàng)選擇加入功能，以選擇在 Windows 上分配大型頁面。
.NET 技術(shù)在云原生時(shí)代也在不停地進(jìn)化。.NET Core 作為.NET 生態(tài)的非常重要的一員，在對(duì)現(xiàn)有 .NET
應(yīng)用保持高度兼容的同時(shí)，對(duì)啟動(dòng)速度和內(nèi)存占用做了細(xì)致的優(yōu)化，比較適于微服務(wù)架構(gòu)配合使用, 在以kubernetes 為代表的云原生應(yīng)用開發(fā)平臺(tái)上發(fā)生蛻變。
在云原生時(shí)代，我們要能夠在橫向的應(yīng)用開發(fā)生命周期中，將開發(fā)、交付、運(yùn)維過程進(jìn)行有效的分割和重組，提升研發(fā)協(xié)同效率；并且要能在整個(gè)縱向軟件技術(shù)棧中，在編程模型、應(yīng)用運(yùn)行時(shí)和基礎(chǔ)設(shè)施等多層面進(jìn)行系統(tǒng)優(yōu)化，實(shí)現(xiàn)
radical simplification，提升系統(tǒng)效率。
熱門工具 換一換