Okay, lassen Sie uns weiter über den Aufsatz aus dem vorherigen Artikel sprechen. Im vorherigen Artikel haben wir erwähnt, dass wir uns nur auf die Spring Cloud -Konfiguration verlassen können, wenn wir alle Microservice -Konfigurationen aktualisieren und die Konfiguration ohne Neustart aktualisieren möchten. Wir müssen jedoch Postanfragen von einem Dienst an einen anderen senden.
Können wir es ertragen? Dies ist viel besser als der vorherige Mangel an Konfigurationszentrum. Wie können wir also weiterhin vermeiden, Postanfragen an den Service einzeln zu senden, um den Service zu informieren? Ihre Konfigurationsinformationen haben sich geändert und Sie müssen die Konfigurationsinformationen im Speicher rechtzeitig ändern.
Zu diesem Zeitpunkt sollten wir das Veröffentlichungsabonnementmodell der Nachrichtenwarteschlange nicht vergessen. Alle Dienste abonnieren diese Veranstaltung. Wenn sich dieses Ereignis ändert, können alle Microservices benachrichtigt werden, um ihre Speicherkonfigurationsinformationen zu aktualisieren. Zu diesem Zeitpunkt kann der Bus -Nachrichtenbus ihn lösen. Sie müssen nur eine Aktualisierung auf der SpringCloud -Konfigurations -Serverseite ausstellen, um alle Microservice -Updates auszulösen.
Wie im folgenden Architekturdiagramm gezeigt:
Spring Cloud Bus unterstützt nicht nur die automatisierte Konfiguration von Rabbitmq, sondern unterstützt auch Kafka, das inzwischen weit verbreitet ist. In diesem Artikel werden wir eine lokale Kafka -Umgebung aufbauen und versuchen, den Spring Cloud -Bus zu verwenden, um Kafka zur Implementierung der Funktion des Nachrichtenbusses zu unterstützen.
KAFKA wird mit Scala implementiert und als Pipeline für die aktive Streaming- und Betriebsdatenverarbeitung von LinkedIn verwendet und wird von vielen Internetunternehmen nun häufig als Datenstroming -Pipeline und Nachrichtensysteme verwendet.
Das Kafak -Architekturdiagramm lautet wie folgt:
Kafka ist ein Messaging -System, das basierend auf dem Message Publishing/Abonnement -Modus implementiert ist. Die Hauptdesignziele sind wie folgt:
1. Nachricht Persistenz: Bieten Sie die Leistungsverhaltensfunktion in einer Zeitkomplexität O (1) an, und sogar Daten über der TB -Ebene können die Zugriffsleistung mit konstanter Zeitkomplexität sicherstellen.
2. Hochdurchsatz: Es kann auch den Durchsatz von mehr als 100.000 pro Sekunde bei billigen kommerziellen Maschinen unterstützen
3.. Verteilt: Support -Nachrichten -Partitionierung und verteilten Konsum und sicherstellen Sie die Nachrichtenreihenfolge innerhalb der Partition
4. plattformübergreifend: Unterstützen Sie Kunden mit unterschiedlichen technischen Plattformen (z. B. Java, PHP, Python usw.)
5. Echtzeit: Unterstützen Sie Echtzeitdatenverarbeitung und Offline-Datenverarbeitung
6. Skalierbarkeit: Unterstützung der horizontalen Expansion
Einige grundlegende Konzepte, die an Kafka beteiligt sind:
1. BROKER: Ein Kafka -Cluster enthält ein oder mehrere Server, die als Makler bezeichnet werden.
2.Topisch: Logisch ähnlich wie bei der Warteschlange des Rabbits, muss jede Meldung, die an den Kafka -Cluster veröffentlicht wurde, ein Thema haben. (Nachrichten mit unterschiedlichen Themen werden separat gespeichert. Obwohl die logische Nachricht eines Themas auf einem oder mehreren Brokern gespeichert ist, muss der Benutzer nur das Thema der Nachricht angeben, um Daten zu produzieren oder zu konsumieren, ohne sich darum zu kümmern, wo die Daten gespeichert sind)
3. Partition: Die Partition ist eine Partition im physischen Konzept. Um den Systemdurchsatz bereitzustellen, wird jedes Thema physisch in eine oder mehrere Partitionen unterteilt, und jede Partition entspricht einem Ordner (Speichern des Nachrichteninhalts und der Indexdatei der entsprechenden Partition).
4.Producer: Nachrichtenproduzent, verantwortlich für das Erstellen von Nachrichten und das Senden an Kafka Broker.
5.Consumer: Nachrichtenverbraucher, Client, der Nachrichten an Kafka Broker liest und sie verarbeitet.
6. Konsumentengruppe: Jeder Verbraucher gehört zu einer bestimmten Gruppe (jeder Verbraucher kann als Gruppe angegeben werden, und wenn nicht angegeben, gehört er zur Standardgruppe). Die Gruppe kann verwendet werden, um Funktionen wie eine Nachricht zu implementieren, die von mehreren Mitgliedern in der Gruppe konsumiert wird.
Sie können aus dem Kafka -Architekturdiagramm sehen, dass Kafka Chookeeper -Unterstützung benötigt. Sie müssen angeben, wo sich Zookeeper in Ihrer Kafka -Konfiguration befindet. Es gewährleistet eine gewisse Zuverlässigkeit durch Zookeeper und ist der Meister und Sklave des Brokers. Wir müssen auch wissen, dass Kafka -Nachrichten in Themenform organisiert sind. Produzenten senden Themenformularmeldungen, und die Verbraucher werden nach Gruppen unterteilt, sodass eine Gruppe von Verbrauchern alle die gleichen Themenformularmeldungen benötigt. Auf der Serverseite stellt es auch einige Scherben her, sodass ein Thema auf verschiedenen Scherben verteilt werden kann, was uns erleichtert, mehrere Maschinen zu erweitern und bereitzustellen. Kafka ist natürlich verteilt. Zur Demonstration hier müssen wir nur die Standardkonfiguration verwenden und eine kleine Demo unter Windows erstellen.
Wir konzentrieren uns hauptsächlich auf die Unterstützung von Spring Cloud Bus für Kafka, was die Funktion des Nachrichtenbusses implementiert. Für bestimmte Kafka- und Rabbitmq -Nachrichtenwarteschlangen hoffen wir, Informationen zu finden, um sie selbst zu lernen. Mit einigen Konzeptunterstützung machen wir einige Demos.
Wie folgt: Erstellen Sie zunächst ein neues SpringCloud-Config-Client1-Modul, um unsere Tests zu erleichtern. Die eingeführten Abhängigkeiten sind wie folgt:
<De vorangestellt> <gruppe> org.springFramework.boot </GroupId> <artifactId> Spring-Boot-Starter-Actuator </artifactID> </abhängig> <Depopentcy> <gruppe> org.springFramework.boot </gruppe> <artifactid> Spring-boot-starter-web </artifactid> </abhängig> </artifactid> </artifactid> </artifactid> </artifactid> </artifactid> <CruupId> org.springFramework.cloud </GroupId> <artifactId> Spring-Cloud-Starter-Config </artifactId> <version> 1.4.0.Release </Version> </abhängig> <Epaptid> <gruppeIDID> org.springFramework.clud </gruppen> <artifactid> <artifactid> fed> <-artifactid> artifactid> artifactid> artifactid> artifactid> artifactid> artifactid> artifactid> artifactid> <version> 1.3.5.Release </Version> </abhängig> <abhängigkeit> <GroupId> org.springFramework.cloud </Groupid> <artifactId> Spring-Cloud-Starter-bus-kafka </artifactid> <version> 1.3.2.Release </Version> </abhängig> </abhängig>
Bitte beachten Sie anschließend, dass die Konfigurationsdatei von Client1 in Bootstrap.yml geändert werden sollte, da dieses Konfigurationsformat bevorzugt wird. Wie im vorherigen Aufsatz erwähnt, lautet die Konfiguration von Client1 wie folgt:
Server: Port: 7006Spring: Anwendung: Name: Cloud-Config Cloud: Konfiguration: #Whe Umgebung wird zum Starten verwendet? Dev repräsentiert die Entwicklungsumgebung. Dies hängt mit dem Suffix der Datei in Ihrem Lagerhaus zusammen. Das Benennungsformat der Warehouse-Konfigurationsdatei lautet beispielsweise Cloud-config-dev.properties. Daher muss das Profil geschrieben werden. Service-ID: config-server#Register Center Eureka: Client: Service-URL: DefaultZone: http: // localhost: 8888/eureka/, http: // localhost: 8889/eureka/#Muss die Berechtigung gezogen werden? Der Standard ist wahr. Wenn Sie nicht falsch sind, dürfen Sie nicht den von der Konfigurationszentrum Serververwaltung aktualisierten Inhalt abziehen: Sicherheit: aktiviert: false
Dann starten Sie die Klasse wie folgt:
@SpringBootApplication@enablediscoveryClientPublic client1Application {public static void main (String [] args) {SpringApplication.run (client1Application.class, args); }}Weisen Sie dann eine Kopie des TestController im Client1 zu. Der Code lautet wie folgt:
@RastController // Die Eigenschaften hier können aktualisiert werden. Wenn sich das Konfigurationszentrum in Git ändert, muss sie aktualisiert werden. Ohne diese Annotation kann die Konfiguration nicht rechtzeitig aktualisiert werden. @Value ("$ {älter}") Private Ganzzahl; @RequestMapping ("/test") public String test () {return this.name+this.age; }}Fügen Sie dann im vorherigen Aufsatz die folgende Konfiguration zum Konfigurationsserver im Modul hinzu:
#Wenn die Erlaubnis zum Ziehen erforderlich ist, ist die Standardeinstellung wahr. Wenn Sie nicht falsch sind, dürfen Sie nicht den von der Konfigurationszentrum Serververwaltung aktualisierten Inhalt abziehen: Sicherheit: aktiviert: false
Als nächstes müssen wir eines tun: Konfigurations-Client, Config-Client1 und Config-Server müssen KAFKA-Abhängigkeiten wie folgt einführen:
<De vorhöhe> <gruppe> org.springframework
Unser Projekt ist fertig, also werden wir es vorerst hierher bringen. Lassen Sie uns Kafka unten installieren und herunterladen. Zunächst besuchen wir die offizielle Kafka -Website kafka.apache.org/downloads, um zur empfohlenen Version auf der offiziellen Website zu gehen.
Zunächst geben wir das heruntergeladene Kafka-Verzeichnis ein und bearbeiten Kafka-Run-Class.bat unter kafka_2.11-1.1.0/bin/window wie folgt:
Finden Sie diese Konfiguration wie folgt:
Kopieren Sie den Code wie folgt: Setzen Sie den Befehl =%Java%%Kafka_heap_opts%%Kafka_jvm_performance_opts%%Kafka_JMX_OPTS%%Kafka_log4j_opts%-CP%classpatps%%%%*%*
Sie können sehen, dass % ClassPath % keine doppelten Zitate hat.
Daher können Sie es in doppelte Zitate einschließen, sonst kann es nicht gestartet werden. Es wird berichtet, dass Ihr JDK nicht ordnungsgemäß installiert ist. Nach der Änderung ist es wie folgt:
Copy the code as follows: set COMMAND=%JAVA% %KAFKA_HEAP_OPTS% %KAFKA_JVM_PERFORMANCE_OPTS% %KAFKA_JMX_OPTS% %KAFKA_LOG4J_OPTS% -cp "%CLASSPATH%" %KAFKA_OPTS% %*
Öffnen Sie anschließend den Server.properties im Konfigurationsordner und konfigurieren Sie es wie folgt:
Sie können sehen, dass es mit dem örtlichen Zookeeper verbunden ist.
Dann beginnen wir zuerst Zookeeper und dann Kafka wie folgt:
Wenn Sie die oben genannten Informationen sehen, zeigt dies, dass das Start von Zookeeper erfolgreich ist. Anwesend
Starten Sie als nächstes wie folgt Kafka mit einem anderen CMD:
Wenn Sie diese Informationen sehen, wurde Kafka erfolgreich gestartet
OK, starten wir das vorherige Projekt, zwei Registrierungszentren, ein Springcloud-Config-Server, zwei Springcloud-Config-Client und SpringCloud-Config-Client1.
Sie können sehen, dass SpringCloudbus auf der 0 -Shard ist. Wenn die obigen Informationen in beiden Konfigurationen angezeigt werden, zeigt dies, dass das Startup erfolgreich ist.
OK, jetzt zugreifen wir wie folgt auf die Seite der Konfigurationserver:
Besuchen Sie zwei weitere Kunden wie folgt:
Okay, die Show hat begonnen. Jetzt gehen wir zum Git -Repository, um die Konfigurationszentrumendatei zu ändern und das Alter wie folgt auf 24 zu ändern:
Als nächstes verwenden wir Aktualisierung, um die Konfigurationsserverkonfiguration zu aktualisieren und die beiden Clients zu benachrichtigen, um die Konfigurationsinformationen im Speicher zu aktualisieren. Verwenden Sie Postbote, um Localhost: 7000/Bus/Aktualisierung zu senden, wie folgt:
Sie können sehen, dass keine Informationen zurückgegeben werden, aber keine Sorge, dies ist eine erfolgreiche Benachrichtigung an alle Kunden, um die Informationen im Speicher zu aktualisieren.
Anschließend werden Konfigurationsserver und zwei Clients erneut anerlen, um die Seite zu aktualisieren, und das Ergebnis lautet wie folgt:
Die beiden Kunden sind wie folgt:
Sie können sehen, dass alle Clients die Konfigurationsinformationen automatisch im Speicher aktualisieren.
Bisher hat die oben genannte Konfigurationsinformationen aktualisiert. Es ist auch in Ordnung, wenn wir die Konfigurationsinformationen eines bestimmten Dienstes aktualisieren möchten. Wir können den Aktualisierungsbereich wie folgt angeben:
Geben Sie den Aktualisierungsbereich an
Im obigen Beispiel auslösen /refresh wir andere Serviceinstanzen im Bus, indem wir die Schnittstelle zum Frühjahr Cloud Bus /bus/refresh von der Serviceinstanz anfordern. In einigen speziellen Szenarien (wie der Veröffentlichung von Graustufen) hoffen wir jedoch, die Konfiguration einer bestimmten Instanz im Microservice zu aktualisieren.
Der Spring Cloud -Bus bietet auch eine gute Unterstützung für dieses Szenario: /bus/refresh bietet auch destination , um die spezifische Anwendung zum Aktualisieren zu finden. Zum Beispiel können wir /bus/refresh?destination=服务名字:9000 . Zu diesem Zeitpunkt bestimmt jede Anwendungsinstanz im Bus, ob es sich um einen eigenen Instanznamen handelt, der auf dem Wert destination basiert.
Wenn die Konfiguration erfüllt ist, wird die Konfiguration aktualisiert. Wenn die Konfiguration nicht übereinstimmt, wird die Nachricht ignoriert.
Zusätzlich zur Positionierung bestimmter Instanzen können destination auch verwendet werden, um bestimmte Dienste zu positionieren. Das Prinzip der Positionierungsdienste wird durch die Verwendung von Spring's Pathmatecher implementiert, z. B. /bus/refresh?destination=customers:** , wodurch alle Instanzen des customers -Dienstes zum Aktualisieren ausgelöst werden.
Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, es wird für das Lernen aller hilfreich sein und ich hoffe, jeder wird Wulin.com mehr unterstützen.