序文
現在、ますます多くの企業がスプリングクラウドを受け入れています。 Spring Bootは次世代のWebフレームワークであり、Spring Cloudは最新かつ最も人気のあるマイクロサービスのリーダーです。どんな理由を拒否しなければなりませんか？ Javaの多くの学生も、Spring Cloudを積極的に学び始めています。実際、ここには別の問題があります。誰もがユーレカ、リボン、ヒストリックス、ズール、装備などを学んだが、実際のプロジェクトに適用することは依然として困難です。
マイクロサービスの難しさは、サービスの分割にあります。フレームワークは単なるツールであり、多くの人がそれを使用します。サービスの分割とサービス間の関係は、分割中に考慮する必要があるものです。
今日、クラスメートが私にメールを送ってくれました。
参照のみのために、私自身の経験に基づいたいくつかの答えが次のとおりです。
最初の質問のAPIに関して、各マイクロサービスの下のコントローラーは？
私たちがAPIと呼ぶものは実際にはインターフェイスであり、それらのほとんどは、コントローラーで注釈付きの方法であるSpring MVCを使用して開発されています。注釈は、私たちがよく使用するものです。
最初の質問に関しては、他のマイクロサービスのコントローラーをカプセル化するために統一されたプロジェクトが必要ですか？
実際には固定パターンはありません。これのほとんどは、APIゲートウェイを介してビジネスサービスに直接転送されます
YuantiandiのようなブログWebサイトのビジネスカテゴリを例にとってください。
ビジネス機能があります。特定のブログ投稿を見るとき、返す必要がある情報は次のとおりです。
この時点で、記事を表示するためのインターフェイスには、実際には、記事自体の情報、コメント情報、および著者の情報、実際に3つのデータが含まれています。
3つのサービス、ユーザーサービス、ブログサービス、コメントサービスがあります
したがって、問題は、以前の複数のサービス間の相互作用を伴うことです。実際、上記のクラスメートと同じ質問が私に尋ねました。統一されたプロジェクトがあり、他のサービスを組み立てる必要がありますか？彼らはお互いに呼ばれることができますか？
これを実装するには2つの方法をお勧めします。
1.APIゲートウェイはブログサービスに直接転送します
私たちのAPIは、ブログ投稿情報を取得するためのインターフェイスです。本体はブログサービスでなければなりません。ブログサービスにブログ投稿情報のインターフェイスがあります。インターフェイスでは、ユーザーサービスが提供するユーザー情報インターフェイスに電話し、コメントサービスのブログ投稿コメント情報も呼び出します。擬似コードを見てみましょう：
@getMapping（ "/blog/detail/{id}"）public bloginfo bloginfo（@pathvariable（ "id"）long id）{// get blog情報ブログ= blogservice.getbyid（id）; // get user information userinfo userinfo = userfeignclient.getuserInfo（blog.getuserid（））; //コメント情報commentinfo commentinfo = commentfeignclient.getCommentInfo（ID）;返品すべての情報を組み立てて返品します。 }2.集約サービスレイヤーを追加します
コレクションサービスレイヤーは上記のクラスメートですが、アセンブリサービスを行うために統一されたプロジェクトが必要ですか？これは、ブログサービスが依然として基本的なブログ情報を提供しており、この情報を組み立てて発信者に均一に返すために、別のビジネス集約サービスが追加されていることを意味します。擬似コードは次のとおりです。
@getMapping（ "/blog/detail/{id}"）public bloginfo bloginfo（@pathvariable（ "id"）long id）{// get blog情報ブログ= blogfeignclient.get.getbyid（id）; // get user information userinfo userinfo = userfeignclient.getuserInfo（blog.getuserid（））; //コメント情報commentinfo commentinfo = commentfeignclient.getCommentInfo（ID）;返品すべての情報を組み立てて返品します。 }データはリモートで呼ばれます。もちろん、ここでは並行して呼び出すことができます。別の方法は、APIゲートウェイで集約操作を実行することです。このソリューションも実現可能です。ゲートウェイではしないことをお勧めします。 APIゲートウェイは可能な限りシンプルで、前方のみです。集約サービスレイヤーを追加することは良い選択です。
サービスガバナンスがDubboで構築されている場合、集約サービスレイヤーもより良い方法です。 Dubbo Service Aggregationは、外部呼び出しにHTTPインターフェイスを提供します。
3.発信者は、自分でさまざまなデータを取得します
別の方法は、ブログインターフェイスを呼び出し、コメントインターフェイス、ユーザーインターフェイス自体を呼び出すことです。このようにして、インターフェイスは独自のデータに注意を払い、アセンブリの問題をユーザーに引き渡すだけです。これは通常、使用されません。一度に発信者にデータを返し、特にモバイル端末で繰り返し呼び出すことが最善です。
要約します
データを組み立てる方法については、自分でそれを決定する必要があります。アセンブリを対応するビジネスサービスに配置したり、集約サービスを追加して個別に組み立てたり、クライアントに単独で組み立てさせたりできます。
サービスは間違いなくお互いと呼ばれることができます。彼らがお互いに呼ばれることができない場合、彼らをバラバラにすることのポイントは何ですか？ feignを使用してサービスインターフェイスを呼び出すと、サービス間の呼び出しとして扱うだけです。
さて、上記はこの記事のコンテンツ全体です。この記事の内容には、すべての人の研究や仕事に特定の参照値があることを願っています。ご質問がある場合は、メッセージを残してコミュニケーションをとることができます。 wulin.comへのご支援ありがとうございます。