クラウド時代の.NETネイティブの転換への攻撃

あなたはこの記事「読まなければならない攻撃変換するJava、ネイティブクラウド時代の記事からこの記事に触発さ」を、。私たちは、.NETのコアの十分な理解を持っているように、この記事を書くためになるよう、北京9.24は公式に、.NETのコア3.0をリリースされます。

.NETのエコシステムは、刻々と変化する生態系ですが、私はそれは素晴らしい方向に移動していると考えています。InfoQはつい最近「の記事公表.NETエコシステムの概要」、オープンソースとクロスプラットフォームこれら二つの重要な優先事項で、私たちは安心できます。記事「を参照してみましょう攻撃変換するJavaのネイティブクラウド時代」ネイティブクラウド時代の完全な変換で.NETコア3.0を示すさまざまなニーズに実行されているクラウドネイティブアプリケーション、：

• より小さい：マイクロサービス分散アーキテクチャのために、より小さなサイズが少ないダウンロード帯域幅を意味し、より高速なダウンロードが分布速度、.NETコアボリュームをミラーもたらす、より小さい非常に小さい、高山鏡像でありますアプリケーション通常80M。
• より速く起動します：従来の単一アプリケーションの起動速度や運転効率がない重要な指標と比較します。その理由は、これらのアプリケーションと再起動が比較的低い周波数を公開していることです。しかし、急速な反復、マイクロサービスアプリケーションの水平展開の必要性は、より高速な起動速度が高い送達効率、およびより高速なロールバックを意味します。あなたはアプリケーションの数百コピーを公開する必要がある場合には特に、遅い起動速度は時間キラーです。サーバレスアプリケーションの場合、コールドスタートのエンドツーエンドはさらに重要で、基本的な技術は、数百ミリ秒のコンテナリソースの準備ができていることができても、アプリケーションが500msの開始以内に完了することができない場合、ユーザーはアクセスのレイテンシを知覚します。私は、大手クラウドベンダーは、すべてのAWSがゴールの模倣であるため、すべての言語ではなくアセンブラ、C / C ++またはそのObjective Cのよりも、高度なAWSラムダで利用可能な、AWSラムダ例を取るためにここにいます。スクリプト言語からのJavaScriptとPythonに、JavaやC＃のように、この言語に行くマネージドランタイムバイナリファイルにコンパイルされ、彼らはすべての言語は、独自の強みを持っています。ベンチマークテスト、最も重要な.NETのコアチャンピオン、特定を参照するにはhttps://react-etc.net/entry/aws-lambda-benchmarks-node-js-python-java-c-go-dotnet-core
• より少ないリソースを占有：低リソース消費の操作、計算密度と低コストの展開が高いことを意味します。.NETのコアは、非常に高速な起動作業を開始するときに、リソースの消費量を減らすには、資源と優れた安全装置他のアプリケーションのSLAのための競争を減らすことができ、CLR。
• サポート拡大のレベル開発：.NETのコアが3.0デフォルトより良いドッカーリソースの制約をサポートするには、公式のチームはそれが低メモリ環境で効率的な操作で、コンテナを意識した機能を持って、本当に.NETコアランタイム・コンテナを作成しようとしています。特定の記事で見つけることができる「CoreCLR GCへのCLR GCからクラウドネイティブの.NETのコアのサポートを参照してください仮想化とメモリコストの人気が衰退して、」大容量メモリの比率は、傾向となっています。だから我々は、一般的にコピーし、コンピューティング・ノードの複数のコピーがリソースの使用率を改善するために、1つのアプリケーションを実行することができ、同時に複数のアプリケーションを展開するための水平スケーラブルな方法を使用していました。

.NETのコア機能のほとんどは、それがウェブサイトを通じて可能であり、開示されている3.0の新機能：https://docs.microsoft.com/zh-cn/dotnet/core/whats-new/dotnet-core-3-0、どのいくつかの特性は非常に多くの人々が明日の公式リリースを待っている、生産に楽しみにしているがあります。

デフォルトの実行可能ファイル

.NETのコアがデフォルトで生成された実行可能ファイルのフレームに依存し、そしてこの動作は、.NET Frameworkと一致しています。.NETアプリケーションのグローバルインストールCoreバージョンの点で使用するために、これは新しい動作です。以前は、唯一の独立した展開は、実行可能ファイルを生成します。

ではdotnet buildまたはdotnet publishSDKの間に実行可能ファイルであなたを一致させるために使用される環境やプラットフォームを作成することができます。そして、他のネイティブの実行可能ファイルは、実行可能ファイルは、たとえば、同じ操作を実行するために使用することができます。

