記事を「応用情報システムの進化とそのアーキテクチャ開発の展望」と呼ぶのは学術的すぎて、結局のところ、実際の実際の経験から非常に短い絞り込みがあり、そのニーズとソリューションを引き起こした技術の開発のための可能なオプションがあります。 この記事が、応用IPに関連するさまざまなタスクを一般化し、再考するのに役立つことを願っています。これらの用語の意味をすぐに明確にしたいと思います。 IP-データの処理、送信、保存を提供するシステム。 これはすべてプログラミングではありませんが、最近では、IPはWebおよびモバイルアプリケーションに関連付けられることがほとんどですが、それらは完全には一致しません。 質問をできる限り広く見て、コメント欄で議論に参加してください。 それでも、私は意図的にフレームワークとテクノロジーの名前を使用して不要なホリバーを避け、一般的に受け入れられているアーキテクチャ、標準、プロトコルの名前に限定します。
技術の分岐は歴史の中で何度も起こりましたが、不必要な期間は常に、持続可能な開発の段階に続きます。重要でない分岐が影になり、関連する機能が最も実行可能なハイブリッドに結合されます。 まず、IPが最初からどのように進化したかを簡単に説明します。 思い出があふれるには、わずか9行と写真が必要です。
| 建築 | 主な機能 | 交換 |
|---|---|---|
| ＃0データファイル | すべてのデータをさまざまな未知の形式のファイルに保存しました | ファイル |
| ＃1ファイルサーバー | アプリケーションと同じプロセスで動作するデータベースエンジン | ファイル |
| ＃2ローカルDB | DBMSは別のプロセスで際立っています-DBMSサーバー | IPC |
| ＃3クライアントサーバー | DBMSはさまざまなタイプのワークステーション（クライアントワークステーション）のLANで利用可能 | RPC |
| ＃4 3層 | アプリケーションサーバーレイヤー、3リンク、リモートオフィスからの作業が際立っていた | RPC |
| ＃5 Webクライアント | シンクライアントがWebブラウザからデータにアクセスするように見える | HTTP |
| ＃6 Web 2.0 | AJAX、Comet、SSEを介した要素の部分的なインタラクティブな再読み込み | アヤックス |
| ＃7 SPA / WebApp | ページをリロードしないフル機能のブラウザーアプリケーション | アヤックス |
| ＃8 PWAおよびモバイル | プログレッシブWebアプリケーションとモバイルアプリケーション | Https |
リストされたソリューションのほとんどすべてがニッチに並行して存在するため、アーキテクチャの存在時間を示しませんでした。 最新のIPの場合、一般的な技術は依然として5番です。 リンク（シンクライアント）およびサーバー上のすべてのロジックによる再読み込みを伴う通常のWebページ。 多くのタスクでは、これ以上は必要ありません。 ＃8の最前線では、Webアプリケーションとモバイルアプリケーションがアーキテクチャ的に統合されましたが、テクノロジーと実装には多くの違いがあります。 次は？ トレンドの概要は既に説明されています。サーバーはAPI、クライアント上のデータベース、クライアントでのレンダリング、リッチGUI、オフライン作業、高負荷、多くのユーザーです。 しかし、技術的には、これらのニーズは非常に多くの異なるプラットフォームで満たされているため、分岐が発生しています。 これは、Webアプリケーションとモバイルアプリケーションにも当てはまります。 デスクトップアプリケーションの場合、いくつかの注意事項があり、状況も一致していると言わなければなりませんが、現在は傾向がなく、次の4つの開発オプションを一般的に適用IPに適用できることを意味します。
高クラウド負荷に対応（#Aクラウド高負荷）
利点 ：クラウドは、RESTの原理を使用してスケーリングの素晴らしい仕事をします。アプリケーションが状態を放棄した場合、数千万人のサブスクライバーにサービスを提供できます。 サーバープロセスは状態をメモリに保存せず、すべてのネットワークコールは独立しており、セッションをどの状態にも転送しません。
欠点 ：実際のアプリケーションでは、問題を解決するために状態が必要なため、RESTから離れることがよくあります。 それは、スケーラブルではないが、多くの制限がある疑似RESTであることがわかりました。 そして最も重要なことは、ユーザーと対話的に対話したり、ユーザー間の対話を提供したりするアプリケーションにはまったく不適切です。
結論 ：多くの場合、これは最適なソリューションです。コンテンツ、情報リソース、メディアのパブリッシングはクラウドで効果的に構築できますが、データベースと対話機能を備えた複雑なアプリケーションの場合、これはアーキテクチャ＃8からの後退です。
アプリケーションサーバー（#Bアプリケーションサーバー）
利点 ：Webサーバーはアプリケーションサーバーによって占有されています。 Webサーバーの制御下で実行されるのはアプリケーションではありませんが、Webサーバーはアプリケーションまたはアプリケーションサーバーに組み込まれています。 さらに、効率を高めるために、HTTP / HTTPSを専用のTCP / TLSプロトコルに置き換えることができます。 これは特にモバイルおよびデスクトップアプリケーションに当てはまり、RPC、イベントバス、データベースの同期を構築できます。
短所 ：そのようなアプリケーションにはまだユニバーサルクラウドソリューションがありませんが、すべてがまもなく表示されるようになります。 その前に、独自の技術スタックを発明し、自分でプライベートクラウドを構築する必要があります。 維持管理が困難です。 さらに、サーバーとクライアント上のデータベースの同期は、通常は開発者の多大な努力によって、アプリケーションを介して手動で行われ、通常、このようなソリューションを再利用することはできません。
結論 ：現在、この方向は、 何百万人ものユーザーにサービスを提供し 、インタラクティブなアプリケーションを作成するか、大規模ユーザー向けの同様のソリューションを準備するR＆D研究所を必要とする大企業のみが利用できます。
DB中心のアプローチ（#Cデータベース中心）
利点 ：データベースをアプリケーションの前に置き、データベース間の同期（部分レプリケーション）を設定することは非常に魅力的です。 したがって、アプリケーションにDBMSが組み込まれ、サーバーではなくローカルデータベースで動作します。 DBMSが長い間存在し、拡張することを学んだため、楽観的レプリケーション、運用変換、競合のないレプリケートされたデータ型など、多くの方法がすでに発明されています。
欠点 ：データを介したアプリケーション間の通信のみでは、明らかに機能が制限されます。 これは、ベースで動作するすべてのものの削減です。 しかし、イベントの受け渡し、APIレベルでの統合、リモートプロシージャの呼び出しはどうでしょうか。 これはすべて、DB中心のアプローチで忘れられなければなりません。
結論 ：特定のクラスのタスクでは、これは素晴らしいソリューションであり、イントロスペクションおよびスキャフォールディングUIとともに、このようなアーキテクチャは、APIを使用して統合し、プログラムで相互作用を記述するのに常に必要な、より複雑な競合他社の非常に幅広い分野を自動的に「展開」します
ピアツーピアまたはピアツーピア相互作用（#Dピアツーピア）
利点 ：これにより、バインディング/ブローカー機能のみを実行するサーバーの負荷が軽減されます。 多くの場合、ユーザー間のローカルインタラクションは、特に大きなデータストリームの場合、リモートサーバーを介した場合よりも効果的です。 それは、個人データの交換の匿名性に希望を与えます。
短所 ：ピアツーピアネットワークの「信頼」の問題は、まだ完全には解決されていません。 P2Pでのみ分散IPを構築することはできません。サーバーはこのスキームのままです。 これまでのところ、応用情報システムを構築するために必要な範囲での実装のための広範なプロトコル、ライブラリ、フレームワーク、およびその他のソフトウェアツールはありません。
結論 ：ピアツーピアネットワークの要素は、集中型IPに組み込まれます。
トレンドの概要
これらの分野が合併した結果、どのようなハイブリッドが生まれるかはまだ明らかではありませんが、いくつかの仮定を構築し、少なくともトレンドを強調することはすでに可能です。
この段階でアーキテクチャの分岐が発生することは、アプリケーション自体にシステムコンポーネントが統合されているため、まず明らかです。
- 組み込み通信サーバーアプリケーション：HTTP / WS、HTTPS / WSS、TCP / TLSなど
- 自動同期を備えた組み込みDBMS。
- 同様に、IPの別の機能について思い出すことができます。これはデータ処理またはコンピューティングです。 したがって、分散コンピューティングシステムの組み込みアプリケーションは、遅かれ早かれ発生します。 結局のところ、現在のユーザーデバイスは優れた計算能力を備えており、分散データ処理には使用していません。これは許容できないアーキテクチャの省略です。
個人的には、データ中心のアーキテクチャ（パレートの原則によれば、ニーズの80％を完全自動化でカバーする）とアプリケーションサーバー（残りの20％のAPIまたはイベントバスレベルでの統合を可能にする）を組み合わせたいと思います。 このため、IPインタラクションプロトコルは、RPC、REST、イベントバス、DB同期、バイナリストリーミングの5種類のインタラクションを同時にサポートする必要があります。 私たちのチームは現在、このような包括的なソリューションに取り組んでいます。
4つの大規模なアーキテクチャに加えて、個々の機能の組み合わせからハイブリッドを構築できます。
- 同期-リアルに近い時間モードでの分散システムのアプリケーション間のデータ構造の同期。
- オフライン-ブラウザまたはモバイルアプリケーションのローカルストレージに保存されたデータの一部を操作し、オンラインになったときに同期する機能。
- 対話性-サーバーとの双方向のイベント交換の可能性、およびリアクティブコンポーネントの構築：UI、データベースカーソル、アプリケーションロジック、ネットワーク交換など。
- 低遅延（または高可用性）-要求の処理とサーバー応答時間の最適化の準備の特性（帯域幅と混同しないでください）。
- 高負荷-要求の集中ストリーム（1秒あたりの要求）を処理します。これには、頻度、サイズ、優先度、キューでの待機時間、ライフタイム、およびサービスのためのリソースが含まれます。
- 高い接続性-どちらかの側の主導で双方向のデータ交換が可能な、サーバーへの多数の競争力のある（同時かつ長期間）クライアント接続。
- 高い相互接続-競合する化合物間の相互作用の強度の特徴、および相互作用する化合物のグループのサイズ。
- スケーラビリティ-水平および垂直スケーリングの特性のグループ。ソフトウェアおよびハードウェアのスケーリングの透明性を提供します（コードを書き換えることなく）。
- ビッグデータ-大量のデータを処理する機能。たとえば、ストリーミングデータ処理や分散ストレージへのクエリの構築。
- ビッグメモリとインメモリDB-メモリの使用率が高いか、データベースをランダムアクセスメモリに完全に転送し、インデックスを追加してクエリを高速で実行します。
- 統合の柔軟性-イントロスペクション、自動インターフェイスバインディング、足場、 メタモデルの動的解釈に基づくソリューションの柔軟性と統合の容易さの特性。
私たち全員が傾向を理解するために、私は質問に答えることを提案し、建設的な批判やコメントにも感謝します。