マイクロサービスを実行していると思いますか?いいえ！モノリスよりも悪い分散モノリスを作ってしまいました。

[[387137]]

この記事はWeChatの公開アカウント「Programmer DD」から転載したもので、著者はZhai Yongchaoです。記事を転載する場合はプログラマーDDの公式アカウントまでご連絡ください。

昨夜寝る前に、いくつかのグループチャットのチャット記録を確認しました。 「分散モノマー」という非常に興味深い用語を見つけ、その手がかりをたどって以前のチャット記録を見てみました。内容は罵倒語だらけなので投稿しません。大まかな内容は、ある企業がマイクロサービス化を進めているが、その変革は中途半端なものだというものです。形式的にはマイクロサービスのように見えますが、本質的には依然としてモノリスであり、モノリスよりもさらに悪いものです。

こうした変化の現象は、実は国内ではかなり一般的です。今日は、分散モノマーという興味深いトピックについてお話します。読者の皆様、あなたの会社でもこのようなミスを犯したことがありますか?

分散モノリスがなぜ悪いのか

まず、この質問について考えてみましょう。モノリスからマイクロサービスに変換する場合、次の手順に従いますか?

1. ビジネスドメインを決定し、ストレージを分割し、各マイクロサービスの境界を定義する
2. コードロジックを変更し、元の内部サービス呼び出しをdubboやfeignなどのリモート呼び出しに変更します。

この変革を通じて、次のような多くのメリットが得られました。

1. コードベースが分離されているため、コードの競合を解決する手間が軽減されます。
2. CI/CD が分離されており、各サービスは独立して開発、デプロイ、実行できます。
3. データベースは分離され、独立して実行されるため、異なるビジネス モジュールは互いに影響を及ぼしません。

これらすべての操作を経て、肥大化したモノリシック アプリケーションが複数の洗練された分散アプリケーションに変換されました。変身は完璧に達成されたようですね？しかし、これでマイクロサービスの中心的な目標は達成されたのでしょうか?次の質問について考え続けましょう。

1. コード ベースは分離されていますが、各サービスは独立して反復処理されていますか?各要件には、多数の同期インターフェースの調整が必要ですか?
2. CI/CD は分離されていますが、すべてのリリースは無料ですか?すべての機能リリースには、一緒にリリースされる多くのサービスが含まれますか?
3. データベースは分離されていますが、サービスがダウンしているようで、それでも多くの機能が異常になりますか?

いろいろメリットがあるようですが、本当に開発効率は向上したのでしょうか？以前は 1 つのアプリケーションを起動するのに 3 分かかっていましたが、分割後は 30 分でプロジェクトを開始できるようになりましたが、開発とデバッグごとに複数のプロジェクトを同時に開始する必要がありますか?この開発体験は本当に楽しいですか?

マイクロサービス化が完了したように見えますが、実際はまだ単一のアプリケーションですが、当初の集中型の実装から分散型の実装に変化しています。結局、私たちは無駄な仕事をしただけで、実際の利益はごくわずかだったことがわかりました。

実際のところ、このような変革は、利益が低いことに加え、より多くの不利益をもたらします。あなたの会社がこれを実行している場合、これを実行した後、システム障害の頻度が高くなったように感じますか?安定性は単一アプリケーションよりも悪いようですか? (そうでない場合は、運用保守チームの素晴らしい働きに感謝しなければなりません。同時に、この記事を運用保守チームに転送し、この変革によって彼らがさらに疲れているかどうかを確認するためにインタビューすることをお勧めします。)

なぜそのような変換によってシステムがさらに不安定になるのでしょうか?実は、その理由は非常に単純です。もともと、モノリシック アプリケーションでは、分割されていないリモート呼び出しはすべて内部呼び出しでした。この内部呼び出しによって発生する失敗率はごくわずかでした。この部分をリモート呼び出しに分割した後、各呼び出しにネットワーク IO の要素が追加され、各呼び出しの失敗率が増加しました。その後、システムの同期リモート呼び出しの数に応じて、システム全体の障害率が増加します。運用・保守チームと開発レベルが複雑性の増大に対応できない場合、変換されたシステムの安定性は必然的に元の単一アプリケーションよりも悪くなります。

したがって、このような変革の結果は、多くの利益を得られなくなるだけでなく、安定性の大きな損失ももたらします。

変形の歪みの犯人

では、なぜ上記のような問題が発生するのでしょうか?主な理由は2つあると思います。

1. 不合理なドメイン分割により同期リモート呼び出しが多すぎる

これは最も基本的な問題であり、改修プロセス中に最もよく発生する問題でもあります。正直に言うと、この部分は、ビジネスに対する非常に深い理解と、システム設計とユーザー行動のドメイン モデルに対する十分な理解を必要とするため、変革プロセス全体の中で最も難しい部分です。分割する場合は、同期リモート呼び出しを可能な限り削減し、メッセージを介した非同期対話に置き換えます。同時に、ビジネスニーズに応じて適切なデータ冗長化を実行できます。これにより、分割された各マイクロサービスで結合度を低くすることができます。

結合度が低いため、最適化を行わなくても分散による安定性の損失が少なくなります。後でポイント 2 を実行する作業が少なくなります。同時に、真に自立した開発、展開、運用も可能となります。

2. シンプルで粗雑な実装、分散保護メカニズムの欠如

多くのチームでは、多くのビジネス要求と人員不足の矛盾により、開発者は、インターフェイス プロバイダーの電流制限戦略 (他者による強制終了から自身を保護するため)、インターフェイス呼び出し元の劣化戦略 (ビジネスの高可用性を保護するため)、インターフェイス呼び出し元のサーキット ブレーカー戦略 (他者による強制終了から自身を保護するため) など、リモート呼び出しに対する適切な保護メカニズムを提供できないことがよくあります。分散環境におけるあらゆる依存ポイントを真剣に受け止めることによってのみ、分散変換によって生じる多くの問題を解決することができます。

しかし、これをうまく行うための鍵は、最初のポイントを把握することです。ドメイン モデルでより合理的な分割計画を立てることによってのみ、開発者がこれを適切に実行できるようにサポートできます。そうしないと、分割が恣意的に行われると、すでに大きなプレッシャーを受けている開発者に、大量のインターフェース呼び出しが課せられることになります。そうすると、開発のこの部分の品質を保証することが難しくなり、インターフェースの複雑さが増すにつれて、当然システムの安定性が低下し始めます。最終的に、開発者は私たちのグループ内で不満を言い始めるでしょう...そして、マイクロサービスでは効率性の向上が実現できないのではないかと疑い始める人さえ出てくるでしょう。

最後に、考えてみてください。あなたのマイクロサービスには、ここで述べたような状況がありますか?それとも、他の異なる問題があるのでしょうか?コメントエリアへようこそ。ここであなたの問題について話し合い、あなたの意見を議論しましょう。

オリジナルリンク: https://mp.weixin.qq.com/s/YN4zGzySLMCx3QoT2t4pbA