• あなたは、実行可能ファイルをダブルクリックすることができます。
• あなたは、Windows上のように、コマンドから直接対応アプリケーションを促すことができるmyapp.exe、そしてLinuxやMacOSで./myapp。

単一の実行可能ファイル

dotnet publishコマンドは、プラットフォーム固有のアプリケーションが単一の実行可能ファイルとしてパッケージ化されてサポートしています。実行可能ファイルは、（ネイティブの依存関係を含む）アプリケーションを実行するために必要なすべての依存関係を含む自己解凍型のファイルです。あなたがアプリケーションを初めて実行すると、アプリケーションがディレクトリに自己解凍型の生成されたアプリケーション名と識別子に基づいて行われます。再度アプリケーションを実行すると、速度が速く起動します。新バージョン、を必要とすることなく、それ以外のアプリケーションがない限り、再び自己解凍。

単一の実行可能ファイルを公開するには、使用しdotnet publishたプロジェクトまたはコマンドラインで設定したコマンドをPublishSingleFile：

<PropertyGroup>
   <RuntimeIdentifier> win10-x64の</ RuntimeIdentifier>
   <PublishSingleFile>真</ PublishSingleFile>
</ PropertyGroup>

若しくは

PublishSingleFile =真：DOTNETは-r win10-x64の/ Pを公開します

この単一のファイルには、私達は特性を行くことを楽しみにされていますが、.NETのコアの正式な、より詳細な情報を見る3.0 https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

アセンブリリンカー

NETのコア3.0 SDKツールが付属して、サイズILトリミングアセンブリのアプリケーションと分析によって低減することができるが使用されていません。

アプリケーションは、ホストコンピュータにインストールされている.NETなしでコードを実行するために必要な自己完結型のすべてのものが含まれます。しかし、何度もアプリケーションを実行するためのフレームワークのほんの一部を必要とし、あなたは他の未使用のライブラリを削除することができます。

.NETのコアは現在、セット、含まILリンカ ILツールのスキャンアプリケーションを。このツールは、ライブラリは、未使用のトリミング、必要とされるコードを検出します。このツールは、大幅に特定のアプリケーションの展開のサイズを小さくすることができます。

このツールを有効にするには、プロジェクトの使用<PublishTrimmed>設定と打ち上げ自己完結型のアプリケーションを：

<PropertyGroup>
   <PublishTrimmed>真</ PublishTrimmed>
</ PropertyGroup>

若しくは

DOTNETは-r公開<取り除く> -cリリース

ヒットのサイズは約70 MBです公開するときたとえば、新しいコンソールプロジェクトテンプレートの基本的な「Hello World」の中に含まれています。使用することにより<PublishTrimmed>、そのサイズは約30 MBに削減されます、この機能は、さらにアプリケーションのサイズを小さくするために使用することができます。多くの場合、トリミング中に破損したアプリケーションや反射枠または（ASP.NET CoreおよびWPFを含む）は、動的関連機能の使用を検討してください。

階層のコンパイル

.NETのコア3.0は、デフォルトで有効になっている階層コンパイル（TC）。この機能は、リアルタイム（JIT）コンパイラの使用は、より適応的により良いパフォーマンスのためのランタイムができ、これは、アプリケーションの起動を高速化するために可能な選択肢であることができます。

TCの主な利点は、リアルタイム法は、高品質のコードを生成するための高速なコード、または遅い速度を生成するために、コードの品質を犠牲にするかコンパイル（再）です。これは、最初からの定常状態への実行のさまざまな段階でのアプリケーションのパフォーマンスを向上させることができます。この方法は、各単一のメソッドである（同じ高品質の層）をコンパイルする非TC、この方法は、定常状態の始動性能にバイアスされていないとは全く異なります。

高速なJIT（0層リアルタイムコンパイルされたコード）を有効にするには、プロジェクトファイルでこの設定を使用します。

<PropertyGroup>
   <TieredCompilationQuickJit>真</ TieredCompilationQuickJit>
</ PropertyGroup>

ReadyToRun 映像

起動時間.NETコアアプリケーションを改善するために、アプリケーションセットReadyToRun（R2R）フォーマットにコンパイルすることができます。R2Rは、アプリケーションの起動時間を高速化するためのオプションである、事前（AOT）コンパイルの形態です。

