project omega

project omega

これまでに必要となる最後のエンタープライズ Web アーキテクチャ パターン。次まで。

TL;DR

目標は、次のことを可能にすることで開発者のエクスペリエンスを最適化することです。

• あたかも一枚岩であるかのようにローカルで開発する
• 個別のマイクロサービスとしてデプロイする
• Docker を使用してローカルで本番環境をシミュレートする

デモ

project omegaの概念実証 - マイクロサービス モノリス ハイブリッド

project omegaデモ - Kubernetes Microserve とスタンドアロン コンテナのデプロイメント

なぜ

スケーラビリティを得るために開発者の効率を犠牲にする必要はないことを証明したいと思っています。マイクロサービスとモノリスの長所と短所について詳しくは、「マイクロサービスとモノリス」を参照してください。

私の印象では、多くの業界専門家は、主に次の 3 つのオプションがあると考えているようです。

• モノリス
• マイクロサービス
• 「ハイブリッド」 (実際にはハイブリッドではなく、モノリスと一部のマイクロサービスの両方)

これらのオプションのいずれかを選択する必要はないことを示したいと思います。少し創造力を発揮すれば、モノリスと一連のマイクロサービスの両方である真の「ハイブリッド」を実現できます。私の現在の戦略では、モノリスとマイクロサービスの欠点をすべて取り除くことはできないと思いますが、両方の問題点の多くを取り除くことはできます。

それは何ではないのか

• 私はフレームワークを作ろうとしているわけではありません（少なくともまだ…）。実験として、私が持っているすべてのレゴを別の構成に組み立てているところです。
• これはコミュニティ プロジェクトを意図したものではありません。予告なしに劇的な破壊的変更を頻繁に行うつもりです。このコンセプトが興味深く、貢献したいと思われる場合は、まず私にご連絡ください。

プロジェクトの目標

• 小規模な 1 人の開発者の趣味のプロジェクトとして機能するパターンを作成し、大規模で複雑なエンタープライズ Web アプリケーションを開発する数十人または数百人の開発者にまで拡張できるパターンを作成します。
• あたかもモノリスであるかのようにローカルで開発できるようにします。
  • リポジトリは 1 つ。まったく同じ理由で、企業はモノリポジトリのアプローチを選択します。
  • 実行する最大 3 つのプロセス (クライアント UI、サーバー、データベースとの Docker 依存関係、メッセージ キューなど)。セットアップ ドキュメントのページを立ち上げて実行する必要はありません。
• マイクロサービスとしてデプロイできるようになります。
• Docker コンテナーで実行されるマイクロサービスを使用して実稼働環境をシミュレートできるようになります。
• 非常に速いセットアップ時間。 Node と .NET 以外のすべての依存関係は、Docker の依存関係 (データベース、メッセージ キューなど) として含める必要があります。新規ユーザーは、.NET、ノードをインストールし、リポジトリを複製して、インストールとコマンドの実行を実行できる必要があります。
• 開発環境のクライアントとサーバーの両方で非常に高速なホットリロード。
• Windows、Linux、Mac 上でアプリケーションを開発して実行できること。
• 新しいサービスを迅速に起動できるようになります。

技術スタック

技術スタックは、私が証明しようとしている高レベルの概念にはほとんど無関係ですが、このプロジェクトでは次のものを使用します。

• サービス用の .NET 5
• React フロントエンド (typescript を使用した基本的な create-react-app)
• ドッカー

高レベルの概念

大規模なアプリケーションを抱える企業は、(他の理由もあり) 水平方向に拡張できるよう、マイクロサービスへの移行がますます進んでいます。したがって、これを達成するために、次のようなものを検討しています。

以下は、水平スケーリングの実装方法の 1 つを示す別のバージョンです。

この道をたどると、地方開発における本当の問題に行き着きます。それは実際、製品がどのようなものであるか、開発者の数、誰が何をどのくらいの頻度で作業するかによって異なります。そうは言っても、マイクロサービスを選択する企業の大部分は、開発者が日々の開発をどのように行うかについて難しい選択をしなければならない状況に陥ることになるでしょう。 project omegaの目標は、ローカルで実行しているときにサービスをすべて 1 つのアプリケーションに結合することで、ローカルで実行するオーバーヘッドを排除できることを示すことです。

フォルダー構造は次のとおりです。

マイクロサービスとしてデプロイすると次のようになります。

各インスタンスにはすべてのコードのコピーがありますが、特定のマイクロサービスの初期化、サービス エンドポイント ルート、およびワーカー プロセスのみが実行されます。

SERVICE_KEYという環境変数を探すか、存在しない場合はすべてのサービスを初期化するだけなので、アプリケーションをモノリスとしてローカルで実行するのが非常に簡単なのはこのためです。

他のサービス固有の初期化の例:

• 依存性注入のセットアップ
• データベース接続文字列
• データベースの移行
• メッセージキューの初期化
• 分散キャッシュ接続のセットアップ
• その他のクラウドリソースの接続設定
• サードパーティAPIの初期化

Startup が呼び出されると、アセンブリをスキャンしてProjectOmegaService継承する型を探し、インスタンスを作成し、そのサービスの初期化ロジックを実行します。ローカルで実行すると、すべてが実行されます。

