🥇モノリスからマイクロサービスへの移行: 歴史と実践

この記事では、私が取り組んでいるプロジェクトが大規模なモノリスから一連のマイクロサービスにどのように進化したかについて説明します。

このプロジェクトの歴史は、かなり昔の 2000 年初頭に始まりました。最初のバージョンは Visual Basic 6 で書かれていました。時間の経過とともに、IDE と言語自体の発達が不十分です。 2000 年代後半に、より有望な C# に切り替えることが決定されました。新しいバージョンは古いバージョンのリビジョンと並行して作成され、徐々に .NET で使用されるコードが増えていきました。 C# のバックエンドは当初サービスアーキテクチャに重点を置いていましたが、開発時にはロジックを備えた共通ライブラリが使用され、サービスは単一プロセスで起動されました。その結果、私たちが「サービスモノリス」と呼ぶアプリケーションが誕生しました。

このようなバンドルの数少ない利点の XNUMX つは、サービスが外部 API を通じて相互に呼び出せることです。より正確なサービス、そして将来的にはマイクロサービスアーキテクチャへの移行には、明確な前提条件がありました。

2015年頃から分解作業を開始しました。まだ理想的な状態には達していません。大きなプロジェクトにはモノリスとは言い難い部分もありますが、マイクロサービスにも見えません。ただし、進歩は顕著です。
それについては記事の中でお話します。

既存のソリューションのアーキテクチャと問題点

当初、アーキテクチャは次のように見えました。UI - 別個のアプリケーション、モノリシック部分は Visual Basic 6 で作成され、.NET アプリケーションはかなり大規模なデータベースを操作する一連の関連サービスでした。

以前のソリューションの欠点

単一障害点
単一障害点がありました。.NET アプリケーションが XNUMX つのプロセスで実行されていたのです。いずれかのモジュールが失敗すると、アプリケーション全体が失敗し、再起動する必要がありました。私たちはさまざまなユーザーに対して多数のプロセスを自動化しているため、そのうちの XNUMX つに障害が発生したため、しばらくの間すべてのプロセスが機能しなくなりました。ソフトウェアエラーが発生すると、冗長性も役に立ちませんでした。

改善キュー
この欠点は、より組織的なものです。私たちのアプリケーションには多くの顧客がおり、彼らは皆、できるだけ早くアプリケーションを完成させたいと考えています。以前はこれを並行して行うことは不可能で、すべての顧客が列に並んでいました。このプロセスはビジネスにマイナスをもたらしました。なぜなら、彼らは自分たちの仕事に価値があることを証明する必要があったからです。そして開発チームはこのキューの整理に時間を費やしました。多くの時間と労力がかかり、結果として製品を思うように早く変えることができませんでした。

リソースの次善の利用
単一プロセスでサービスをホストする場合、常にサーバー間で構成を完全にコピーしました。私たちは、リソースを無駄にしないように、また展開スキームをより柔軟に制御できるように、最も負荷の高いサービスを個別に分離したいと考えていました。

最新のテクノロジーを導入するのは難しい
すべての開発者にとってよくある問題です。最新のテクノロジーをプロジェクトに導入したいと考えていますが、その方法がありません。大規模なモノリシックソリューションでは、新しいライブラリへの移行は言うまでもなく、現在のライブラリの更新はかなり簡単な作業になります。これが無駄な神経を費やすよりも多くのボーナスをもたらすことをチームリーダーに証明するには長い時間がかかります。

変更の発行が難しい
これが最も深刻な問題でした。私たちは XNUMX か月ごとにリリースを発行していました。
開発者のテストと努力にもかかわらず、リリースのたびに銀行にとっては大惨事となりました。企業は、週の初めには一部の機能が機能しないことを理解していました。そして開発者たちは、一週間にわたって重大な事件が待っていることを理解していました。
誰もが状況を変えたいという願望を持っていました。

マイクロサービスへの期待

準備ができたらコンポーネントを発行します。ソリューションを分解し、異なるプロセスを分離することで、準備が整ったコンポーネントを発行します。

小規模な製品チーム。古いモノリスに取り組んでいる大規模なチームは管理が困難だったため、これは重要です。このようなチームは厳格なプロセスに従って作業することを強いられましたが、より創造性と独立性を求めていました。小規模なチームだけがそれを買う余裕がありました。

サービスを別のプロセスに分離します。理想的にはコンテナに分離したいのですが、.NET Framework で書かれたサービスの多くは、特定の環境でのみ動作します。 Windows.NET Coreをベースとしたサービスが登場し始めているが、まだ数は少ない。