リアルタイム（JIT）コンパイラでアプリケーションをロードする際の作業負荷を減らすことにより、起動時のパフォーマンスを向上させるためのR2Rバイナリファイルは実行する必要があります。JITバイナリファイルが生成されたネイティブコードに類似したコンテンツが含まれています。しかし、これらは中間言語（IL）コードが含まれているため、より大きなR2Rバイナリは、同じコードのネイティブバージョン（まだこのいくつかのケースでは、コードを必要とします）。場合のみ、リリース固有の動作環境（RID）R2Rが利用可能である自己完結型のアプリケーション（例えば、Linuxのx64のまたはWindows x64のような）。

元メジャーリリースロール

.NETのコア3.0は、アプリケーションの前に、.NETのコアの最新メジャーリリースにロールすることができますオプトイン機能を導入しました。加えて、予備ロールがアプリケーションで使用される方法を制御するために新しい設定を追加しました。これは、次の方法で設定できます。

• プロジェクトファイル属性：RollForward
• プロファイルプロパティのランタイム：rollForward
• 環境変数：DOTNET_ROLL_FORWARD
• コマンドラインパラメータ：--roll-forward

あなたは、次のいずれかの値を指定する必要があります。設定を省略した場合、デフォルト値「マイナー」。

• LatestPatch
  最高パッチバージョンにロールフォワード。これはマイナーバージョンを無効にする前にロールバックされます。
• マイナー
  要求されたマイナーバージョンが存在しない場合は、より高い最小のマイナーバージョンの前にロールバックされます。要求されたマイナーバージョンがある場合、それは使用していますLatestPatch戦略を。
• 主な
  要求されたメジャーバージョンが存在しない場合は、より高いメジャーバージョンと最低の最小マイナーバージョンにロールフォワード。要求された使用のメジャーバージョンがある場合はマイナーな戦略は。
• LatestMinor
  要求があるのも、マイナーバージョンは、まだ最高のマイナーバージョンにロールフォワードされます。コンポーネントホスティングパッケージに適用されます。
• LatestMajor
  ロール前にそこに要求された場合でも、メジャーバージョンは、まだ最高のメジャーバージョンとマイナーバージョン最高です。コンポーネントホスティングパッケージに適用されます。
• 無効には
  ロールフォワードされません。唯一の特定のバージョンにバインドします。それは機能を無効にする前に最新のパッチが巻かれているため、この戦略は、一般的な使用は推奨されません。この値は、テストのために推奨されます。

ドッカーとのcgroupのメモリ制限

開始からプレビュー3は、ドッカーは、.NETのコアのLinux 3.0上で実行する使用して、あなたはより良いメモリ制限のcgroup処理することができます。（例えばメモリ制限とドッカーコンテナを実行しますdocker run -m.NETのコアの動作を変更します）。

• デフォルトのガベージコレクタ（GC）ヒープ・サイズ：最大20 MBまたは血管メモリ制限の75％。
• 明示的なサイズは、パーセンテージまたは絶対のcgroupの制限として設定してもよいです。
• 各セグメントの最小サイズは、16メガバイトのGCヒープ予約しました。これは、コンピュータ上で作成されたヒープサイズの数を減らすことができます。

ガベージコレクションのヒープサイズを小さく

.NETのコアは、少ないメモリを使用するようにガベージコレクタのデフォルトのヒープサイズは、縮小されています。この変更は、より近代的なプロセッサのキャッシュサイズと予算配分の世代0に沿ったものです。

ガベージコレクションラージ・ページのサポート

（また、Linux上の巨大なページとして知られている）ラージ・ページは、オペレーティング・システムがこれらの大きなページを要求するアプリケーションのパフォーマンスを向上させるためには、ネイティブのページサイズ（通常は4K）メモリ領域よりも多くを確立することである関数です。

これで、使用することができますGCLargePages Windows上で大きなページの割り当てを選択するためにオプトイン機能として構成されたガベージコレクタを設定します。

.NETテクノロジは常にクラウドネイティブの時代に進化しています。.NET生態学的に非常に重要なものとして.NETコアサービスを使用して詳細な最適化、より適切なマイクロアーキテクチャを作るために、速度とメモリフットプリントを開始するために、既存の.NETアプリケーションに互換性の高度を維持しつつ、させるためにネイティブクラウドアプリケーション開発プラットフォームが表すようkubernetes変換が発生します。

クラウドネイティブの時代に、私たちは、効果的なセグメンテーションと再構成のための水平方向のアプリケーション開発ライフサイクル、開発、配信、運用・保守のプロセスにできるように、研究開発のコラボレーションの効率を向上させる必要があり、全体の垂直ソフトウェア技術スタックにできるように、プログラミングマルチレベル・モデルは、アプリケーションが実行され、システムインフラストラクチャは、ラジカル簡素化を図るシステムの効率を改善するために最適化されました。