私はspring
を使っていましたが、spring boot
とマイクロサービスについて学びたいと思います。 microservice
とは何か、そしてそれがどのように機能するかを理解しています。ドキュメントを調べているうちに、microservices
とspring boot
の開発に使用される多くのものに出会いましたが、これは非常に混乱しています。
以下のシステムと質問をリストしました:
services
はeureka
サーバーに登録され、すべてのmicroservices
はeureka
クライアントです。私の疑問は、APIゲートウェイを持たずに、このサービスレジストリを使用することはできますか?これは、サービスレジストリの実際の使用方法を理解するためです。ZUULApiゲートウェイ-ZUULは、リクエストURLに対応する適切なマイクロサービスを呼び出すロードバランサーであるAPIゲートウェイとして使用できることを理解しています。その仮定は正しいですか? APIゲートウェイは、適切なマイクロサービスを取得するためにEurekaと対話しますか?
[〜#〜] nginx [〜#〜]-NGINX
もAPIゲートウェイとして使用できますか?それは可能ですか?また、NGINX
のようなサービスレジストリとして使用できる他の場所、つまりEurekaの代替としての場所も読んでいます!したがって、どちらが正しいですか? APIゲートウェイまたはサービスレジストリ、あるいはその両方? nginx
はウェブサーバーであり、reverse proxies
は強力に設定できることを知っています。
AWS APIゲートウェイ-これはZUUL
の代替としても使用できますか?
[〜#〜] ribbon [〜#〜]-ribbon
は何に使用されますか?分かりませんでした!
AWS ALB-これは負荷分散にも使用できます。したがって、AWS ALB
がある場合、ZUULが必要ですか?
助けてください
スプリングブーツに付属するmicroservices
の動作に使用できるさまざまなシステム:
ユーリカ:おそらく最初に起動したマイクロサービス。 Eurekaはサービスレジストリです。つまり、どのマイクロサービスがどのポートで実行されているかを把握しています。 Eurekaは別のアプリケーションとしてデプロイされており、@EnableEurekaServer
アノテーションと@SpringBootAPplication
を使用して、そのアプリをeurekaサーバーにすることができます。そのため、eurekaサービスの登録は稼働しています。これ以降、デプロイされたすべてのマイクロサービスで@EnableDiscoveryClient
アノテーションとともに@SpringBootAPplication
アノテーションを使用して、すべてのマイクロサービスがこのeurekaサーバーに登録されます。
Zuul:ZUULはload balancer
、routing
アプリケーション、およびreverse proxy
サーバーでもあります。これは、リバースプロキシにApacheを使用する前のことです。今では、マイクロサービスにはZUULを使用できます。利点は、ZUULでは、/ customer/*がこのようなマイクロサービスにアクセスする場合のように、プログラムで構成を設定できることです。また、ZUUL
はロードバランサーとしても機能し、ラウンドロビン方式で適切なマイクロサービスを選択します。 SO ZUULはどのようにしてマイクロサービスの詳細を知るのか、答えはeurekaです。マイクロサービスの詳細を取得するためにeureka
と連携して動作します。ここで@EnableDiscoveryClient
を使用してマークする必要があります。これが、これら2つのアプリ(Eurekaとzuul)のリンク方法です。
Ribbbon:負荷分散のためのリボンの使用。これはZUUL内ですでに利用可能です。zuulでは、負荷分散にリボンを使用しています。マイクロサービスは、プロパティファイルのサービス名で識別されます。異なるポートで1つのマイクロサービスの2つのインスタンスを実行する場合、これはEurekaによって識別され、リボン(Inside zuul)とともに、リクエストはバランスの取れた方法でリダイレクトされます。
AWS ALB、NGINX、AWS Apiゲートウェイなど:上記のすべてのものに代わるものがあります。 AWSには、独自のロードバランサー、サービス検出、APIゲートウェイなどがあります。 AWSだけでなく、Azureなどのすべてのクラウドプラットフォームがこれらを備えています。どちらを使用するかによります。
一般的な質問も追加する、これらのマイクロサービスが相互に通信する方法:Resttemplate
またはFeignclient
実際のREST APIを呼び出すことができますまたはRabbit MQ
などのようなメッセージキューを使用できます。
aPIゲートウェイがなくても、このサービスレジストリを使用できますか?
はい。たとえば、すべてのマイクロサービスの(IPおよびポート)を見つけるために使用できます。これは、devopsタイプの作業に役立ちます。たとえば、私が取り組んだあるプロジェクトで、Eurekaを使用してマイクロサービスのすべてのインスタンスを見つけ、それらのステータス(/ health、/ info)をpingしました。
ZUULは、リクエストURLに対応する適切なマイクロサービスを呼び出すロードバランサーであるAPIゲートウェイとして使用できることを理解しています。その仮定は正しいですか?
はい、しかしもっと多くのことができます。基本的に、Zuulはマイクロサービスに変換するフレームワーク/ライブラリであるため、それをコーディングして、思いつくあらゆる種類のルーティングロジックを実装できます。その意味で非常に強力です。たとえば、時刻やその他の外部要因に基づいてルーティング方法を変更したい場合、Zuulを使用するとできます。
aPIゲートウェイは、適切なマイクロサービスを取得するためにEurekaと対話しますか?
はい。ユーレカを指すようにZuulを構成します。 Eurekaのクライアントになり、リアルタイム更新(どのインスタンスが参加または離脱したか)のためにEurekaにサブスクライブします。
NGINXをAPIゲートウェイとして使用することもできます。また、私はNGINXのような他のサービスレジストリとして使用できる場所を読んでいます、それはユーレカの代替としてです!したがって、どちらが正しいですか? APIゲートウェイまたはサービスレジストリ、あるいはその両方?
Nginxは非常に強力であり、APIゲートウェイタイプの作業を実行できます。しかし、いくつかの大きな違いがあります。私の知る限り、マイクロサービスはNginxに動的に登録できません。間違っている場合は修正してください...ユーリカでできるように。第二に、Nginxが高度に(非常に高度に)設定可能であることは知っていますが、その設定機能はZuulのルーティング機能に近づかないと思われます(Zuul内で自由にJava言語を使用できるため) Nginxで動作するサービスディスカバリソリューションがある場合があります。そのため、Nginxがルーティングなどを処理しますが、サービスディスカバリにはソリューションが必要です。
これはZUULの代替としても使用できますか?
はい、AWS API Gatewayは、Zuulの種類の代替として使用できます。ここでの問題は、Nginxと同様に、サービスの発見です。 AWS API Gatewayを使用すると、ルーティングにロジックを適用できますが、Zuulほどオープンエンドではありません。
どのリボンに使用されますか?
リボンライブラリは直接使用できますが、ほとんどの場合、これをZuulの内部依存関係と見なします。これは、Zuulが行う単純な負荷分散を支援します。このプロジェクトはメンテナンスモードであり、推奨されないことに注意してください。
これは、負荷分散にも使用できます。したがって、AWS ALBがある場合、ZUULが必要ですか?
ECS(弾性コンテナサービス)でALBを使用して、Eureka/Zuulを置き換えることができます。 ECSがサービスの検出を行い、特定のサービスのすべてのインスタンスをターゲットグループにマッピングします。その後、ALBルーティングテーブルは、単純なルーティングルールに基づいてターゲットグループにルーティングできます。ただし、ALBのルーティングルールは非常に単純ですが、時間の経過とともに改善されます。