ローカルアプリケーション間の安らかなコミュニケーションは良い考えですか？

Question

（同じサーバーで）ローカルアプリケーションをRestful APIを通じて完全に互いに通信させることをお勧めしますか？

これは珍しいことではないことを知っています。なぜなら、ローカルアプリケーションであっても、コミュニケーションにHTTP RESTを使用しているCouchDBのようなアプリケーションがすでにあるからです。

しかし、より大きなアプリケーションのモジュールのように機能するアプリケーションを作成することにより、私はそれをより高いレベルに引き上げたいと思います。これは、別のアプリケーションなどのモジュールでもあります。言い換えれば、Restful APIと通信している多くのローカルアプリケーション/モジュールがあります。

このようにして、これらのアプリケーション/モジュールは任意の言語である可能性があり、サーバー間のワイヤーを介して通信することができます。

しかし、私にはいくつかの質問があります：

• これは良い考えですか？
• それらの間のデータ転送は遅くなりますか？
• これを行うと、各アプリケーション/モジュールがHTTPサーバーである必要がありますか？したがって、アプリケーションが100のアプリケーション/モジュールを使用している場合、これらのそれぞれがそれぞれ異なるポートで実行されているローカルHTTP Webサーバーでなければなりません（http：// localhost：81、 http：// localhost：82, http：// localhost：83 など）そうですか？
• 私が知っておくべきベストプラクティス/ゴッチャはありますか？

Answer 1

• これは良い考えですか？

確かに、おそらく。

• それらの間のデータ転送は遅くなりますか？

うん！しかし、何と比較して？ネイティブの内部呼び出しと比較して、絶対に - それは氷河になります。他のネットワークAPIと比較して、EH、必ずしも遅くなるわけではありません。

• これを行うと、各アプリケーション/モジュールがHTTPサーバーである必要がありますか？したがって、アプリケーションが100のアプリケーション/モジュールを使用している場合、100のローカルHTTP Webサーバーを使用して、それぞれ異なるポートを使用して実行する必要があります（http：// localhost：81、http：// localhost：82, http：// localhost：83 等々）？

いや、モジュールごとにポートを割り当てる理由はありません。これを行うためのあらゆる種類の方法。

• 私が知っておくべきベストプラクティス/ゴッチャはありますか？

これが成功する唯一の方法は、あなたが話しているサービスが十分に粗い場合です。これらは、それらを価値のあると呼ぶ費用を課す大きくて黒い箱型のサービスでなければなりません。接続コスト、データ転送コスト、および各トランザクションでコストをマーシャリングするデータが発生します。したがって、これらのトランザクションが可能な限り珍しいものであることを望み、最良の利益を得るためにペイロードを可能な限り大きくしたいと考えています。

実際にRESTアーキテクチャを使用しているのか、それともhttp経由で物を送信しているだけですか？ （これらは異なるものです）RESTは独自のコストを負担します。

最後に、これを行う必要がないかもしれません。それは「ちょっとクール」であり、「いい」、「白いボードでは良さそう」かもしれませんが、実際に、それを必要としないなら、それをしないでください。内部サービスを分離する良い実践に従って、後でこのようなことをすることを決定した場合、通信を管理するために必要な接着層を挿入するだけです。リモート配信を追加すると、リスク、複雑さ、パフォーマンスの低下が増加します（スケーリング！=パフォーマンス）したがって、それを行う正当な理由があるはずです。

それは間違いなく、それらすべての「ベストプラクティス」です。

編集 - コメントへの応答：

だから、私はすべての着信要求を処理する1つのWebサーバーを実行するということですか？ただし、モジュールはスタンドアロンアプリケーションではなく、目的全体を打ち負かします。それぞれのモジュールを単独で実行できるようにしたいと思います。

いいえ、それは目的を打ち負かしません。

これが取引です。

3つのサービスがあるとしましょう。

• http://store.example.com/service1

• http://blog.example.com/service2

• http://forum.example.com/service3

一見すると、これらは3つの異なるマシンで3つの異なるマシンで、3つの異なるWebサーバーで実行される3つの異なるサービスであると言うのは公平です。

しかし、真実は、これらはすべて同じマシン、同じWebサーバーで、まったく同じロジックを実行している（これを極端に進めるために）実行できるということです。