導入の柔軟性。コードで強制される方法ではなく、必要な方法でサービスを組み合わせたいと考えています。

新しいテクノロジーの使用。これはプログラマにとって興味深いものです。

移行の問題

もちろん、モノリスをマイクロサービスに分割するのが簡単であれば、カンファレンスでそれについて話したり、記事を書いたりする必要はありません。このプロセスには多くの落とし穴がありますが、妨げとなった主な落とし穴について説明します。

最初の問題 ほとんどのモノリスに典型的なものは、ビジネスロジックの接続です。モノリスを作成するときは、余分なコードを書かないようにクラスを再利用したいと考えます。そして、マイクロサービスに移行すると、これが問題になります。すべてのコードが非常に緊密に結合されており、サービスを分離するのが困難です。

作業開始時点では、リポジトリには 500 以上のプロジェクトと 700 万行以上のコードがありました。これは十分に大きな解決策です。 XNUMX番目の問題。それを単純にマイクロサービスに分割することはできませんでした。

XNUMX番目の問題 — 必要なインフラストラクチャの欠如。実際、私たちはソースコードをサーバーに手動でコピーしていました。

モノリスからマイクロサービスに移行する方法

マイクロサービスの割り当て

まず、私たちはマイクロサービスの分離は反復的なプロセスであるとすぐに判断しました。私たちは常にビジネスタスクを並行して開発することが求められてきました。これを技術的にどのように実装するかは、すでに私たちの問題です。したがって、反復プロセスの準備をしました。大規模なアプリケーションがあり、最初は書き換える準備ができていない場合でも、動作は変わりません。

マイクロサービスを分離するにはどのような方法を使用しますか?

第一の方法 - 既存のモジュールをサービスとして取り出す。この点に関して、私たちは幸運でした。WCF プロトコルに従って動作する正式化されたサービスがすでに存在していました。それらは別々のアセンブリに分離されました。私たちはそれらを個別に移植し、各ビルドに小さなランチャーを追加しました。これは、アプリケーションをサービスとしてもコンソールとしても実行できる素晴らしい Topshelf ライブラリを使用して書かれています。ソリューションには追加のプロジェクトが必要ないため、これはデバッグに役立ちます。

サービスは共通のアセンブリを使用し、共通のデータベースで動作するため、ビジネスロジックによって接続されていました。それらを最も純粋な形でマイクロサービスと呼ぶのは困難でした。ただし、これらのサービスを異なるプロセスで個別に発行することもできます。これにより、相互の影響を軽減することがすでに可能になり、並行開発と単一障害点の問題が軽減されます。

ホストアセンブリは、Program クラスのわずか XNUMX 行のコードです。補助授業でトップシェルフの作品を隠しました。

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

マイクロサービスを分離する XNUMX 番目の方法: 新しい問題を解決するためにそれらを作成します。同時にモノリスが成長しない場合、これはすでに優れており、私たちが正しい方向に進んでいることを意味します。新しい問題を解決するために、私たちは別のサービスを作成しようとしました。そのような機会があれば、データモデル、つまり別のデータベースを完全に管理する、より「標準的な」サービスを作成しました。

他の多くの企業と同様に、私たちも認証および認可サービスからスタートしました。彼らはこれに最適です。これらは独立しており、原則として、別個のデータモデルを持っています。それら自体はモノリスと対話せず、問題を解決するためにモノリスを参照するだけです。これらのサービスでは、新しいアーキテクチャへの移行を開始したり、サービス上のインフラストラクチャをデバッグしたり、ネットワークライブラリなどに関連するいくつかのアプローチを試したりすることができます。私たちの組織には認証サービスを作成できないチームはありません。

マイクロサービスを分離する XNUMX 番目の方法私たちが使用しているは、少し特殊なものです。これは、UI レイヤーからビジネスロジックを削除することです。私たちのメインの UI アプリケーションはデスクトップであり、バックエンドと同様に C# で書かれています。開発者は定期的に間違いを犯し、バックエンドに存在して再利用されるべき UI 上のロジックの一部を削除していました。

UI 部分のコードの実際の例を見ると、このソリューションのほとんどに実際のビジネスロジックが含まれていることがわかります。これは、UI フォームの構築だけでなく、他のプロセスでも役立ちます。

実際の UI ロジックは最後の数行だけです。それを再利用できるようにサーバーに転送することで、UI を削減し、正しいアーキテクチャを実現しました。

