分散データ管理-データベースをマイクロサービスにカプセル化
私は最近ソフトウェア設計のコースを受講しており、サービスのコンポーネントが可能な限り独立したマイクロサービスサブコンポーネントに分離される「マイクロサービス」モデルの使用について最近の議論/推奨がありました。
言及された部分の1つは、すべてのマイクロサービスが通信する単一のデータベースを持つという非常によく見られるモデルに従うのではなく、マイクロサービスごとに個別のデータベースを実行することです。
これのより適切な言葉でより詳細な説明は、ここにあります： http://martinfowler.com/articles/microservices.html セクションの分散データ管理
これを言っている最も顕著な部分：
マイクロサービスは、各サービスが独自のデータベース、同じデータベーステクノロジーの異なるインスタンス、または完全に異なるデータベースシステムのいずれかを管理できるようにすることを好みます。これは、Polyglot Persistenceと呼ばれるアプローチです。モノリスでポリグロット永続性を使用できますが、マイクロサービスでより頻繁に表示されます。
図4
私はこのコンセプトが好きです。とりわけ、メンテナンスと、複数の人が取り組んでいるプロジェクトの強力な改善としてそれがわかります。とはいえ、私は決して経験ソフトウェアアーキテクトではありません。誰かがそれを実装しようとしたことがありますか？どのようなメリットとハードルに遭遇しましたか？
マイクロサービスアプローチの良い点と悪い点について話しましょう。
最初のネガ。マイクロサービスを作成すると、コードに本質的な複雑さが加わります。あなたはオーバーヘッドを追加しています。あなたは環境を複製することを難しくしています（例えば開発者のために）。断続的な問題のデバッグを難しくしています。
本当の欠点を説明しましょう。ページの生成中に100個のマイクロサービスが呼び出され、それぞれが99.9％の確率で正しい動作を行うケースを想定します。しかし、0.05％の確率で間違った結果が生成されます。そして、0.05％の時間で、接続に低速の接続要求があり、たとえば、接続にTCP/IPタイムアウトが必要であり、5秒かかります。リクエストの約90.5％が完全に機能します。しかし、約5％の時間で間違った結果が生じ、約5％の時間でページが遅くなります。また、再現不可能な障害にはそれぞれ異なる原因があります。
監視、再現などのためのツールについて多くのことを考えないと、これは混乱につながります。特に、あるマイクロサービスが別のマイクロサービスを呼び出し、別のマイクロサービスが数層の深さを呼び出す場合。また、問題が発生すると、時間の経過とともに悪化します。
OK、これは悪夢のように聞こえます（そして、複数の会社がこの道を進むことによって彼ら自身に大きな問題を引き起こしました）。成功は、潜在的なマイナス面を明確に認識し、一貫してそれに取り組むためにのみ可能です。
では、一体型のアプローチはどうでしょうか？
モノリシックアプリケーションは、マイクロサービスと同じくらい簡単にモジュール化できます。また、関数呼び出しは、RPC呼び出しよりも実際には安価で信頼性が高くなります。したがって、信頼性が高く、実行速度が速く、コードが少なくて済むことを除いて、同じものを開発できます。
では、なぜ企業はマイクロサービスアプローチを採用するのでしょうか。
答えは、スケーリングするにつれて、モノリシックアプリケーションで実行できることには限界があるためです。非常に多くのユーザー、非常に多くのリクエストなどを処理すると、データベースがスケーリングされなくなったり、Webサーバーがコードをメモリに保持できなくなったりするなどの問題が発生します。さらに、マイクロサービスアプローチは、アプリケーションの独立した増分アップグレードを可能にします。したがって、マイクロサービスアーキテクチャは、アプリケーションをスケーリングするためのソリューションです。
私の経験則では、スクリプト言語（Pythonなど）のコードから最適化されたC++に変更すると、パフォーマンスとメモリ使用量の両方で1〜2桁の改善が見込めます。別の方法で分散アーキテクチャに移行すると、リソース要件が大幅に増加しますが、無制限にスケーリングできます。分散アーキテクチャを機能させることはできますが、そうするのはより困難です。
したがって、私が個人的なプロジェクトを始めているなら、一枚岩にしてください。それをうまく行う方法を学びましょう。 （Google | eBay | Amazon | etc）は配布されているため、配布しないでください。流通している大企業に上陸する場合は、彼らがどのように機能するかを細心の注意を払い、それを台無しにしないでください。そして、移行をしなければならなくなった場合は、非常に、非常に慎重になるようにしてください。
開示、私はあらゆる規模の企業で20年近くの経験があります。そして、はい、モノリシックアーキテクチャと分散型アーキテクチャの両方を間近で個人的に見てきました。その経験に基づいて、分散マイクロサービスアーキテクチャは本当に必要なために実行するものであり、なんらかの方法でよりクリーンで優れているためではないことを説明しています。
私は心からbtillyの回答に同意しますが、マイクロサービスにもう1つのポジティブな点を加えたかったのです。
マイクロサービスの世界では、サービスはドメインに揃えられ、別々のチームによって管理されます（1つのチームが複数のサービスを管理する場合があります）。これは、各チームが他のサービスとは完全に別々に独立してサービスをリリースできることを意味します（正しいバージョン管理を前提としています）。
これは些細な利点のように思えるかもしれませんが、モノリシックな世界ではその逆を検討してください。ここで、アプリケーションの一部を頻繁に更新する必要がある場合、それはプロジェクト全体と、それに取り組んでいる他のチームに影響を与えます。次に、スケジュールやレビューなどを導入する必要があり、プロセス全体が遅くなります。
選択については、スケーリング要件を検討するだけでなく、必要なチーム構造も検討してください。モノリシックを開始し、後でマイクロサービスが有益になる可能性がある場所を特定するというbtillyの推奨に同意しますが、メリットはスケーラビリティだけではないことに注意してください。
私はかなりの量の独立したデータソースがある場所で働いていました。それらはすべて単一のデータベースに入れましたが、Webサービスによってアクセスされる異なるスキーマに入れました。各サービスは、作業を実行するために必要な最小限のデータにしかアクセスできないという考えでした。
モノリシックデータベースに比べてオーバーヘッドはそれほど大きくありませんでしたが、これは主に、既に分離されたグループに含まれていたデータの性質によるものだと思います。
Webサービスは、ページを生成したWebサーバーコードから呼び出されたため、マイクロサービスアーキテクチャによく似ていますが、Wordが示唆するほどマイクロではなく、配布されなかった可能性もあります（1つのWSが呼び出したことに注意してください）サードパーティのサービスからデータを取得するため、分散データサービスのインスタンスが1つありました）。これを行った会社は規模よりもセキュリティに関心がありましたが、これらのサービスとデータサービスは、1つの脆弱性が悪用されてもシステム全体への完全なアクセス権が付与されないという点で、より安全な攻撃面を提供しました。
彼の優れたObjectwatchニュースレターのRoger Sessionsは、彼のSoftware Fortressesのコンセプトと同様のことを説明しました（残念ながら、ニュースレターはオンラインではなくなりましたが、彼の本を購入できます）。