0

私の質問は実際には問題ではなく、意見を求めるものです。おそらく、これは投稿するのに適切な場所ではありません。それにもかかわらず、ここのコミュニティは非常に情報が豊富であり、試してみても害はありません...

私は、高度にスケーラブルで、とりわけ高度にモジュール化されたバックエンドアーキテクチャを作成する方法を考えていました。たとえば、大規模なサイトへの将来性のある進化の可能性を秘めた大規模なサイトのバックエンドエコシステム全体。

これには、関心の分離が非常に高度になり、（たとえば）基盤となるDBを置き換えることができるだけでなく（つまり、OracleからMySQLに）、実際のタイプのデータベースを置き換えることができます（SQLからKV、または逆に）。

各サブシステムがバックエンドエコシステム内で独自のAPIを公開する状況を想定しています。このようにして、APIは一定のままでありながら、実装は時間の経過とともに（根本的にさえ）変更される可能性があります。

システムは、特定の言語に関連付けられていないという点で異種である必要があります。異なる言語を使用するモジュールまたはサブシステム全体に対応できる必要があります。

それから、私が想像していたのは、単にWeb自体のアーキテクチャーであることに気づきました。

だからここに私の議論のポイントがあります:(主に）テキストベースのプロトコルを使用するオーバーヘッドとは別に、複雑なバックエンドアーキテクチャを私が説明する方法で実装すべきではないという最優先の理由がありますか、または私がいくつかの強力な論理的根拠がありますTwisted、AMQP、Thriftなどの通信プロトコルを使用するためにmがありませんか？

更新：@meagarからのコメントに続いて、おそらく質問を再定式化する必要があります：明らかなパフォーマンスヒットを補うのに十分な、非常にシンプルで柔軟性があり、よく理解されているアーキテクチャ（つまり、一連のRESTful APIとして公開されているすべての機能）を使用することの明らかな利点ですこのアーキテクチャをバックエンドコンテキストで使用するときに発生しますか？

4

1 に答える 1

0

[コード]データベースの実際のタイプを置き換えることができます (SQL を KV に、またはその逆)。[/コード]

そして、2 つのテーブル間の結合を書いた人は悲しむでしょう。「機能」を KV に切り替える必要がある場合は、KV がサポートできるよりも豊富な API を公開しないでください。

あなたの質問に対する答えは、何を達成しようとしているのかによって異なります。各モジュールを妥当な範囲内に保ちたいと考えています。コードの適切な物理層を使用し、定義済みのインターフェイスを副作用コントラクトと共に使用し、各インターフェイスの成功および失敗ケースごとにテスト ケースを使用します。そうすれば、「ユーザーが何とかページに入ると、登録されているすべてのファクトリスナーが呼び出されるように、ユーザー何とかファクトが生成される」などに依存できます。これにより、ポイント A からポイント B への直接呼び出しを行わずにシステムを拡張できると同時に、大きく異なる依存関係を何らかの形で制御できます。(私はシンボルへのすべての可能な参照を見つけることができないコードベースが嫌いです!)

しかし、多くのコードとクラスを 1 つのシステムに入れているのは、システム間の呼び出しが非常に高価であることが多いためです。可能な場合は、コード モジュールが相互に要求を行うという観点から考えたいと思います。関数呼び出しと REST 呼び出しのタイミングの違いは、1 から 100 万のようなものです (ウォールクロック時間ではなくサイクルのみをカウントすると、1 から 1 万まで低くなる可能性がありますが、私はそうではありません)。承知しました）。また、どんなに頑張っても 100% 損失のないデータセンターなど存在しないため、データセンターで回線上を移動するものはすべて、潜在的にパケット損失を被る可能性があります。パケット損失は、アプリケーションの応答時間におけるランダムなレイテンシ スパイクを意味します。

于 2011-01-02T06:36:55.507 に答える