分散データ管理-データベースをマイクロサービスにカプセル化する[終了]

私は最近ソフトウェア設計のコースを受講しており、サービスのコンポーネントが可能な限り独立したマイクロサービスサブコンポーネントに分離される「マイクロサービス」モデルの使用について、最近の議論/推奨がありました。

言及された部分の1つは、すべてのマイクロサービスが通信する単一のデータベースを持つという非常によく見られるモデルに従うのではなく、マイクロサービスごとに個別のデータベースを実行することでした。

これについてのより適切な言葉で詳細な説明は、http：//martinfowler.com/articles/microservices.htmlの分散型データ管理セクションにあります 。

これを言っている最も顕著な部分：

マイクロサービスは、各サービスが独自のデータベース、同じデータベーステクノロジーの異なるインスタンス、または完全に異なるデータベースシステムを管理できるようにすることを好みます-Polyglot Persistenceと呼ばれるアプローチ。モノリスでポリグロット永続化を使用できますが、マイクロサービスではより頻繁に表示されます。

図4

私はこの概念が好きで、他の多くのことの中でも、保守と複数の人が取り組んでいるプロジェクトの強力な改善と考えています。とはいえ、私は決して経験のあるソフトウェアアーキテクトではありません。誰もそれを実装しようとしましたか？どのようなメリットとハードルに遭遇しましたか？

マイクロサービスアプローチの長所と短所について話しましょう。

最初のネガ。マイクロサービスを作成すると、コードに固有の複雑さが追加されます。オーバーヘッドを追加しています。環境の複製を難しくしています（開発者向けなど）。断続的な問題のデバッグを難しくしています。

本当の欠点を説明させてください。仮説として、ページの生成中に100個のマイクロサービスが呼び出され、それぞれが99.9％の時間で正しいことを行う場合を考えてください。しかし、0.05％の確率で誤った結果が生じます。また、接続にTCP / IPタイムアウトが必要な場合など、接続要求が遅くなる時間の0.05％には5秒かかります。リクエストが完全に機能する時間の約90.5％。しかし、間違った結果が出る時間の約5％、ページが遅い時間の約5％です。そして、再現不可能な障害にはそれぞれ異なる原因があります。

監視、再現などのツールについて多くのことを考えない限り、これは混乱に変わります。特に、あるマイクロサービスが別のマイクロサービスを呼び出し、それが別のマイクロサービスを数層深く呼び出す場合。そして、問題が発生すると、時間とともに悪化します。

OK、これは悪夢のように聞こえます（そして、複数の会社がこの道をたどることによって自分自身に大きな問題を生み出しています）成功は、潜在的なマイナス面を明確に認識し、それに対処するために常に努力することによってのみ可能です。

では、一体型のアプローチについてはどうでしょうか？

モノリシックアプリケーションは、マイクロサービスと同じくらい簡単にモジュール化できます。また、関数呼び出しは、実際にはRPC呼び出しよりも安価で信頼性があります。したがって、より信頼性が高く、実行速度が速く、コードが少ないことを除いて、同じことを開発できます。

では、なぜ企業はマイクロサービスアプローチを採用するのでしょうか？

答えは、スケーリングすると、モノリシックアプリケーションでできることには制限があるためです。非常に多くのユーザー、非常に多くの要求などの後、データベースがスケーリングされない、Webサーバーがコードをメモリに保持できないなどの状態になります。さらに、マイクロサービスのアプローチにより、アプリケーションの独立した増分アップグレードが可能になります。したがって、マイクロサービスアーキテクチャは、アプリケーションをスケーリングするためのソリューションです。

私の経験則では、スクリプト言語（Pythonなど）のコードから最適化されたC ++に移行すると、一般にパフォーマンスとメモリ使用量の両方で1〜2桁改善できます。別の方法で分散アーキテクチャに移行すると、リソース要件が大幅に増加しますが、無制限に拡張できます。分散アーキテクチャを機能させることはできますが、そうすることは困難です。

したがって、個人的なプロジェクトを開始する場合は、モノリシックに移行してください。うまくやる方法を学びましょう。（Google | eBay | Amazon |など）があるため、配布しないでください。分散している大企業に着地する場合は、それらがどのように機能するかに注意を払い、それを台無しにしないでください。そして、移行をしなければならなくなった場合は、非常に、非常に慎重になります。

開示、あらゆる規模の企業で20年近くの経験があります。そして、はい、私はモノリシックと分散アーキテクチャの両方を間近で見ました。その経験に基づいて、分散マイクロサービスアーキテクチャは本当にクリーンで優れているからではなく、必要なために行うことだと言っています。

私はbtillyの答えに心から同意しますが、Microservicesにもう1つのポジティブな要素を追加したかったのです。

Microservicesの世界では、サービスはドメインに合わせられ、個別のチームによって管理されます（1つのチームが複数のサービスを管理できます）。これは、各チームが他のサービスとは完全に別個に独立してサービスをリリースできることを意味します（正しいバージョン管理などを前提としています）。

それは些細な利益のように思えるかもしれませんが、モノリシックの世界では反対を考えてください。ここでは、アプリケーションの一部を頻繁に更新する必要がある場合、プロジェクト全体およびそれに取り組んでいる他のチームに影響を与えます。その後、スケジューリング、レビューなどを導入する必要があり、プロセス全体が遅くなります。

そのため、選択については、スケーリング要件を考慮するだけでなく、必要なチーム構造も考慮してください。Monolithicを開始し、その後Microservicesが有益になる可能性がある場所を特定するというbtillyの推奨に同意しますが、スケーラビリティだけが利点ではないことに注意してください。

私は独立したデータソースがかなりある場所で働いていました。それらはすべて単一のデータベースに入れられましたが、Webサービスによってアクセスされる異なるスキーマに入れられました。アイデアは、各サービスが作業を実行するために必要な最小限のデータにしかアクセスできないというものでした。

モノリシックデータベースに比べてオーバーヘッドはそれほど大きくありませんでしたが、これは主に、すでに分離されたグループにあったデータの性質によるものだと思います。

Webサービスはページを生成したWebサーバーコードから呼び出されたため、これはマイクロサービスアーキテクチャによく似ていますが、単語が示唆するほどマイクロではなく、分散されていない可能性があります（1つのWSが呼び出すことに注意してください）サードパーティのサービスからデータを取得するため、分散データサービスのインスタンスが1つありました）。これを行った会社は、規模よりもセキュリティに関心がありましたが、これらのサービスとデータサービスは、悪用可能な欠陥がシステム全体に完全にアクセスできないという点で、より安全な攻撃対象となりました。

Roger Sessionsは、彼の優れたObjectwatchニュースレターで、Software Fortressesのコンセプトと似たものを説明しました（残念ながら、ニュースレターはもはやオンラインではありませんが、彼の本を購入できます）。