これらの基本的なコンポーネントを備えたシステムを設計する必要があります。
このようなシステムでは、すべてのコンポーネントが構築されるサービスレイヤーを持つことは理にかなっていますか？コンポーネント間の相互作用はすべて、サービスレイヤーを通過します。これにより、システムのアップグレードと保守が容易になりますが、処理するトラフィックが非常に多いため、パフォーマンスに大きな影響はありませんか？
あなたがそれを警戒しない限り、これが起こり得ることです。
レイヤー間の通信では、XMLなどの形式が選択されます。次に、それをビルドして実行し、パフォーマンスが不十分であることがわかります。
次に、プロファイラーをいじって、問題が何であるかを推測します。
このような問題に取り組んだとき、私はスタックショット手法を使用して、すぐに問題を見つけました。あなたはそれがI/Oだと思ったでしょう。いいえ。データをXMLに変換し、XMLを解析してデータ構造を復元するのに約80％の時間がかかっていました。それを行うためのより良い方法を見つけるのはそれほど難しくありませんでした。結果-5倍のスピードアップ。
個人的には、システムを設計するときに、低レベルの実装の詳細に集中しすぎている可能性があると感じています。コンポーネント、アセンブリ、またはサービスをレイアウトする方法を検討する前に、システムを設計する方法を検討する必要があります。
システムアーキテクチャを構築するための次の高レベルのステートメントから始めることができます。
明らかに、上記のすべてがあなたの特定のケースに一致するわけではありませんが、少なくともいくつかの考えを与える必要があることをお勧めします。
幸運を。
個別のサービスレイヤーを持つことのコストとしてどのように見ていますか？
それらの費用は、あなたが負担しなければならない費用とどのように比較されますか？あなたの場合、それは少なくとも
加えて、いくつかのデータの変更。
どんなサービスを考えていますか？多分
なぜオーバーヘッドはプロシージャコール以上のものなのですか？サービスは、「個別のプロセス」または「Webサービスのマーシャリング」を意味する必要はありません。
構造は常に価値があると私は主張します。アプリケーションの関心の分離は本当に重要です。データベースアクティビティと比較して、いくつかのプロシージャ呼び出しはめったに多くの費用がかかりません。
ちなみに、生データの永続化は、キューイングシステムに対して行うのが最適な場合があります。必要に応じて、別々のマシンに多数のキューリーダーを配置することで、自然なスケーリングを実現できます。事実上、キューイングシステムは、サービスのような概念を自然に導入しています。
抽象化と階層化はレイテンシーをもたらしますが、本当の問題は、コストを価値のあるものにするために何を獲得しているのかということです。緩い結合、ガバナンス、スケーラビリティ、保守性は、実際の価値があります。
最適に設計されたレイヤードアプリでさえ、DBと直接通信するアプリよりも待ち時間が長くなります。元のシステムを知っているユーザーは違いを感じるでしょう。彼らはそれを好まないかもしれないので、これは技術的な問題と同じくらい政治的な問題になる可能性があります。