[マイクロサービス設計] を読む (4) モノリシックシステムを分解する

1. 継ぎ目を特定します (境界のあるコンテキスト)

モノリシックシステムには高い凝集性と低い結合性という特性がないため、分解の最初のステップは非常に慎重である必要があります。最初のステップは継ぎ目の位置を特定することです。コードの比較的独立した部分を抽出できます。継ぎ目を削除してこの部分を変更します。システムの他の部分には影響を与えず、コードベースをクリーンアップしてサービスの境界になる可能性があります。

多くのプログラミング言語には名前空間の概念があり、類似したコードをまとめて整理するのに役立ちます。たとえば、Python/Java/Go にはパッケージの概念があります。境界のあるコンテキストを認識すると、pkg を通じてそれらを個別に維持できます。

2. より効率的な分解

より大きなモノリシックシステムを分解する場合は、分解されたコードの優先順位付けを行う必要があります。

次の開発タスクが在庫システムの場合、次のステップは、在庫の継ぎ目をサービスとして抽出し、自律的なユニットにすることです。これにより、後の開発速度が大幅に向上します。
チーム構造。システムが異なるチームによって保守されている場合、単一のチームがコードベースに対して全責任を負えるように、チームごとに独立したサービスに優先順位を付けることをお勧めします。
セキュリティの面では、特定のシステムが金融関連インターフェースのセキュリティ監査と送信データ保護対策を実装する場合、このサービスを分離すると、より適切な監視、送信データ保護、静的データ保護などが可能になります。
技術的には、レコメンダシステムチームが新しいアルゴリズム（別言語）を開発する場合、この部分のコードを分離できれば、問題があった時のリファクタリングやテストが容易になります。

3. 静的データを共有する

システムが国リストデータを使用したい場合、マイクロサービスアーキテクチャでそれを共有する方法がいくつかあります。

データはデータベース内のテーブルに書き込まれ、すべてのサービスがこのテーブルを直接読み取ります。
データを別のサービスの静的ファイルに配置し、他のサービスがこのサービスによって提供されるインターフェイスを呼び出して読み取ります。

1 番目の方法は変更するときに不便です 2 番目の方法の方が合理的だと思います更新時にサービスの静的ファイルを変更するだけで済みますサービスコードは更新されないため、他のサービスは pkg 情報を更新する必要がありません. .

ここで、静的ファイルを更新する具体的な方法について疑問があるかもしれません。これは、静的ファイルを /static ディレクトリに配置し、countries_202006270920.txt という名前を付ける方法です。その後ろの数字は変更時刻です。更新するときは、最新の変更時刻を持つファイルは /static ディレクトリに配置され、サービスは読み取り時に最新のファイルを読み取ります。

4. テーブルを共有しないようにする

通常、複数のサービスは、ユーザーがメンバーであるかどうか、ログアウトするかどうかなどのユーザーの情報を読み取る必要があります。最善の方法は、独立したユーザーにサービスを提供することです。他のサービスは、このサービスによって提供されるインターフェイスを呼び出して、リソースを分離し、単一責任の原則を実践します。

5. データベースのリファクタリング

このステップでは分離を実装しますが、あるリリースでモノリシックシステムを直接 2 つのサービスに変えるにはどうすればよいと思いますか? そして、彼らは独自のデータベーステーブルを持っているのでしょうか？

実際、現時点ではサービスを分離せずに、まずデータベース構造を分離することをお勧めします。

テーブルが分離された後は、元のアクションでデータベースへのアクセス数が増加する可能性があります。これは、以前はすべてのデータを取得するために 1 回の SELECT だけが必要でしたが、現在は別の場所からデータを取得して保存する必要があるためです。メモリ内接続。また、2 つのテーブル構造に分割するとトランザクションの整合性が損なわれる可能性があり、アプリケーションに重大な影響を与える可能性があります。これについては後で説明します。サービスを切り離さずに最初にデータベース構造を切り離す利点は、サービスの利用者に影響を与えることなく、いつでもこれらの変更をロールバックするか、ロールバックを継続するかを選択できることです。データベースの分離に満足したら、サービス全体の分割を検討できます。

6. マイクロサービスでのデータの一貫性

残念ながら、著者がこの部分に関してより実現可能な解決策を提案したのを見たことがありません。この本では 2 つの方法が説明されています。

補償トランザクションまたは操作はすぐに再試行されるか、スケジュールされたタスクを通じてデータベースの不整合を定期的にチェックして除去されますが、補償トランザクションには失敗する可能性があり、同期する必要がある操作が 2 つ、3 つ、またはそれ以上ある時限タスクは非常に困難です理解するのが難しく、後のメンテナンスにとっては悪夢となる可能性があります。
分散トランザクション。システム内で実行されているトランザクションを均一に調整するために集中トランザクションマネージャーツールが必要です。著者が言及したアルゴリズムの 1 つは 2 フェーズコミットであり、トランザクションマネージャーに単一障害点があり、投票後のコミットが失敗する可能性があるなど、このアルゴリズムの多くの欠点についても言及しました。

このテーマについては、引き続き探究する必要があると思います。