Vorwort
Jetzt nehmen immer mehr Unternehmen Spring Cloud an. Spring Boot ist die nächste Generation von Web Frameworks und Spring Cloud ist führend in den neuesten und beliebtesten Microservices. Welchen Grund müssen Sie ablehnen? Viele Schüler in Java haben auch begonnen, die Frühlingswolke aktiv zu lernen. Tatsächlich gibt es hier ein weiteres Problem: Obwohl jeder Eureka, Ribbon, Hytrix, Zuul, Täuschung usw. gelernt hat, ist es immer noch schwierig, es auf tatsächliche Projekte anzuwenden.
Die Schwierigkeit von Microservices liegt in der Aufteilung von Diensten. Framework ist nur ein Werkzeug, und viele Menschen werden es benutzen. Service -Aufteilung und die Beziehung zwischen Diensten sind Dinge, die während der Aufteilung berücksichtigt werden müssen.
Heute hat mir ein Klassenkamerad eine E -Mail geschickt, um mir die folgenden zwei Fragen zu stellen:
Hier sind einige Antworten, die auf meiner eigenen Erfahrung basieren, nur als Referenz:
In Bezug auf die API in der ersten Frage steht der Controller unter jedem Microservice?
Was wir API nennen, ist tatsächlich eine Schnittstelle, und die meisten von ihnen werden mit Spring MVC entwickelt, eine kommentierte Methode im Controller. Anmerkungen sind diejenigen, die wir oft verwenden:
Benötigt in Bezug auf die erste Frage ein einheitliches Projekt, um den Controller anderer Microservices zu verkörpern?
Es gibt tatsächlich kein festes Muster. Das meiste davon wird direkt über das API -Gateway an Ihre Geschäftsdienste weitergeleitet
Nehmen Sie die Geschäftskategorie von Blog -Websites wie Yuantiandi als Beispiel:
Es gibt eine Geschäftsfunktion. Wenn ich bestimmte Blog -Beiträge sehe, sind die Informationen, die ich zurückgeben muss, wie folgt:
Zu diesem Zeitpunkt umfasst unsere Schnittstelle zum Anzeigen des Artikels drei Teile von Daten, die Informationen des Artikels selbst, die Kommentarinformationen und die Informationen des Autors.
Es gibt 3 Dienste, Benutzerdienste, Blog -Dienste und Kommentardienste
Die Frage ist also, dass es die Interaktion zwischen mehreren Diensten zuvor betrifft. Tatsächlich hat mir die gleiche Frage wie der Klassenkamerad gefragt. Muss ich ein einheitliches Projekt haben und andere Dienste zusammenstellen? Können sie sich gegenseitig genannt werden?
Ich empfehle zwei Möglichkeiten, dies zu implementieren:
1. Das API -Gateway leitet direkt in den Blog -Dienst weiter
Unsere API ist eine Schnittstelle zum Erhalten von Blog -Postinformationen. Der Hauptteil muss der Blog -Service sein. Im Blog -Service gibt es eine Schnittstelle für Blog -Postinformationen. In der Schnittstelle rufen wir die vom Benutzerdienst bereitgestellte Benutzerinformationsschnittstelle an und rufen auch die Blog -Post -Kommentarinformationen im Kommentardienst auf. Lassen Sie uns den Pseudo -Code sehen:
@Getmapping ("/blog/detail/{id}") public blogInfo blogInfo (@PathVariable ("id") Long id) {// Blog -Informationsblog -Blog = blogService.getbyid (id); // Benutzerinformationen userInfo userInfo = userFeignClient.getUserInfo (blog.getUerid ()) abrufen; // Kommentarinformation Kommentar kommentinfo commentInfo = commentFeignclient.getCompmentInfo (ID); Beben Sie alle Informationen zusammen und senden Sie zurück. }2. Fügen Sie eine Aggregations -Serviceschicht hinzu
Die Sammlungsserviceschicht ist der oben genannte Klassenkamerad. Ist es erforderlich, ein einheitliches Projekt zu haben, um Assemblerdienste durchzuführen? Dies bedeutet, dass unser Blog -Dienst weiterhin grundlegende Blog -Informationen bereitstellt und ein separater Geschäftsaggregationsdienst hinzugefügt wird, um diese Informationen zusammenzustellen und sie gleichmäßig an den Anrufer zurückzugeben. Der Pseudo-Code lautet wie folgt:
@Getmapping ("/blog/detail/{id}") public blogInfo blogInfo (@PathVariable ("id") Long id) {// Blog -Informationsblog -Blog = blogFeignclient.getbyid (id); // Benutzerinformationen userInfo userInfo = userFeignClient.getUserInfo (blog.getUerid ()) abrufen; // Kommentarinformation Kommentar kommentinfo commentInfo = commentFeignclient.getCompmentInfo (ID); Beben Sie alle Informationen zusammen und senden Sie zurück. }Daten werden remote bezeichnet. Natürlich können Sie es hier parallel nennen. Eine andere Möglichkeit besteht darin, den Aggregationsbetrieb im API -Gateway durchzuführen. Diese Lösung ist auch machbar. Ich schlage vor, es nicht im Tor zu tun. Das API -Gateway ist so einfach wie möglich und nur vorwärts. Das Hinzufügen der Aggregations -Serviceschicht ist eine gute Wahl.
Wenn Ihre Service -Governance mit Dubbo gebaut wird, ist die Aggregations -Serviceschicht auch eine bessere Methode. Die Dubbo Service Aggregation bietet die HTTP -Schnittstelle für externe Anrufe.
3. Der Anrufer erhält verschiedene Daten alleine
Eine andere Möglichkeit besteht darin, die Blog -Oberfläche, die Kommentarinterface und die Benutzeroberfläche selbst anzurufen. Auf diese Weise muss die Schnittstelle nur auf ihre eigenen Daten achten und das Montageproblem dem Benutzer übergeben. Dies wird im Allgemeinen weniger verwendet. Es ist am besten, die Daten gleichzeitig an den Anrufer zurückzugeben und sie wiederholt anzurufen, insbesondere am mobilen Terminal, was zu viele Anfragen erfordert und den Verkehr verschwendet.
Zusammenfassen
Wie Sie die Daten zusammenstellen, müssen Sie sie selbst entscheiden. Sie können die Montage in den entsprechenden Geschäftsdiensten einfügen oder einen Aggregationsdienst hinzufügen, um sie separat zusammenzustellen, oder den Kunden sie selbst zusammenstellen lassen.
Dienstleistungen können definitiv einander genannt werden. Wenn sie sich nicht gegenseitig genannt werden können, was bedeutet dann, sie auseinander zu brechen? Verwenden Sie vorgegeben, um die Serviceschnittstelle anzurufen, und Sie behandeln sie nur als Anruf zwischen Diensten.
Okay, das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Referenzwert für das Studium oder die Arbeit eines jeden hat. Wenn Sie Fragen haben, können Sie eine Nachricht zur Kommunikation überlassen. Vielen Dank für Ihre Unterstützung bei Wulin.com.