問題タブ [microservices]

私は、マイクロサービスとして展開される一連のアプリケーションに取り組んでいます。それぞれに個別のデータベースがあり、Apache Kafka のような単一の統合されたイベント ストア/ログを通じてデータを調整しようとしています。私は Kafka の実験を始めました。ほとんどのユーザーは、クラスタリングとかなり複雑なフォールト トレランスのセットアップを使用して、かなり大規模に kafka を使用しているようです。最初は特に大きなボリュームになるとは考えていないので、Kafka が正しい選択なのだろうか? これはカフカに適していますか、それとも現在の規模を考えると、より軽量な代替手段を検討する必要があります。

バックエンド コンポーネントの開発では、これらのコンポーネントがどのように相互作用し、相互に通信するかを決定する必要があります。特に、(RESTful、micro) Web サービスとメッセージ ブローカー (RabbitMQ など) を使用する方が良いかどうかを判断する必要があります。各コンポーネントに Web サービスを使用するか、メッセージングを使用するかを決定するのに役立つ特定の基準はありますか?

電子メールに関する情報を受信して​​送信する非常に単純な REST マイクロサービスを作成しました。マイクロサービスの send メソッドは次のようになります。

私のアプリケーションでは、次のように RestSharp を使用して呼び出します。

私が持っている質問:

1. これは電話をかけるのに最適な方法ですか? 明らかに、後でエラー処理などを追加する必要がありますが、RestSharp を使用して呼び出しを行う方法について詳しく説明しています。

2. マイクロサービスが受け取ることを期待しているオブジェクトをアプリが知る必要があるのは少し不快だと思います.確実に知るために使用する定義/インターフェイス/コントラクトのようなものはありません。これは一般的にRESTで問題ないと受け入れられているのでしょうか、それともアプリが持つある種のインターフェースを実装して、もう少し定義された方法でマイクロサービスを呼び出せるようにする必要がありますか。それはRESTでも可能ですか？

助けてくれてありがとう！

いくつかのコンポーネントに分かれている Web アプリケーションがあります。いくつかの理由 (価格) から、将来のコンポーネントを別のクラウドにデプロイすることを検討しています。

これが絶対に良くないかどうかを教えてくれる、これに関する参考文献と経験を持っている人はいますか? コンポーネントが異なるネットワークにあるとパフォーマンスが低下することはわかっています。同時に、新しいコンポーネントをどこに配置するかを選択する力を失うという考えは好きではありません。

マイクロサービス ベースのシステムはすべて同じネットワーク内にある必要がありますか? この問題をどのように処理しますか?

マイクロサービス アーキテクチャで swagger を使用することに興味があります。各マイクロサービスは .NET (WebApi2) で記述され、個別のアプリケーションです (ホストは同じですが、パスが異なるだけです)。理想的には、すべての API を記述する 1 つの Swagger 仕様が必要であり、これを使用してクライアント側の c# を生成し、これらの API のすべてのコンシューマーがモデルの定義とサービスの呼び出し元を持つようにします。

これは可能ですか？2.0以降だと読みましたが、具体的な例は見つかりませんでした。私はいくつかの .NET swagger ライブラリをいじり始めましたが、それらはすべてアプリ自体に swagger-ui をインストールしているようです。そのため、各マイクロサービスは効果的に独自の API をホストしています。

助けてくれてありがとう。

通常、メッセージパッシングを使用して、分離されたサービスにメッセージを送信します。これにより、(たとえば RabbitMQ の AMQP を使用して) ブローカーのルーティング機能を使用して、正しいサービスにフィードする正しいキューにメッセージをディスパッチできるため、サービス検出は問題になりません。負荷分散もメッセージ ブローカによって処理されます。

Kubernetes に入ります。

サービスのレプリケーションと失敗したサービスの再生成について話すときに通常提示される使用例は、クライアントが http などのアクティブなプロトコルを使用してサービスに接続する場合です (このサービスがリクエストを非同期的に処理する場合でも)。このコンテキストでは、サービスのグループとそれらの間の負荷を分散するための単一のエントリ ポイントを管理するレプリケーション コントローラーを用意するのが自然に適しています。

ローリング デプロイなど、kubernetes の直感的なコンセプトは気に入っていますが、http インターフェースを持たないこの野獣をどのように制御すればよいのでしょうか。

更新: メッセージ ブローカーのクラスターをセットアップしようとしていません。メッセージコンシューマをサービスとして見ています。サービス クライアントはサービスに直接接続せず、メッセージ ブローカーにメッセージを送信します。メッセージ ブローカは、ある意味でロード バランサとして機能し、サブスクライブされたキュー コンシューマにメッセージをディスパッチします。これらのコンシューマーがサービスを実装します。

私の質問は、デモのほとんどの使用パターンが http 経由で呼び出されるサービスを処理し、kubernetes がこれらのサービスのサービス プロキシとレプリケーション コントローラーを作成するためにうまく機能しているという事実に引き寄せられます。HTTP インターフェイス自体を持たず、ローリング アップデートのすべての利点と最小限のインスタンスを備えた、私の種類のサービス用のレプリケーション コントローラーを作成することは可能ですか?

マイクロサービスは、継続的な配信をより適切にサポートし、迅速な展開と関心の分離のモデルを提供するソフトウェア アーキテクチャ スタイルとして勢いを増しています。

Vert.x 3 と Vert.x-Apex は、マイクロサービスを構築するための興味深いモデルを提供します。例の 1 つが示すように、単純なバーティクルは HTTP サービスを公開できるため、REST サービスを利用できます。verticle は独自の TCP ポートをバインドします。

完全なアプリケーションをサポートするために複数のマイクロサービスにスケールアップする場合、多くの選択肢があります。最終的に継続的デリバリーをサポートし、アップグレードのダウンタイムを最小限に抑えることができるスタイルについて何か考えはありますか?

オプション

1. 複数のバーティクルを実行すると解決策になる可能性があり、すべてに独自のルーティングが含まれているため、http 処理はバーティクルに含まれています。リクエスト/レスポンスは、バーティクルで完全に処理できます。これは、すべての verticle が独自の tcp ポートで実行されることを意味する可能性があります。
2. ルーターを使用すると、単一のポートですべてのパスを公開し、それに応じて処理できます。データはルーターを含むバーチクルによって処理され、他のバーチクルに渡すことができます。これは、よりモノリシックなアプローチのように見え始めます。
3. サービスを含む vert.x の個別のインスタンスを実行します (それらをクラスター化する可能性があります)。全体が自己完結型であるため、これにより継続的デリバリーの使用が容易になる可能性があります。
4. 他の可能なオプション？

展開

展開側では、アプリケーション全体をダウンさせることなく、新しいサービスを迅速に展開することが望ましいでしょう。

• オプション 3. はこれを実現する方法を提供できますが、特にすべてのバーティクルで DB バーティクルが実行されている場合に、オーバーヘッドが発生する可能性があります。
• オプション 1. の方が簡単かもしれませんが、新しいバーティクルと更新されたバーティクルのリロードはどうでしょうか。

個別のマイクロサービスは興味深い開発方法を提供しますが、オーケストレーションと展開にはいくつかの課題があります。

何かご意見は？