0

Cloud Foundry 用のクラスター化されたキャッシュ サービスを作成しようとしています。Service Broker API を実装する必要があることを理解しています。ただし、このサービスをクラスター化し、Cloud Foundry 環境で使用したいと考えています。ご存じのように、コンテナー間接続 (TCP) はまだサポートされていません。別の環境でバックエンドをホストしたくありません。

基本的に私の質問はこれとほぼ同じです: http://grokbase.com/t/cloudfoundry.org/vcap-dev/142mvn6y2f/distributed-caches-how-to-make-it-work-multicast

そして、私は彼がアドバイスしたこの解決策を達成しようとしています:

B) は、このドキュメント ページの下部にいくつかの例が示されているように、Service Broker API を実装して CF サービスを作成することです [1] 。サービスには固有のネットワーク制限はありません。そのため、クラスタ内でマルチキャストを使用する CF キャッシュ サービスを使用できます。次に、TCP などのアウトバウンド プロトコルを使用してこのクラスタに接続できるローカル キャッシュ クライアントをアプリに配置できます。

まず、このサービスはどこにありますか? DEAで？バックエンドの実装はブローカー自体に含まれますか? クラスターをスケーリングするためのバックエンドを実装するにはどうすればよいですか? 同じサービス ブローカーを最初からやり直しますか?

もう 1 つの非常に重要な質問は、TCP 接続がアプリに許可されていない場合、他のサービスはどのように機能するかということです。たとえば、MySQL サービスはアプリとどのように通信するのでしょうか?

4

2 に答える 2

1

これを解決するにはいくつかの方法があり、解決策が堅牢であるほど複雑になります。

最も簡単な解決策は、固定数のバックエンド キャッシュ サーバーを用意し、それぞれに固有のルートを設定し、クライアント アプリケーションがアプリケーション層でこれらのルートに (HTTP) マルチキャストを実装できるようにすることです。バックエンド キャッシュ サーバーを CF アプリケーションとして実行する場合、現時点では、すべてのソリューションで、アプリケーション層で HTTP マルチキャスト ロジックを実行するための何かが必要になります。

次のステップは、中間サービス ブローカーを導入することです。これにより、クライアント アプリはすべて 1 つのサービスにバインドするだけで、バックエンド キャッシュ サーバーのルートのリストを取得できます。したがって、バックエンドを展開し、バックエンドの情報を使用してサービス ブローカー API インスタンスを展開します。クライアント アプリがバインドされると、ユーザー提供のサービス メタデータでこの情報が取得されます。

バックエンドをスケールアップまたはスケールダウンするとどうなりますか? 次に、バックエンドが基本的にある種の中央メタデータ/構成/検出サービスに登録し、クライアントアプリがこのサービスにバインドされ、キャッシュサーバーリストのライブ更新を定期的に照会できる、より洗練されたものにすることができます.

別の方法として、マルチキャスト ロジックを単一の (クラスター化された) サービスに移動することもできます。

  • バックエンド キャッシュは config/metadata/discovery サービスに登録します
  • マルチキャスターは定期的にディスカバリー サービスにクエリを実行し、キャッシュ サーバー ルートのリストを取得します。
  • クライアント アプリは Multicaster サービスにリクエストを送信します

難点の 1 つは、自分でメタデータ サービスを実装する場合です。クラスター化する場合は、高可用性のような一貫性のあるデータストアを実装する必要があります。サービスがクラスター内のすべてのノードへのデータの複製を処理することを除いて、これはほとんど元の問題であり、その必要はありません。マルチキャスト。

于 2015-11-23T22:16:06.153 に答える