In diesem Artikel befassen wir uns mit den Profilen des WSO2 API Managers. Was sind sie und was bewirken sie? Sie werden lernen, wie Sie ein Profil als Teil einer verteilten Verteilung des API Managers optimieren können.
Carbon Core
Die WSO2-Produkte basieren größtenteils auf dem Carbon Core. Carbon Core ist ein Satz von Bibliotheken, der von (fast) allen Produkten von WSO2 verwendet wird. Es bietet eine Reihe von Funktionalitäten, die alle Produkte gemeinsam haben, wie z. B. Clustering-Funktionen, Benutzerverwaltung, aber auch Bundle-Verwaltung mit der Management UI. Diese Funktionen sind alle Teil des Core. Außerdem gibt es die funktionalen Komponenten, die das Produkt zu einem Enterprise Integrator, einem API Manager, einem Identity Server oder einem Streaming Processor machen.
Anders und gleich
Man könnte auch argumentieren, dass die Produkte vielleicht etwas mehr gemeinsam haben, als man denkt, vor allem wenn man über den API Manager und den Enterprise Integrator spricht. Beispielsweise ist die Zusammenarbeit zwischen den Produkten größer als man denkt. Der API Manager enthält beispielsweise einen Teil des Schlüsselmanagers, der auch in den Identity Server integriert ist. Der API-Manager und der Enterprise Integrator verwenden die gleiche Nachrichtenvermittlung (Synapse).
Der Unternehmensintegrator ist im Grunde ein Monolith. Er ist ein großer Funktionsblock, der auf seiner eigenen JVM gestartet wird, ohne die Möglichkeit, ihn in verschiedenen JVMs mit unterschiedlichen Funktionen einzurichten. Um vollständig und korrekt zu sein, wenn Sie den Enterprise Integrator betrachten, sind auch der Message Broker und der Business Process Server sowie die Analytik so, aber sie werden oder sollten als separate Produkte betrachtet werden. Sie werden stets auf ihrer eigenen JVM laufen.
Mit der monolithischen Natur des Enterprise Integrator und auch des Micro Integrator meine ich, dass diese Produkte als ein großer Block installiert werden. Beim API-Manager hingegen wird, obwohl er ähnliche Komponenten verwendet, ein Setup verwendet, das als verteilte Bereitstellung bezeichnet wird.
Ausführen von WSO2 API Manager
Wenn Sie die WSO2 API Manager-Zip-Datei herunterladen und ausführen, erhalten Sie im Grunde eine JVM, die alle fünf Komponenten des API Managers enthält: Publisher, Devportal, Key Manager, Traffic Manager und Gateway.
Deshalb können Sie eine verteilte Einrichtung für die verteilte Bereitstellung vornehmen, bei der jede dieser Komponenten in ihrer eigenen JVM-Umgebung ausgeführt werden kann. Dazu können Sie sie unter anderem mit einem so genannten Profil starten.
Was ist ein Profil?
Ein Profil ist eine definierte Konfiguration, die nur die OSGi-Bundles lädt, die sie zur Ausführung ihrer Funktionen benötigt, z. B. den Key Manager. Das heißt, dass die Bundles für die spezifische Funktionsweise dieser Komponente nicht notwendig sind, zum Beispiel wird die SYNAPSE-Konfiguration in diesem speziellen Fall nicht geladen. Die Folge ist natürlich, dass wir einen geringeren Speicherbedarf haben, weil wir statt aller jar-Dateien nur einige der jar-Dateien laden. Das kann ein Vorteil sein.
Aber wie kann man sehen, was tatsächlich in diesen Profilen enthalten ist?
Das werden wir jetzt herausfinden. Wie können wir also wissen, welche Profile für ein bestimmtes Produkt verfügbar sind? Das ist ganz einfach. Sie nehmen das Produkt und starten es z. B. in einer Terminalsitzung unter Linux, Sie können dies auch unter Windows tun (die Funktionalität ist auch für Windows verfügbar).
API Manager installieren
Ich gehe davon aus, dass Sie Java installiert haben (Java 8 oder Java 11, OpenJDK oder Oracle) und dass Sie JAVA_HOME eingestellt haben. Es gibt nun kein Hindernis mehr, das Sie daran hindern würde, den API Manager einzurichten und auszuführen. Falls Sie ihn noch nicht installiert haben, lesen Sie diesen Blog über die Installation von WSO2-Produkten.
Starten wir also den API Manager, indem wir eine sofort einsatzbereite Version auf dem Desktop entpacken. Mit den gerade beschriebenen Voraussetzungen können Sie den API Manager im Grunde mit einer Shell oder einem Batch-Skript starten, und er wird ausgeführt.
In unserem Fall werden wir dem API-Manager einen weiteren Parameter hinzufügen, und zwar den Parameter -DosgiConsole. Wie Sie also auf dem Screenshot sehen können, geben Sie einfach ein Leerzeichen und dann den zusätzlichen Parameter ein.
Danach werden Sie eine Meldung auf der Konsole sehen. Wenn das System startet, wird die OSGi-Konsole gestartet, die normalerweise die Schnittstelle zu den internen Abläufen des API-Managers darstellt.
Das heißt, dass Sie über die OSGI-Konsole einen Blick auf die geladenen Bundles, Einstellungen usw. werfen können. Sie ermöglicht es Ihnen, Bundles zu aktualisieren, zu sehen, was sich in einem Bundle an Java-Klassen befindet, und so weiter und so fort. Insgesamt gibt es über 20 Seiten mit Hilfebefehlen, die Ihnen alles zeigen, was Sie wissen müssen, und zwar auf einem sehr tiefen technischen Niveau.
Die OSGI-Konsole ermöglicht es Ihnen auch, einen Befehl einzugeben. Allerdings müssen Sie warten, bis der Befehl ausgeführt wurde. Andernfalls verdecken die Protokollmeldungen das, was Sie gerade eingeben. Wenn die Konsole anhält und die URL der Verwaltungsoberfläche angezeigt wird, können Sie im Terminal die Eingabetaste drücken, und wie von Geisterhand erscheint ein Cursor, mit dem Sie provlp eingeben können, und die Eingabetaste wird aktiviert.
Dadurch erhalten Sie die Profile, die sich derzeit im Produkt befinden. Wie Sie sehen können, gibt es eine Reihe von spezifischen Profilen, die sich auf die Operation beziehen. Zum Beispiel das API-Gateway als Arbeitsknoten, das Devportal, der Publisher, der Traffic Manager und der Key Manager und natürlich das Standardprofil, denn das Standardprofil wird verwendet, wenn kein Profil als Parameter hinzugefügt wird. Wenn Sie dem Befehl provlp ein Profil hinzufügen, werden die einzelnen Jars angezeigt (es wird nur eine kleine Anzahl angezeigt).
Somit wissen wir, dass ein bestimmtes Setup innerhalb eines Profils vorhanden ist. Wir können auch einen Blick in das Verzeichnis [APIM-HOME]/repository/components werfen, wo wir die Verzeichnisse für diese Profile sehen.
Für dieses Profil sind etwa 550 einzelne JARs aufgelistet. Als Format wird der Name des Jars, die Version und der Ort innerhalb der Verzeichnisstruktur angegeben. Dieser Überblick bietet mehr Informationen als die OSGI-Konsole. Die OSGI-Konsole zeigt jedoch eine Vielzahl zusätzlicher Befehle für die Arbeit mit Profilen an.
Optimierung eines Profils
Doch eine verteilte Bereitstellung ist mehr als nur die Aktivierung eines Profils. Die eigentliche Konfiguration zur Einrichtung der verteilten Bereitstellung (die in diesem Artikel nicht behandelt werden soll) steht vor der Profiloptimierung. Dazu müssen wir einige der Unterkomponenten entfernen oder auskommentieren, z. B. für den Publisher die JMS-Verbindung, WS-Transporte und eine Reihe anderer Dinge. Zum Glück muss dies nicht von Hand gemacht werden.
Profil einrichten
Wir können ein Skript verwenden, um die Änderungen vorzunehmen. Beim Ausführen des Skripts werden wir aufgefordert, eine große Anzahl von Dateien zu entfernen oder zu ändern. Wie man sieht, werden etwa 1800 Dateien aus dem Setup entfernt. Da es sich bei dem Skript um ein echtes Skript handelt und nicht um die Ausführung einer Java-Klasse, kann es leicht überprüft werden. Dies muss für alle Profile durchgeführt werden. Treesize ist ein großartiges Tool für Windows, mit dem Sie auf hohem Niveau sehen können, wo die Änderungen liegen.
Dies ist vor der Aktualisierung:
Und dies ist nach der Aktualisierung:
Sie können auch beim ersten Start optimieren. In diesem Fall verwenden Sie den folgenden Befehl:
wso2server.bat –optimize -Dprofile=api-publisher
Dieser Befehl muss ebenfalls für alle Profile ausgeführt werden.
Benutzerdefinierte Profile und Distributed Deployment
Mit den optimierten Einstellungen sind Sie nun bereit, mit einer dezentralen Bereitstellung fortzufahren. Wie bereits gesagt, würde dies den Rahmen dieses Blogs sprengen, da es einen erheblichen Arbeitsaufwand erfordert.
Es besteht auch die Möglichkeit, ein eigenes benutzerdefiniertes Profil zu erstellen, um ein bestimmtes Setup zu kombinieren, zum Beispiel Devportal und Publisher in einem. Es überrascht Sie vielleicht nicht, dass dies ebenfalls den Rahmen sprengt, da dieser Blog bereits recht umfangreich ist und es sich um ein fortgeschrittenes Thema handelt, das den Umfang des Blogs in Bezug auf die Anzahl der Wörter leicht verdoppeln würde.
Fazit
Wenn Sie den API-Manager in einer dezentralen Bereitstellung einsetzen möchten, ermöglicht Ihnen das Profil-Setup das automatische Entfernen oder Ausschließen von Komponenten, die nicht benötigt werden. Danach können Sie mit der Konfiguration des verteilten Einsatzes beginnen. Im Idealfall verwenden Sie ein Skript, um nicht jede Konfiguration von Hand vornehmen zu müssen.
Unglücklicherweise konnten wir nicht auf benutzerdefinierte Profile und verteilte Bereitstellung eingehen. In unseren Schulungen zum API Manager behandeln wir jedoch die verteilte Bereitstellung und benutzerdefinierte Profile (in Vorbereitung). Wenn Sie sich für diese Themen interessieren, werfen Sie einen Blick auf unseren Schulungsplan.