HTTPを使用すると、あらゆる種類のものをマッピングできます。 HTTP自体は抽象化のメカニズムです。

クライアントとして、あなたが気にするのは、使用するURLと送信するペイロードだけです。クライアントの問題ではなく、どのマシン、または実際のコードを実行するか。

アーキテクチャレベルでは、抽象化とモジュール化の方法を達成しました。 URLにより、システムを整理できます。これは、必要な論理レイアウトです。物理的な実装は、論理ビューとは異なります。

これらの3つのサービスは、単一のプロセスで提供される単一のマシンで実行できます。一方、それらは1000台のマシンを表すことができます。 「www.google.com」に応答するマシンはいくつあると思いますか？

Webサーバー自体を保存するコードを共有することなく、3つのサービスすべてを単一のマシンで簡単にホストできます。サービスを元のマシンから他のマシンに簡単に移動できます。

ホスト名は、サービスをマシンにマッピングする最も簡単な方法です。最新のWebサーバーは、さまざまなホストを任意にサービスできます。各「仮想ホスト」は、そのホストの名前スペース内で、任意の数の個々のサービスエンドポイントをサービスできます。 「ホスト」レベルでは、あるマシンから別のマシンにコードを再配置するのは簡単です。

サーバー上の実際のロジックに任意のリクエストを向けるために、最新のWebサーバーの機能をさらに検討する必要があります。あなたはそれらを非常に柔軟にすることがわかります。

Answer 2

これは良い考えですか？

はい。それは常に行われています。これが、たとえば、すべてのデータベースサーバーの動作です。 Linuxには、TCP/IPを介して通信するクライアント/サーバーアプリケーションが満載されています。

それらの間のデータ転送は遅くなりますか？

いいえ。TCP/IP使用 localhost 実際のネットワークI/Oを実行するための短いカットとして。

HTTPプロトコルは、専用の接続に最適なものではありませんが、シンプルでよくサポートされています。

これを行うと、各アプリケーション/モジュールがHTTPサーバーである必要がありますか？

必ずしも。一部のモジュールは、クライアントであり、サーバーを持たない場合があります。

したがって、アプリケーションが100のアプリケーション/モジュールを使用している場合、これらのそれぞれがそれぞれ異なるポートで実行されているローカルHTTP Webサーバーでなければなりません（http：// localhost：81、 http：// localhost：82, http：// localhost：83 など）そうですか？

はい。それが機能する方法です。

私が知っておくべきベストプラクティス/ゴッチャはありますか？

ポート番号を「ハードコード」しないでください。

「特権」ポート番号（1024未満）を使用しないでください。

WSGIライブラリを使用すると、すべてのモジュールをWSGIアプリケーションに作成するのが最も幸せになります。その後、些細な2ラインHTTPサーバーを使用して、モジュールをラップできます。

これを読む。 http://docs.python.org/library/wsgiref.html#examples

Answer 3

アプリケーション統合にRESTFULソリューションを使用することで、これは良いアイデアであり、別の質問で同様の見解を公言していると思います。

• 組織全体でデータを共有する方法

Answer 4

率直に言って、100のアプリケーションに100のサーバーが必要だとは思わないので、同じサーバーで100ポートを使用するだけかもしれません。

また、Restful Interfaceは、サーバーを拡張し、巨大にスケールアップする可能性がある場合にロードバランスを有効にする柔軟性を提供します。

Answer 5

いいえ - 正当な理由がなければ、それは良い考えではありません。アプリケーションのコードをレイヤー化して、必要に応じて後の段階で「休む」ことができることをお勧めします。 （または、パフォーマンスの改善が必要であるとみなされるものは何でも）「サーバーベースのレイヤー」の展開の複雑さの増加は、それを行わない正当な理由です。私は提案します：

• 優れたクリーンコードを使用して、よく構造化されたアプリケーションを作成します。
• 予想される生産負荷でテストします
• 必要に応じて - サーバーであるレイヤーにリファクタリングします - しかし.....

より良いアプローチは、アプリケーション全体のバランスをとることです。アプリサーバーに状態のないRailsのようなことをしている場合、いくつかのインスタンスを並行して実行するのに問題はないはずです。

あなたが複雑さを探しているなら - 私の答えを無視してください。 :-)