XNUMX 番目、マイクロサービスを分離する最も重要な方法モノリスを削減できるようにする、処理を伴う既存のサービスの削除です。既存のモジュールをそのまま取り出すと、開発者が必ずしもその結果を気に入るとは限らず、機能の作成時からビジネスプロセスが古くなってしまう可能性があります。ビジネス要件は常に変化するため、リファクタリングを通じて新しいビジネスプロセスをサポートできます。ソースコードを改善し、既知の欠陥を削除し、より良いデータモデルを作成できます。得られるメリットはたくさんあります。

リワークによるサービスの分離は、境界付きコンテキストの概念と密接に関連しています。これはドメイン指向設計の概念です。これは、単一言語のすべての用語が一意に定義されているドメインモデルのセクションを意味します。例として、保険と請求書のコンテキストを考えてみましょう。私たちはモノリシックなアプリケーションを持っており、保険のアカウントを操作する必要があります。開発者が別のアセンブリで既存の Account クラスを見つけて、Insurance クラスからそれを参照することを期待します。そうすれば、機能するコードが得られます。 DRY 原則が遵守され、既存のコードを使用することでタスクがより高速に実行されます。

その結果、口座と保険の文脈はつながっていることが分かりました。新しい要件が発生すると、この関係によって開発が妨げられ、すでに複雑なビジネスロジックがさらに複雑になります。この問題を解決するには、コード内のコンテキスト間の境界を見つけて、その違反を削除する必要があります。たとえば、保険の場合、中央銀行口座の 20 桁の番号と口座開設日で十分である可能性が十分にあります。

これらの制限されたコンテキストを互いに分離し、モノリシックソリューションからマイクロサービスを抽出するプロセスを開始するために、アプリケーション内に外部 API を作成するなどのアプローチを使用しました。一部のモジュールがマイクロサービスになり、プロセス内で何らかの変更が必要であることがわかっている場合は、外部呼び出しを通じて、別の限定されたコンテキストに属するロジックをすぐに呼び出します。たとえば、REST または WCF を使用します。

私たちは、分散トランザクションを必要とするコードを避けないと強く決意しました。私たちの場合、このルールに従うのは非常に簡単であることがわかりました。これまでのところ、ハード分散トランザクションが本当に必要な状況には遭遇していません。モジュール間の最終的な整合性は十分です。

具体的な例を考えてみましょう。オーケストレーターという概念があります。これは、「アプリケーション」の本質を処理するパイプラインです。彼は、クライアント、アカウント、銀行カードを順番に作成します。クライアントとアカウントは正常に作成されたが、カードの作成が失敗した場合、アプリケーションは「成功」ステータスにならず、「カードが作成されていません」ステータスのままになります。将来的には、バックグラウンドアクティビティがそれを取得して終了する予定です。このシステムはしばらくの間一貫性のない状態にありましたが、私たちはこれに概ね満足しています。

それでも、データの一部を継続的に保存する必要がある状況が発生した場合、これを XNUMX つのプロセスで処理するためにサービスの拡張を行う可能性が高くなります。

マイクロサービスを割り当てる例を考えてみましょう。比較的安全に本番環境に導入するにはどうすればよいでしょうか? この例では、システムの別の部分、つまり給与サービスモジュールがあり、マイクロサービスを作成したいコードセクションの XNUMX つです。

まずはコードを書き換えてマイクロサービスを作成します。合わなかった点を改善していきます。お客様からの新しいビジネス要件を実装します。 UI と API Gateway バックエンドの間のバンドルに追加して、通話の転送を提供します。

次に、この構成をリリースして運用しますが、これはパイロット状態です。ユーザーのほとんどは依然として古いビジネスプロセスを使用しています。新規ユーザー向けに、このプロセスには含まれていないモノリシックアプリケーションの新しいバージョンを開発しています。実際、パイロットの形で動作するモノリスとマイクロサービスが多数あります。

パイロットが成功すると、新しい構成が実際に機能することがわかり、方程式から古いモノリスを削除して、古いソリューションの代わりに新しい構成を残すことができます。

合計すると、モノリスのソースコードを分離するために、ほぼすべての既存の方法を使用します。これらのすべてを使用すると、アプリケーションの一部のサイズを削減し、それらを新しいライブラリに変換して、より良いソースコードを作成できます。

データベースの操作

データベースには現在のスキーマだけでなく、蓄積された履歴データも含まれるため、ソースコードよりも分離しにくいです。

