アプリケーションを複数に分割するが、データベースは同じに保つ
中規模のeコマースアプリケーションがあります。時間の経過とともに、私たちのモノリシックプロジェクトはコードベースの点でかなり重くなりました。私はそのソリューションを調査していたところ、マイクロサービスが1つのオプションであることがわかりましたが、非常に多くのリスクと開発サイクルの増加を伴う非常に初期の最適化のようでした。そこで、モノリシックアプリをビジネスに基づいて複数のアプリに分割することを考えました。私は次の3つを考え出します。
- 店先（ウェブサイト）
- 管理バックエンド（CRM、レポートなど）
- 売り手プラットフォーム
これらの3つの個別のプロジェクトを作成することにより、次のようなメリットがあります。
- それらは独立して開発でき、共通のコードベースが必要な場合はいつでも、現在のプロジェクトにライブラリとして追加できます。 B
- これらのアプリケーションは個別に展開できます。
- アプリケーション間で通信する必要がある場合はいつでも、データを転送するための限られたAPIを作成できます
- 共通のデータベースがあれば、すべての外部キーを保持することでデータの完全な一貫性を保つことができます
そうは言っても、私は次の点について心配しています：
- まず、これは正しいアプローチですか？そこに注意点はありますか？
- 3つのアプリによってアクセスされる共通のデータベースがあり、同様のテーブルに書き込むと、後でスケールに関する問題が発生しますか？
マイクロサービスには、独自の一連の課題があります。あなたが説明しているのは、本質的に Strangler Pattern を使用して古いアプリケーションを置き換えることです。これにはいくつかの利点があります。
- マイクロサービス全体で機能のバランスを正しく取ることができるように、1つの変更に努力を集中します
- 以前に機能していたデータストアを機能させ続ける
ただし、いくつかの制限があります。
- ボトルネックがデータストアになりました
- アプリケーションのスケーリングはデータベースアーキテクチャに限定されます
したがって、必要な変更の複雑さを分割する効果的な方法だと思います。問題は、現在のボトルネックがアプリケーションにとってどこにあるかを理解しているかどうかです。
現在のデータベースアーキテクチャの限界に近づいていない場合は、最初のカットとしてアプローチを使用して電源を入れます。これにより、データの格納方法を気にすることなく、マイクロサービスインフラストラクチャを連携させる複雑さに集中できます。データベースの相互作用を処理する多くの既存のコードを活用できます。
これにより、必要な変更を検討する時間を節約できます。
- アプリケーションを測定して、ボトルネックを理解する
- アーキテクチャを進化させるためのガイドラインとしてdoctrine（マイクロサービスのすべての「ルール」）を使用します
- システムの成長率に対処するために適切な変更を決定します。
要するに、それはすぐに完璧である必要はありません。次の最大の問題が何であるかに焦点を合わせるのに十分である必要があります。マイクロサービスは、モノリシックアプリケーションにはない複雑さをもたらします。ただし、モノリシックアプリにはないインターネット規模で顧客にサービスを提供するという問題は解決されます。
これを適切なマイクロサービスアーキテクチャと見なすには、各アプリにデータ自律性が必要です。それがなくても、データベーススキーマを介してアプリケーション間を結合できます。
ここで本格的なマイクロサービスアプローチが必要かどうかは、決定する必要があります。これはその方向への一歩となる可能性がありますが、マイクロサービスが提供する程度の疎結合はないことを認識する必要があります。データベースは一般的な依存関係です。
共通データベースを維持する利点として、「共通データベースを使用すると、すべての外部キーを保持することでデータの完全な一貫性を保つことができます」と記載されています。真のマイクロサービスモデルに移行するには、データベースに依存しないで一貫性を確保し、別の方法で解決する必要があります。最も簡単なアプローチは、各アプリが他のアプリによって維持されている公開キーをデータベースで追跡することです。基本的には同じですが、DBの制約チェック機能が失われます。
大きなモノリスの問題の解決策を見つけようとしているとのことですが、共有DBを使用して複数のアプリに分割することは悪いアプローチではありませんが、必ずしもマイクロサービスに変換されるわけではありません。
参照： https://martinfowler.com/articles/microservices.html
前述したように、マイクロサービスには他の特性に加えて、データを管理する独自の方法が必要です。 製品ではなく製品について考えてみてください。マイクロサービスは、使用法にとらわれず、1つのことと1つのことだけを実行できる必要があります。したがって、完全に独立しています。マイクロサービスはあなたが探しているものではないかもしれませんが、古き良き[〜＃〜] soa [〜＃〜]：必要なことは、集中型データベースへのゲートウェイとしてのサービス。懸念事項を分離するために、各アプリケーションに独自のバックエンドサービスを持たせることもできます。
また、モノリスから分散システム（特にマイクロサービス）に移行するには、ログから追跡、ユニットテスト、展開戦略、トランザクション、さらにはコード自体の複雑さに至るまで、まったく新しい一連の問題に直面する必要があることに注意してください。 。
他のアプリケーションをデプロイせずに各Webアプリケーションを実際にデプロイできる場合は、それらを個別のアプリケーションに分割することは有益です。 2つ以上のアプリケーションを同時にデプロイする必要がある場合、マイクロサービスアーキテクチャに移行しない理由は、ウェブアプリケーションをデプロイするときに明らかになります。
あなたが言った：
私はそのソリューションを調査していたところ、マイクロサービスが1つのオプションであることがわかりましたが、非常に多くのリスクと開発サイクルの増加を伴う非常に初期の最適化のようでした。
本当に「小さなモノリス」である3つの別個のWebアプリケーションを使用しても、同じ問題が発生します。
あなた コメント ：
はい、言及するのを忘れていました。モバイルアプリ（Android、iOS）向けの現在のウェブアプリにはすでにAPIが組み込まれています。そして新しいデザインに従って、彼らはストアフロントアプリに行きます
すでにiOSとAndroid=アプリケーションがあります。本番環境に入ると、すでに3つのユーザーインターフェースがあります。
- モノリスWebアプリケーション
- Androidアプリ
- iOSアプリ
そして、UIの真のリストを作成する2つのWebユーザーインターフェイスを追加したいとします。
- ストアフロントWebアプリ（管理アプリとの対話）
- 管理Webアプリ
- 販売者のWebアプリ（管理アプリと対話）
- Androidアプリ（ストアフロントアプリと対話）
- iOSアプリ（ストアフロントアプリと通信）
関連するメモとして、すべてのパスは管理Webアプリケーションに戻ります（Androidは店頭に話しかけ、店頭は管理者に話しかけます）。あなたの管理アプリケーションは、3つのパブリックユーザーインターフェース（ウェブ、iOS、Android）から間接的に攻撃されています。管理アプリの復元力を向上させます。
少なくとも、データAPIをユーザーインターフェイスアプリケーションから分離してください。ストアフロントアプリに対してデータのAPI呼び出しを行うということは、すでに大きく、複雑で、絶えず変化するストアフロントアプリケーションがまだあることを意味します詳細変更する理由。
今が複数のデータベースで本格的なマイクロサービスに移行する時ではない場合、いつになるかわかりません。