セットアップ手順

前提条件をインストールします。

• .NET 5
• ノード
• 糸
• ドッカー

Windows 上で最新バージョンの Docker を実行するには、しばらくこれを行っていない場合、WSL 2 のインストールや WSL ディストリビューションの更新など、追加の手順が必要になる場合があることに注意してください。 Docker の Web サイトの指示に従ってください。

手順:

• このリポジトリのクローンを作成します
• ターミナルで、リポジトリのルートから、 yarn run installAll実行します。
• SQL サーバーを 1434 以外のポートで実行する場合:
  • yarn run syncEnvFiles
  • .env.serverのOMEGA_DEFAULT_DB_PORTとOMEGA_MSSQL_HOST_PORTを変更します。
• コマンドyarn run dockerDepsUpDetachedを使用して依存関係を開始します。
• DB マイグレーションを初めて実行するとき、またはデータベースの更新で他の人が変更を取得したときに実行します: yarn run dbMigrate
• 次のオプションのいずれかを使用して、ローカル開発モードでアプリを実行します。
  • オプション 1: ターミナルで、リポジトリのルートからyarn run both (これは、オプション 2 のコマンドを同時に実行するために使用します)
  • オプション 2: 2 つの別々の端末を使用します。一方の端末ではyarn run client実行し、もう一方の端末ではyarn run server実行します。
• https://localhost:3000 にアクセスします (https 警告を過ぎたところをクリックします)

初めてdotnet testを使用して単体テストを実行する前、または新しい DB スキーマに単体テストを追加した後:

• yarn run dockerDepsUpDetachedでまだ実行されていない場合は依存関係を開始します
• yarn run testDbMigrateする
• 次に、 dotnet testを実行します

Docker で本番環境とマイクロサービスをシミュレートするには:

• yarn run dockerDepsUpDetachedを使用して docker の依存関係が実行されていることを確認します。
• ターミナルで、リポジトリのルートから、 yarn run dockerRecreateFullを実行します。
• https://localhost:3000 にアクセスします (https 警告を過ぎたところをクリックします)

次のステップ

• 変更のログ記録
  • Serilog json フォーマッタを試してみる
  • 相関 ID およびその他のコンテキスト情報をログ エントリに追加します。
• 追加のドキュメントを追加する
  • Docker シミュレーションの仕組みを示す図
  • Docker の依存関係
    • それが何であるか、どのように機能するかをテキストで説明します
    • docker deps が開発プロセスにどのように適合するかを示す図
  • ルーティング/プロキシのドキュメント
  • DBの移行
• http REST 呼び出しの代わりにサービス間の RPC テスト (おそらく次のようなものを使用します: https://github.com/aspnet/AspLabs/tree/main/src/GrpcHttpApi)
• サービス間のクライアント基本クラスに追加して、エラー処理とログを抽象化します。
• 認証の実装
  • フロントエンドサイトの登録
  • サービス間認証 (OAuth?)
• 自動ドキュメント生成 (Swagger および HTML XML ドキュメント出力)
• キューのセットアップとワーカー プロセス サービス
  • 抽象キュー定義 (オプションとしてクラウド サービスの使用を許可するため)
  • メッセージを検索するイベント ループを備えた基本的なワーカー プロセス タイプのサービス
  • docker-compose.deps.yml の RabbitMQ
  • ワーカープロセスサービスに接続された RabbitMQ の基本実装
• 追加のローカル Kubernetes デモ作業
  • ネットワークを調整してホスト DB を公開する方法を理解できない限り、データベースではおそらく kubernetes 永続ボリュームの使用方法を学ぶ必要があります。
  • Seq を追加するか、Seq 機能をオプションにして、kubernetes で実行する場合は使用しないでください。
• ソリューションを分析するためのメタ プロジェクト/スクリプト
  • 変更されたファイルに基づいて影響を受けるサービスを分析する (展開の粒度を高めるため)
• プロジェクトの足場:
  • すべてのプロジェクト/ディレクトリ名に Omega 以外の他のプロジェクト「キー」を使用して、プロジェクトの新しいコピーをスピンアップする機能
  • 新しいプロジェクトで Docker コンテナを起動し、効果的に統合テストを実行して、新しいプロジェクトの作成を確実に成功させる機能

その他

Linux で開発している場合、サーバーの起動時に次のエラーが発生する可能性があります。

System.AggregateException: 1 つ以上のエラーが発生しました。 (inotify インスタンス数に関して設定されたユーザー制限 (128) に達したか、オープン ファイル記述子の数に対するプロセスごとの制限に達しました。)

これは、vscode によって使用されるファイル監視が多すぎることが原因である可能性があります。次のコマンドを実行すると、 inotifyインスタンスの制限 ( /etc/sysctl.confファイルですでに非常に高く設定されている監視制限だけではありません) を増やすことができます。

echo fs.inotify.max_user_instances=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

その他のドキュメント

デザインパターンのコストメリット分析: DesignPatternCostBenefit.md

デザインパターンのバリエーション: DesignPatternvariations.md

決定: Decisions.md

ソフトウェア開発の哲学と発言: https://gist.github.com/mikey-t/3d5d6f0f5316abf9e74fb553be9fdef3