他の多くのデータベースと同様、私たちのデータベースには、サイズが巨大であるというもう XNUMX つの重要な欠点がありました。このデータベースはモノリスの複雑なビジネスロジックに従って設計されており、さまざまな限定されたコンテキストのテーブル間に関係が蓄積されています。

私たちの場合、すべての問題 (大規模なデータベース、多数のリレーションシップ、場合によってはテーブル間の理解できない境界) に加えて、多くの大規模プロジェクトで発生する問題、つまり共有データベースパターンの使用が発生しました。データはビュー、レプリケーションを通じてテーブルから取得され、このレプリケーションが必要な他のシステムに送信されました。その結果、テーブルはアクティブに使用されていたため、テーブルを別のスキーマに移動できませんでした。

分割では、コード内の限られたコンテキストへの分割自体が役に立ちます。通常、データベースレベルでデータをどのように分割するかについて、かなり良いアイデアが得られます。どのテーブルが XNUMX つの制限されたコンテキストに属し、どのテーブルが別のコンテキストに属するかを理解します。

データベースを分割するために、既存のテーブルの分割と処理を伴う分割という XNUMX つのグローバルな方法を適用しました。

データ構造が良好でビジネス要件を満たし、全員がそれに満足している場合は、既存のテーブルを分離することをお勧めします。この場合、既存のテーブルを別のスキーマに割り当てることができます。

ビジネスモデルが大きく変化し、テーブルではまったく満足できなくなった場合には、処理を伴う分岐が必要になります。

既存のテーブルの分離。 何を分離するのかを決める必要があります。この知識がなければ何も機能せず、コード内の限られたコンテキストを分離することがここで役に立ちます。一般に、ソースコード内のコンテキストの境界を理解できれば、どのテーブルを分離のリストに含めるべきかが明確になります。

XNUMX つのモノリスモジュールが同じデータベースと対話するソリューションがあると想像してください。 XNUMX つのモジュールだけが分割されたテーブルのセクションと対話し、もう XNUMX つのモジュールが API を介して対話を開始することを確認する必要があります。まずはAPI経由で録音だけを行えば十分です。これは、マイクロサービスの独立性について話すために必要な条件です。大きな問題がない限り、既読リンクはそのままでも構いません。

次のステップとして、処理の有無にかかわらず、取り外し可能なテーブルを操作するコードのセクションを別のマイクロサービスに分離し、別のプロセスであるコンテナーで実行することができます。これは、モノリスデータベースとそれに直接関係しないテーブルへの接続を備えた別個のサービスになります。モノリスは、読み取りのために取り外し可能な部分と依然として相互作用します。

後で、この接続を削除します。つまり、モノリシックアプリケーションデータの読み取りも、デタッチされたテーブルから API に転送します。

次に、新しいマイクロサービスのみが動作する共通データベースからテーブルを選択します。テーブルを別のスキーマ、または別の物理データベースに移動することもできます。マイクロサービスとモノリスデータベースの間には読み取り用の接続が残りますが、この構成では長期間存続できるため、心配する必要はありません。

最後のステップは、すべてのリンクを完全に削除することです。この場合、メインデータベースからデータを移行する必要がある場合があります。場合によっては、外部システムから複製された一部のデータまたはディレクトリを複数のデータベースで再利用したいことがあります。時々これがあります。

加工部門。 この方法は最初の方法と非常によく似ていますが、手順が逆である点が異なります。新しいデータベースと、API を介してモノリスと対話する新しいマイクロサービスがすぐに完成しました。ただし、これにより、将来削除する必要があるデータベーステーブルのセットが残ります。不要になりましたので、新しいモデルに交換しました。

この計画が機能するためには、おそらく移行期間が必要になるでしょう。

次に、考えられるアプローチは XNUMX つあります。

最初の: 新しいデータベースと古いデータベースのすべてのデータを複製します。この場合、データの冗長性はありますが、同期に問題が発生する可能性があります。ただし、XNUMX つの異なるクライアントを受け入れることができます。 XNUMX つは新しいバージョンで動作し、もう XNUMX つは古いバージョンで動作します。

2番目の: 何らかのビジネス属性に従ってデータを分割します。たとえば、システム内に 5 つの製品があり、それらは古いデータベースに保存されていました。 XNUMX 番目は、新しいビジネスタスクのフレームワーク内で、新しいデータベースに配置します。ただし、このデータを同期し、クライアントにどこに何を取るべきかを示す API ゲートウェイが必要です。

どちらのアプローチも機能しますので、状況に応じて選択してください。

すべてが動作することを確認したら、古いデータベース構造で動作するモノリスの部分を無効にすることができます。

