モノリスのスケーリングとマイクロサービスのスケーリング

マイクロサービスを使用するための一般的な議論の1つは、スケーラビリティの向上です。しかし、私はこの議論が本当に有効かどうか疑問に思います。

10個のマイクロサービスで構成されるアプリケーションがあり、そのうちの9個がそれぞれ2つのインスタンス（冗長性のため）を持ち、そのうちの1つが負荷を処理する4つのインスタンス（スケーラビリティー）を持つとします。この場合、マイクロサービスの賛成論は、このmiroserviceを他のサービスとは無関係にスケーリングできるということです。

ただし、10個のマイクロサービスすべてが単一のモノリスのモジュールであり、このモノリスのいくつかのインスタンス（たとえば上記の合計のような22個）がデプロイされたとしましょう。システムは、1つの重要な部分の負荷を処理できる必要があります。そうするのに十分なインスタンスがあるためです。インスタンスに不要なプログラムロジックが含まれている場合、唯一の欠点は、バイナリと必要なRAMの量がわずかに大きくなることです。しかし、この場合も、ほとんどの場合、差はあまり大きくないはずです-少なくともスタックの残りの部分と比較してはなりません（Spring Bootを考えてください）。スケーリングされたモノリスの利点は、分散システムの（ほとんど）誤りを伴わないシンプルなシステムになります。

何か不足していますか？

マイクロサービスのポイントは、プロセッサーの負荷を減らすことではありません。実際、以前はグローバルユーティリティコードであった通信のオーバーヘッドと機能の繰り返しのため、通常はプロセッサの負荷がいくらか増加します。

モノリスを廃止するポイントは、機能の複雑なシステムをまったく維持、展開、実行できることです。システムが一定のサイズに達すると、コンパイル、テスト、デプロイなどが行われますが、モノリスは高価になりすぎて、適切な稼働時間を維持できません。マイクロサービスを使用すると、システムの断片をアップグレード、再起動、またはロールバックできます。

ミスをしないでください。マイクロサービスはリモートインターフェイスを介して疎結合するための本質的に優れたソリューションであるため、マイクロサービスを作成しません。実際、モノリスが提供できる強力な型と一貫性チェックの喪失は、しばしば大きな欠点です。我々はので、それを行う我々がしなければならない複雑さが私たちのより良いを得ているため、と次善の状況のベストを作っています。

あなたはほとんど正しいです。均等にロードされるクイックサービスがある場合は、すべてのボックスにそれらをすべてインストールすることもできます。サービスごとにボックスを用意するほど「素敵」ではありませんが、お金を節約できます。

しかしながら。サービス5がCPUの100％を2分間使用すると言うアンバランスが発生したら、他のすべてのサービスが実行されてもブロックされないように、そのサービスを専用のボックスに移動します。

ロードのためにサービス5への呼び出しがタイムアウトした場合、すべてではなくアプリの一部の機能のみが失敗します。

これで、モジュール化されたモノリスでも同じことができます。すべてのサービスをインストールしますが、そのうちの1つにサービス5トラフィックのみをルーティングします。サービス5のトラフィックを他のボックスにルーティングしない間。

しかし、通常、モノリスはその性質上、同じボックスにインストールされるサービスのゆるいコレクションではありません。モジュール間でメモリ内の呼び出しが発生し、アプリのエラーが発生します。

マイクロサービスのポイントは、1）関心の分離と2）負荷の分散です。基本的に、これにより、そのタスクに固有のテクノロジーを使用してできる限り最高のブラックボックスサービスを作成できます。私たちのサービスは多言語であり得ます-それは異なるスタック上の異なるプログラミング言語で書かれています。APIの契約を超えて他のチームがどのように機能するかを知らなくても、さまざまなチームが各サービスに取り組むことができます。これを全体として考えると、パフォーマンスをデバッグ、理解、および調整しやすい、各サービスのコードベースがはるかに単純になります。