通常、アプリケーション開発者は、たとえば J2EE を例にとると、アプリケーションを設計する際にインフラストラクチャ関連の問題を優先しません。従来のプログラム不可能なインフラストラクチャと連携するのは困難です。従来のアプローチは、JBoss などのアプリ サーバーで実行できる .war ファイルを作成することです。Spring などの従来のフレームワーク (Spring Cloud の新しいフレーバーを除く) は、これを前提としています。たとえば、Kubernetes によって提供されるフォールト トレラントでエラスティックなデプロイ ランタイムが利用可能である場合、同じ方法でビジネス アプリケーションを作成すると、ランタイムによって提供されるスケジューリングなどの機能が無視されるように思われます。具体的な質問: アプリケーションがランタイム (つまり、Kubernetes、Mesos など) API から通信する (そして利益を得る) のは一般的ですか? もしそうなら、良い例を挙げていただけますか。
1 に答える
5
いいえ、Kubernetes のポイントは、アプリが Kubernetes を「認識する」必要がないことです。(Mesos には、「アプリは私たちについて知る必要がある」という哲学があります。)
Kubernetes では、各ポッドが起動し、ポートでリッスンします。アプリはその存在を登録せず、バージョンも通知しません。別のサービスと通信する必要がある場合、DNS (または固定サービス IP) を使用して、そのダウンストリーム サービスの LB を見つけます。
通常、アプリケーション開発者は、アプリケーションを設計する際にインフラストラクチャ関連の問題を優先しません。
一般に、心配すべき点は次の 2 つだけです。
1) サービスをステートレスにして、状態をエッジ (データベースおよび/またはクライアント) にプッシュします。これにより、Kubernetes はより多くのコピーを実行してアプリを「スケーリング」できます。ステートフル サービスのスケーリングはほぼ不可能です。
2) アプリを複数の「マイクロサービス」に分割して、「顧客ログイン」機能をスケーリングせずに「製品ビュー」機能をスケーリングできるようにします。
3) オプション: 12factorアプリに向かいます。
于 2016-02-03T07:10:27.770 に答える