最後のステップは、古いデータ構造を削除することです。

まとめると、データベースには問題があると言えます。ソースコードに比べてデータベースを操作するのは難しく、分離するのはより困難ですが、それは可能であり、そうすべきです。これを非常に安全に実行できる方法をいくつか見つけましたが、ソースコードよりもデータのほうが間違いを犯しやすいのです。

ソースコードの操作

これは、モノリシックプロジェクトの分析を開始したときのソースコード図の様子です。

条件付きで10つの層に分けることができます。これは、実行モジュール、プラグイン、サービス、および個々のアクティビティのレイヤーです。実際、これらはモノリシックソリューション内のエントリポイントでした。それらはすべて共通層でしっかりと固定されていました。これには、サービスと多くの関係間で共有されるビジネスロジックがありました。各サービスとプラグインは、そのサイズと開発者の良心に応じて、最大 XNUMX 個以上の共通アセンブリを使用しました。

幸運だったのは、個別に使用できるインフラストラクチャライブラリがあったことです。

場合によっては、一部の Common オブジェクトが実際にはこのレイヤーに属しておらず、インフラストラクチャライブラリであるという状況が発生することがありました。これは名前を変更することで解決されました。

コンテキストの境界が最大の懸念事項でした。たまたま 3 ～ 4 つのコンテキストが XNUMX つの共通アセンブリ内に混在し、同じビジネス機能内で相互に使用されていました。どこで、どの境界に沿って分割できるのか、そしてこの分割をソースコードアセンブリにマッピングして次に何をすべきかを理解する必要がありました。

コード分割プロセスに関していくつかのルールを策定しました。

最初の: サービス、アクティビティ、プラグイン間でビジネスロジックを共有したくなくなりました。私たちは、マイクロサービス内でビジネスロジックを独立させたいと考えていました。一方、マイクロサービスは、理想的には、完全に独立して存在するサービスとして認識されます。このアプローチは、いくらか無駄があり、実現が難しいと思います。なぜなら、たとえば、C# サービスはどのみち標準ライブラリによって接続されるからです。私たちのシステムは C# で書かれており、他のテクノロジーはまだ使用されていません。したがって、一般的な技術ビルドを使用する余裕があると判断しました。重要なことは、ビジネスロジックの断片が含まれていないことです。使用している ORM に優れたラッパーがある場合、それをサービス間でコピーするのは非常にコストがかかります。

私たちのチームはドメイン指向の設計のファンなので、オニオンアーキテクチャは私たちにぴったりでした。私たちのサービスの基礎はデータアクセス層ではなく、ビジネスロジックのみを含み、インフラストラクチャへのリンクが含まれていないドメインロジックを備えたアセンブリでした。同時に、ドメインアセンブリを独自に調整して、フレームワークに関連する問題を解決できます。

この段階で、最初の重大な問題に遭遇しました。サービスは XNUMX つのドメインアセンブリを参照する必要があり、ロジックを独立させたかったのですが、ここでは DRY 原則が邪魔をしました。開発者は重複を避けるために隣接するアセンブリのクラスを再利用したいと考え、その結果、ドメインは再び相互に通信するようになりました。私たちは結果を分析し、おそらく問題はソースコードリポジトリデバイスの領域にもあると判断しました。すべてのソースコードを含む大規模なリポジトリがありました。プロジェクト全体のソリューションをローカルマシン上に構築するのは非常に困難でした。したがって、プロジェクトの一部に対して個別の小さなソリューションが作成され、それらに共通またはドメインアセンブリを追加して再利用することを禁じる人はいませんでした。これを実現できなかった唯一のツールはレビューコードでした。しかし、時々彼は失敗することもありました。

その後、個別のリポジトリを持つモデルへの移行を開始しました。ビジネスロジックがサービスからサービスへ流れることはなくなり、ドメインは実際に独立しました。境界付きコンテキストがより明示的にサポートされます。インフラストラクチャライブラリを再利用するにはどうすればよいでしょうか? それらを別のリポジトリに分離し、Nuget パッケージに入れて Artifactory に入れました。変更を加えると、アセンブリと公開が自動的に行われます。

私たちのサービスは、外部インフラストラクチャパッケージと同じように内部インフラストラクチャパッケージを参照するようになりました。 Nuget から外部ライブラリをダウンロードします。これらのパッケージを配置する Artifactory で作業するために、XNUMX つのパッケージマネージャーを使用しました。小規模なリポジトリでは、Nuget も使用しました。複数のサービスを含むリポジトリでは、モジュール間のバージョンの一貫性を高めるパケットを使用しました。

