マイクロサービスとストアドプロシージャ
ストアドプロシージャは、マイクロサービスアーキテクチャでは悪い習慣と見なされていますか？
これが私の考えです。
マイクロサービスに関するほとんどの書籍では、マイクロサービスごとに1つのデータベースを推奨しています。ストアドプロシージャは通常、モノリシックデータベースで機能します。
ここでも、ほとんどのマイクロサービスアーキテクチャブックは、自律的で疎結合である必要があると述べています。特にOracleで記述されたストアドプロシージャを使用して、マイクロサービスをそのテクノロジーに密結合します。
ほとんどのマイクロサービスアーキテクチャブック（私が読んだもの）では、マイクロサービスはビジネス指向である（ domain-driven design （DDD）を使用して設計する）ことを推奨しています。ビジネスロジックをデータベース内のストアドプロシージャに移動することで、これは当てはまりません。
これについて何か考えはありますか？
マイクロサービスでストアドプロシージャを使用することを明示的に禁止または主張するものはありません。
免責事項：開発者のPOVからのストアドプロシージャは好きではありませんが、マイクロサービスとはまったく関係ありません。
ストアドプロシージャは通常、モノリスデータベースで機能します。
あなたは論理的な誤りに屈していると思います。
ストアドプロシージャは最近減少しています。まだ使用されているほとんどのストアドプロシージャは、保持されている古いコードベースのものです。その当時、モノリシックデータベースは、マイクロサービスが普及したときと比較してはるかに普及していました。
ストアドプロシージャとモノリシックデータベースはどちらも古いコードベースで発生するため、これらを一緒に見る頻度が高くなります。しかし、それは因果関係ではありません。ストアドプロシージャを使用しない理由モノリシックデータベースがあります。モノリシックデータベースがありません理由ストアドプロシージャを使用します。
マイクロサービスに関するほとんどの書籍では、マイクロサービスごとに1つのデータベースを推奨しています。
これらの小さなデータベースにストアドプロシージャを含めることができない技術的な理由はありません。
先ほど触れたように、ストアドプロシージャは好きではありません。私はそれらを扱いにくく、将来のメンテナンスに耐えられると思います。 sprocを多くの小さなデータベースに分散すると、私がすでに気に入らない問題がさらに悪化すると思います。しかし、それはそれができないという意味ではありません。
ここでも、ほとんどのマイクロサービスアーキテクチャブックは、自律的で疎結合である必要があると述べています。特にOracleで記述されたストアドプロシージャを使用して、マイクロサービスをそのテクノロジに密結合します。
反対に、マイクロサービスが使用するどんなORMについても同じ議論をすることができます。すべてのORMがすべてのデータベースをサポートするわけではありません。カップリング（具体的にはその堅さ）は相対的な概念です。それはあなたが合理的にできる限りルーズであることの問題です。
マイクロサービスに関係なく、Sprocは一般に密結合の影響を受けます。私は一般的にsprocsに対して助言しますが、特にマイクロサービスを使用しているからではありません。それは以前と同じ議論です：sprocsは（一般的に）進むべき道だとは思いませんが、それは単に私の偏見かもしれません、そしてそれはマイクロサービスとは関係ありません。
ほとんどのmsaブック（私が読んだもの）では、マイクロサービスをビジネス指向（dddを使用して設計）にすることを推奨しています。ビジネスロジックをデータベースのストアドプロシージャに移動することで、これは当てはまりません。
これは常に、sprocについての私の主な不満でした。データベース内のビジネスロジックです。意図していない場合でも、どういうわけか常にそうなる傾向があります。
しかし、繰り返しになりますが、マイクロサービスを使用するかどうかに関係なく、この問題は存在します。それがより大きな問題のように見える唯一の理由は、マイクロサービスがアーキテクチャ全体を最新化するようにプッシュするためであり、sprocsは現代のアーキテクチャではもはや好まれていません。
ソフトウェアを作成するには、テクノロジーに密結合する必要があります。
少なくとも、その中で開発されているプログラミング言語によって提供されるランタイム環境に。
より一般的には、あなたのマイクロサービスはいくつかのテクノロジーと密接に結びついていることがわかります：
- 高レベルのHTTP/SSL/SOAPプロトコル実装を提供するネットワークサービスフレームワーク
- 永続性を提供するリポジトリ/ ORM/DAOフレームワーク。
- データを操作するためのツールを提供するデータ操作フレームワーク。
- マルチタスク、ファイルシステム、メモリ、GPUコンピューティング、拡張カードなどのOSリソースへのアクセスを提供するプロセス/スレッド/ OSフレームワーク...
そして、それは必要最小限のマイクロサービスを作ることです。
ストアドプロシージャ
ストアドプロシージャは、使用するか使用しないかを選択できる別のテクノロジにすぎません。それはあなたのコードを魔法のようにモノリシックまたはマイクロにしません。
それは何ですか：
- 別のテクノロジー。アプリケーションに存在する各テクノロジーは、特定のプログラマーがそのテクノロジーミックスの読み取り、理解、および賢明な設計選択を行う可能性を減らします。
- 異なるプログラミングパラダイムを使用する言語。専門家ではない人が自分の命令的、機能的、オブジェクト指向などの視点を試して強制するのはあまりにも簡単です。これは多くの場合、優れた結果につながりません。
- API。コードベースの他のクラスと同様に維持する必要があります。また、データベースが一般的でないインターフェースを提供していることも意味します。これにより、データベースエンジン自体を置き換えることも、メモリキャッシュなどの一般的な動作を透過的に適用することも困難になります。
- アーティファクト。バージョン管理、テスト、および展開が必要です。これは可能ですが、データベースは別のアプローチを必要とする生きた人工物です。通常、オリジナルを削除して置き換えることはできません。多くの場合、システムを望ましい状態に移行するためには、時間をかけて変更を慎重に調整する必要があります。
これらはそれぞれ実際のコストです。場合によってはコストが正当化されることもあれば、そうでないこともあります。
スクリプトエンジンをホストすることで、ほぼ同じコストセットを支払うことになります。唯一の削減は、ホスト言語と同じプログラミングパラダイムを選択できることです。
ビジネスロジック
ビジネスルールをデータベースに移動することは悪い習慣です。ストアドプロシージャが原因ではありません。
データベースとビジネスロジックは異なるシャーリングレベルで動作するため、これは悪い習慣です。
成熟したアプリケーションのデータベースは、何十年も使用されている可能性があります。通常、これらのシステムではエンジンが定期的に更新されますが、データベース自体は移行されました。最初から殺されて再建されたわけではありません。マイクロサービスがそれほど長く存続できない理由はありません。
ビジネスルールの変化の速さと数十年を比較してください。私の経験では、古いビジネスルールはおそらく数年前のものですが、ほとんどがすぐに変更され、どちらが次に変更されるかはわかりません。規制当局からの新しい要件、廃止予定の古い製品、レターヘッドの変更、上司に報告する従業員数の変更など.
ビジネスロジックがシャーリングレイヤー全体に分散している場合、特に、より低速で長寿命のレイヤーに分散している場合、変化に対する抵抗が生じます。これは必ずしも悪いことではありません。結局、ビジネスロジックがゼロのデータベースは、トリプルストアだけです。
テーブルスキーマを指定するという単なる行為は、ビジネスロジックをデータベースに移動することです。
アーキテクチャ
ソリューションを作成して維持するために、あまり多くのツールを必要とせず、解決するのを難しくしすぎずに、適切な問題に対して適切なツールを使用することに取り組んでいます。
これは簡単ではありません。
しかし、考えられないことを考えてみましょう。複数の言語に分散したビジネスロジックをどのように維持しますか？
- 各ビジネスルールの実装を追跡および維持できるように、カタログ。
- テスト...実装の場所や方法に関係なく、各ビジネスルールに対して使用できます。
- 参照実装..不一致が見つかった場合、真実の情報源（または少なくとも議論の情報源）が存在するようにします。
しかし、これにはコストもかかります。
- ビジネスルールに多くの実装を許可する方が良いですか？それぞれがチームのスキルとフレームワークの規定を利用できますが、小さな気まぐれが多くないように厳格な品質管理が必要ですか？
- それとも、単一の言語で書かれた単一の真実の情報源を持つ方が良いでしょうか？間違いなく実装コストは安く、それでも障害の単一の原因であり、それ自体が異なるプラットフォーム、フレームワーク、またはまだ発明されていないツールに直面しても変化に抵抗するモノリシックコンポーネントですか？
ストアドプロシージャを使用するいくつかのマイクロサービスを実際に維持していると言って、私の回答の前置きをします。また、キャリアのさまざまな時点で多くのストアドプロシージャを作成しましたが、それらを誤って使用すると、事態が非常に悪くなる可能性があることにも同意します。
つまり、短い答えは、いいえ、ストアドプロシージャは、マイクロサービスアーキテクチャにおいて本質的に悪いものではないということです。しかし、あなたは理解する必要があります：
- ストレージエンジンの置き換えに障害を追加しています。運用上またはパフォーマンス上の特性または機能の制限によってストレージエンジンの切り替えが必要な場合は、多くの新しいコードを記述してテストするため、コストが高くなります。複数のストレージエンジンを実行すると（移行フェーズ中、またはパフォーマンスニーズに基づいてアクティビティを分離するため）、パフォーマンス自体に問題がある2フェーズコミット（2PC）を使用しない限り、一貫性の問題が発生する可能性があります。
- 維持する別のAPIがあります。つまり、依存関係が壊れる可能性があります。プロシージャのパラメータのタイプを追加、削除、または変更すると、既存のコードが破損する可能性があります。テーブルとクエリでも同じことが起こりますが、ツールは、問題が発生する可能性のある場所を追跡するのにあまり役立ちません。ストアドプロシージャの問題は、通常、実行時、開発/展開プロセスの非常に遅い段階で見られます。
- データベースの権限がさらに複雑になりました。プロシージャはログインしたユーザーとして実行されますか、それとも他の役割として実行されますか？これについて考え、管理する必要があります（うまくいけば自動化された方法で）。
- 安全に新しいバージョンに移行できる必要があります。多くの場合、プロシージャを削除して再作成する必要があります。繰り返しになりますが、権限によって問題が発生する可能性があります。
- 失敗した移行のロールバックは、追加の作業を意味する場合があります。本番環境が開発者から分離されると、事態はさらに困難になります。
これらは、私がしばしば価値があると思うストアドプロシージャのいくつかの使用法です。
- 編集履歴（監査ログ）の実施。トリガーはこの目的で一般的に使用され、トリガーはストアドプロシージャです。一部のデータベースでは、アプリケーションロールの挿入と更新を完全に禁止することもできます。クライアントは、適切な権限を持つ別のロールとして実行され、必要なすべての動作を実行するプロシージャを実行します。
- チェック制約の拡張。これにより、ビジネスロジックの領域に入る可能性がありますが、データベースの組み込みの制約ツールでは、必要なものが十分でない場合があります。多くの場合、チェックを表現するための最良の方法は命令コードを使用することであり、アプリケーションがそれを実行することに依存している場合は、不良データを入れる危険があります。
- ビューが不適切または複雑すぎる場合の複雑なクエリのカプセル化。正しいビューが、ストアード・プロシージャーでより理解しやすく表現できる非常に複雑なSQLを必要とするいくつかのケースを見てきました。これはおそらくまれですが、実際に発生します。
一般的には、最初にビューを試し、必要な場合にのみ手順を実行することをお勧めします。適切に設計されたビューは、実際にはAPIとして機能し、基になるテーブルのクエリ方法の詳細を抽象化します。ストアドプロシージャでAPI（ビュー）を拡張することは、状況によっては理にかなっています。クエリ結果からアプリケーションのデータモデルへのマッピングデータ全体の混乱を回避して、SQLクエリから直接JSONを発行することも可能です。それが良いアイデアかどうかは、自分のニーズに基づいて判断するためのものです。
すでにいくつかの自動化ツールを使用してデータベースリソース（スキーマ、権限など）を管理しているはずなので、いいえ、ストアドプロシージャはマイクロサービスにとって本質的に悪いものではありません。
ストアドプロシージャは実装の詳細です。ファイルシステムのどこかに保存されているデータベース関数、ラムダ、またはシェルスクリプトはすべて実装の詳細であり、アーキテクチャには関係ありません。
マイクロサービスに関するほとんどの書籍では、マイクロサービスごとに1つのデータベースを推奨しています。
では、これらのデータベースにストアドプロシージャをコーディングします。
再び、ほとんどのマイクロサービスアーキテクチャブックでは、自律的で疎結合である必要があると述べています
ビジネス機能、開発のライフサイクル、管理、展開、チームの場所などの間。実装の詳細とは関係ありません。マイクロサービスは技術的な問題を解決しません（正反対）。彼らは経営陣と市場投入までの時間の問題を解決するためにやって来ます。それは戦略であり、戦術ではありません。最小限のコストでフェイルファストする方法。特定のビジネス機能が役に立たないことが判明した場合、他の機能、デプロイメント、プロジェクトの管理、リリースを台無しにすることなく、それをドロップします...
「スプリット」はすでにデカップリングエージェントのように機能することに注意してください。 2つのサービスがあるとします。AはOracleによってサポートされ、BはMongoDBによってサポートされています。デカップリングの黄金律を破らない限り、Bへの副作用は無視できる程度にA + Oracleを落とすことができるはずです。
特にOracleで記述されたストアドプロシージャを使用して、マイクロサービスをそのテクノロジに密結合します。
ベンダーロックインを引き起こす可能性があります。多くの場合、ベンダーは歴史的または契約上の理由によりビジネスから課されます1。コードをベンダーにロックしない方法を知ることが重要です。たとえば、一部のORMとフレームワークは、データベースの組み込み関数と機能を隠す新しいクエリ言語を実装しています。
ただし、サービスが十分に小さい場合は、全体のごく一部に影響を与えるため、ベンダーロックインはもはや問題ではありません。迅速に交換（または分離）できるはずの小さな部品。
ほとんどのMSA書籍（私が読んだもの）では、マイクロサービスをビジネス指向（DDDを使用して設計）にすることを推奨しています。
business-drivenである必要があります。すべてのビジネスがDDDを利用するわけではありません。 DDDとマイクロサービスは多くの点で重複していますが、それらは原因となる影響ではありません。貧血サービスで構成されたマイクロサービスエコシステムになる可能性があります。または、複雑なドメインを実装するサービスと、DBから直接POJOを提供するダム貧血サービスの両方の組み合わせで構成されます。それには何も問題はありません。
本に関しては、彼らは戦略の実行にのみ焦点を当てています。戦術-分散コンピューティングを利用する方法-成功させるにはどうすればよいですか。しかし、それらは（通常）戦略にとらわれません。戦略は会社ごとに異なり、開発者に依存することはほとんどありません。したがって、本が私たちの特定のニーズ、要件、および制約に言っていることを推定して適応させる必要があります。目標は、ビジネス戦略を収益性の高い持続可能なものにすることです。
どのようなアーキテクチャも目的を達成するための手段であることを常に心に留めておいてください。ビジネスルール。ファッションや芸術への愛情のためにマイクロサービスエコシステムを構築することはありません。
マイクロサービスとは何の関係もありません。
ストアドプロシージャは、DBがサービスの基盤であり、データアクセス層とビジネスロジック層が上にある「古いスタイル」の階層型アーキテクチャーのサービスの場合に有効です。このようなアーキテクチャにおけるサービスとデータベース間のインターフェースは、サービスの最も内側の詳細に非常に固有です。通常、サポートされるデータベースの種類ごとにサービス固有のアダプターがあり、アダプターによって公開されるAPIの特殊性により、基になるレイヤーでストアドプロシージャを使用できるようになります。
そのようなアーキテクチャには多くの問題があります。最も重要なのは、ほとんどのロジックを単体テストすることが非常に困難になることです。これらのアーキテクチャはもはや好まれません。
新しいスタイルの「クリーンアーキテクチャ」、「オニオンアーキテクチャ」などを使用している場合、データベースは注入された依存関係となり、外側の層で指定されます。これは外側のレイヤーで定義されているため、データベースに提供されるインターフェースはgenericである必要があります。 cannotサービスの最も内側の詳細を反映します。これらの詳細は、アーキテクチャの最も外側の層からhiddenでなければならないためです。データベースまたは単体テストハーネスで機能するgenericストアドプロシージャインターフェイスを定義することは非常に難しく、実際には必要ないため、これらの種類のアーキテクチャではストアドプロシージャが実用的でないことがよくあります。
マイクロサービスとの関係は、マイクロサービスが新しくて優勢であるということです-私たちはもう一枚岩をしません-そしてこれらの新しい建築スタイルもまた優勢です-フラットレイヤーをもうしません。