Technologieaustausch

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Leistungsaufteilung:

1. Prinzip der Einzelverantwortung: In einer Microservice-Architektur sollte ein Dienst nur für eine Funktion oder einen Geschäftsbereich verantwortlich sein. Jeder Dienst sollte klare Definitionen und Grenzen haben und sich nur auf seinen eigenen spezifischen Geschäftsbereich konzentrieren.

2. Dienstautonomie: Dienstautonomie bedeutet, dass jeder Mikrodienst über ein hohes Maß an Autonomie verfügen sollte, d. h. jeder Dienst sollte unabhängig entwickelt, unabhängig getestet, unabhängig aufgebaut, unabhängig bereitgestellt und unabhängig betrieben werden können.

3. Einseitige Abhängigkeit

Zwischen Mikrodiensten muss eine einseitige Abhängigkeit bestehen. Zirkuläre Abhängigkeiten und bidirektionale Abhängigkeiten sind strengstens verboten.

Zirkuläre Abhängigkeit: A->B->C->A

Zweiseitige Abhängigkeit: A->B,B->A

Beispiel:

1. Bestellliste

2. Produktliste

Bestellservice: Bestell-ID angeben und Bestelldetails abrufen

Produktservice: Produktdetails basierend auf der Produkt-ID zurücksenden

Wenn Sie Bestellinformationen auf Grundlage einer Bestellung abfragen, erhalten Sie Produktdetails basierend auf der Produkt-ID in der Bestellung.

erreichen:

Umsetzungsidee: Der Bestelldienstdienst sendet eine http-Anfrage an den Produktdienstdienst, führt das zurückgegebene Ergebnis mit dem Bestellergebnis zusammen und gibt es an den Anrufer zurück

Implementierungsmethode: Verwendung von RestTemplate, bereitgestellt von Spring

1. Definieren Sie RestTemplate

@Aufbau

öffentliche Klasse BeanConfig{
@Bohne

öffentliche RestTemplate restTemplate{

gib ein neues RestTemplate() zurück;

      }

}

2. Verwenden Sie restTemplate im Order-Controller

RestTemplate:

Ausruhen(RePräsentation State Tranfer) repräsentiert die Übertragung des Layer-Ressourcenstatus

Ressourcen: Daten im Internet, wie Bilder, Videos, Texte etc. sind allesamt Ressourcen

Präsentationsschicht: Die Darstellungsform von Ressourcen (z. B. ist die Darstellungsform von Text TXT, die Darstellungsform von Bildern ist JPG und einige Ressourcen werden in JSON, XML oder Binär usw. ausgedrückt.)

Statusübertragung: Wenn wir über das Netzwerk auf Ressourcen zugreifen und die Ressourcen ausführen (hinzufügen, ändern, löschen usw.), ändert sich der Ressourcenstatus. Vereinfacht ausgedrückt: REST beschreibt eine Form der Interaktion zwischen Client und Server Das Netzwerk selbst ist nicht praktikabel, da die RESTful-API (Netzwerkschnittstelle im REST-Stil) nicht praktikabel ist.

Der erholsame Stil weist im Allgemeinen die folgenden Merkmale auf:

1. Ressourcen

2. Einheitliche Schnittstelle: Für Vorgänge an Ressourcen wie Abrufen, Erstellen, Ändern und Löschen entsprechen diese Fenster den vom http-Protokoll bereitgestellten Methoden GET, POST, PUT und DELETE. Mit anderen Worten, wenn Sie eine Schnittstelle im RESTful-Stil verwenden , über die Schnittstelle können Sie nur die Ressourcen finden, aber Sie haben keine Möglichkeit zu wissen, welche Vorgänge ausgeführt wurden. Sie müssen genau wissen, welche Vorgänge stattgefunden haben, und sie anhand des HTTP-Anforderungsmethodentyps beurteilen (z. B. dieselbe URL). : GET/blog/{blogId }: Blog abfragen (DELETE/blog/{blogId} Blog löschen)

Nachteile der RESTful-API:

1. Die Operationsmethode ist umständlich. Die RESTful-API unterscheidet die Operationsaktionen für Ressourcen normalerweise nach GET, POST, PUT und DELETE.
Die HTTP-Methode kann nicht direkt beobachtet werden und muss mithilfe von Tools wie der Paketerfassung beobachtet werden. Es ist intuitiver, wenn die Aktion auf der URL platziert wird.
Es fördert das Verständnis und die Kommunikation im Team.
2. Einige Browser sind bei der Unterstützung anderer Anfragen als GET und POST nicht sehr benutzerfreundlich und erfordern eine zusätzliche Verarbeitung.
3. Überbetonung der Ressourcen Die tatsächlichen Geschäftsanforderungen können jedoch komplexer sein und können nicht einfach durch Hinzufügen, Löschen, Ändern und Suchen erfüllt werden
Die RESTful-API wird die Entwicklungsschwierigkeiten und -kosten erhöhen.

Es gibt ein Problem mit dem Projekt
1. Beim Remote-Anruf sind die IP- und Portnummer der URL fest codiert (http://127.0.0.1:9090/product/). Wenn Sie die IP ändern, müssen Sie den Code ändern.
Code
2. Wie kann der Anrufer sich nicht auf die IP des Dienstanbieters verlassen?
3. Bereitstellung mehrerer Maschinen, wie kann der Druck geteilt werden?
4. Beim Tätigen von Remote-Anrufen ist es sehr leicht, die falsche URL zu schreiben, und die Wiederverwendbarkeit ist nicht hoch. Wie implementiert man Remote-Anrufe elegant?
5. Alle Dienste können diese Schnittstelle aufrufen. Gibt es Risiken?