したがって、ソースコードに取り組み、アーキテクチャをわずかに変更し、リポジトリを分離することで、サービスの独立性を高めます。

インフラストラクチャの問題

マイクロサービスへの移行の欠点のほとんどは、インフラストラクチャに関係しています。自動展開が必要になり、インフラストラクチャを実行するには新しいライブラリが必要になります。

環境への手動インストール

最初に、ソリューションを環境に手動でインストールしました。このプロセスを自動化するために、CI/CD パイプラインを作成しました。ビジネスプロセスの観点からは、継続的デプロイメントが依然として受け入れられないため、継続的デリバリープロセスを選択しました。したがって、操作への送信はボタンによって実行され、テストのために自動的に実行されます。

ソースストレージには Atlassian、Bitbucket、ビルドには Bamboo を使用しています。同じ C# であるため、私たちは Cake でビルドスクリプトを書くことを好みます。既製のパッケージが Artifactory に提供され、Ansible が自動的にテストサーバーにアクセスし、すぐにテストできるようになります。

個別のロギング

かつて、モノリスのアイデアの XNUMX つは、共有ログを提供することでした。また、ディスク上にある個々のログをどう処理するかを理解する必要もありました。ログはテキストファイルに書き込まれます。標準の ELK スタックを使用することにしました。私たちはプロバイダーを通じて ELK に直接書き込みませんでしたが、テキストログを完成させ、トレース ID を識別子として書き込み、これらのログを解析できるようにサービス名を追加することにしました。

Filebeatを使用すると、ログを収集できます。サーバーを変換し、Kibanaを使ってUIでクエリを作成し、サービス間で呼び出しがどのようにルーティングされたかを確認します。トレースIDは、この際に非常に役立ちます。

私たちは何を達成できたのでしょうか?

まず、「リリース」という概念をなくしました。この巨大なリリースが運用環境にデプロイされると、1,5 か月にわたる巨大なリリースがなくなり、ビジネスプロセスがしばらく中断されました。現在では、承認後に運用が開始されるため、サービスをグループ化して平均 XNUMX 日ごとにデプロイしています。

私たちのシステムには致命的なクラッシュはありません。バグのあるマイクロサービスをリリースした場合、それに関連付けられた機能は壊れますが、他のすべての機能は影響を受けません。これにより、ユーザーエクスペリエンスが大幅に向上します。

導入スキームを制御できます。必要に応じて、サービスのグループをソリューションの残りの部分から個別に分離できます。

さらに、大規模な改善待ちの問題を大幅に軽減しました。当社には、一部のサービスを独立して扱う個別の製品チームがあります。ここでスクラムプロセスが役に立ちます。特定のチームには、タスクを割り当てる別の製品所有者がいる場合があります。

まとめ

マイクロサービスは、複雑なシステムを分解するのに適しています。その過程で、私たちはシステムの中に何があるか、限定されたコンテキストとは何か、その境界はどこにあるのかを理解し始めます。これにより、改善をモジュールに適切に配布し、コードの難読化を防ぐことができます。
マイクロサービスは組織にメリットをもたらします。多くの場合、それらは単にアーキテクチャとして参照されますが、どのようなアーキテクチャもビジネスニーズを解決するために必要であり、それ自体ではありません。したがって、現在スクラムが非常に人気があることを考えると、マイクロサービスは小規模なチームで問題を解決するのに適していると言えます。
分離は反復的なプロセスです。アプリケーションを単にマイクロサービスに分割することはできません。結果として得られる製品は、実用的ではない可能性があります。マイクロサービスを強調する場合、既存のレガシーを書き直すこと、つまり、機能と速度の点でビジネスのニーズをよりよく満たす、好みのコードに変えることが有益です。
ちょっとした注意点: マイクロサービスへの移行にはかなりのコストがかかります。インフラの問題を解決するには長い時間がかかりました。したがって、特定のスケーリングを必要としない小規模なアプリケーションを使用していて、チームの注目と時間を争う多数の顧客がいない場合、おそらくマイクロサービスは今日必要なものではないでしょう。かなり高価です。マイクロサービスでプロセスを開始すると、同じプロジェクトをモノリスの開発から開始する場合よりも、最初のコストが高くなります。
PS より感情的な物語 (そしてあなた個人に対するものであるかのように) - by リンク.
レポートの完全版はこちらです。

出所： habr.com

モノリスからマイクロサービスへの移行: 歴史と実践