マイクロサービスとしてのデータストアの並行性の管理スケール

Question

私はまだマイクロサービスを回避しようとしています。私は基本的な質問があります。

エンタープライズのシナリオでは、マイクロサービスは、RDBMSや何らかの種類のNoSQLなど、永続的なデータストアに書き込む必要があります。ほとんどの場合、永続的なデータストアはエンタープライズグレードですが、1つのエンティティのみが複製され、バックアップされます。

ここでは、独自の永続データストア（エンタープライズグレードのRDBMSなど）を持つプライベート/パブリッククラウド環境にデプロイされた単一のマイクロサービスのケースを考えてみましょう。マイクロサービスの規模を拡大すると、同じデータストアからの読み取り/書き込みを試みるマイクロサービスのインスタンスが複数存在します。従来のデータストアは、〜50-200同時接続を処理するためにおそらく調整できます。私のマイクロサービスがそれをはるかに超えて拡大縮小されなければならない状況をどう対処しますか？

このような場合のベストプラクティスは何ですか？どのようなパターンを使用することができますか？

Answer 1

理想的には、各マイクロサービスインスタンスは自己完結型であるため、各インスタンスは他のインスタンスとは独立して拡張でき、その状態をカプセル化して他のユーザーが明確に定義されたAPIを通じてのみアクセスできるようにします。したがって、マイクロサービスが状態を格納するために使用するデータベースをどのように拡張するかを把握する必要があるだけでなく、このアーキテクチャパターンを本当に釘付けたい場合には、このカプセル化の問題も解決しなければなりません。

Service Fabricをご覧になりましたか？サービスファブリックの概念はstateful servicesで、実際には各マイクロサービスインスタンス内にデータが格納されています。このプラットフォームは、HAのための複製とディスクの永続性を自動的に処理し、また、複数のマシン間で配布するためにデータパーティション化機能を内蔵しています。この考え方は、基本的に中央データベースを破棄し、マイクロサービスインスタンス内で計算とデータを同じ場所に配置することです。今やあなたのサービスは自己完結型であり、突然ソリューションはこのアーキテクチャパターンにうまく収まります。これは、それぞれのマイクロサービスインスタンスを個別にスケールアウトしてアップグレードすることができ、データをサービス内に完全にカプセル化できるからです。もちろん、トレードオフは、本格的なRDBMSの機能セットを手に入れることはできませんが、とにかくNoSQLストアを検討しているならば、それは大きな問題ではありません。

私の考えは、データベースのような中央の店舗は、シェアード・ニア・マイクロサービス・アーキテクチャーでややアンチ・パターンであるということでした。しかし、私はサービスファブリックに取り組み、私の意見は少し偏っているかもしれません！