Autor: Zen und die Kunst der Computerprogrammierung
1. Einleitung
Mit dem zunehmenden Wachstum von Internetanwendungen, der Reifung verteilter Systemtechnologie, dem Aufstieg von Cloud-Computing-Plattformen und der zunehmenden Datenmenge werden die internen Informationssysteme von Unternehmen immer komplexer und es wird für sie immer schwieriger Anwendungssystem zur Unterstützung der schnellen Entwicklung und Iteration des Unternehmensgeschäfts. . Um dieses Problem zu lösen, veröffentlichte die Internationale Organisation für Normung (ISO) im September 2001 die serviceorientierte Architektur (SOA) als Servicestandard.
Der Hauptzweck der SOA-Architektur besteht darin, durch die Integration von Kommunikationsdiensten zwischen Anwendungskomponenten in einer einheitlichen Plattform eine „Entweichung von Informationssystemen“ zu erreichen, um die Effizienz zu verbessern, Wartungskosten zu senken und Risiken bei der Systembereitstellung zu verringern.
Die SOA-Architektur kann in drei Ebenen unterteilt werden:
Serviceschicht: Die äußerste Schicht in der SOA-Architektur, die funktionale Dienste bereitstellt, einschließlich Geschäftsregeln, Transaktionsverarbeitung, Sicherheit, Berichtserstellung, Abfrage und Analyse usw.;
Nachrichtenschicht: Die mittlere Schicht dient zur Verwaltung des Nachrichtenflusses zwischen Diensten, einschließlich Nachrichtenweiterleitung, Orchestrierung, Konvertierung, Kodierung, Verschlüsselung, Signatur usw.;
Plattformschicht: Infrastrukturschicht, einschließlich Hardwareressourcen, Netzwerk, Datenspeicher, Middleware, Entwicklungsumgebung, Testumgebung, Produktionsumgebung usw.;
Auf der SOA-Architektur basierende Anwendungssysteme umfassen im Allgemeinen mindestens die folgenden Dienste:
Datendienste: Verwaltung von Geschäftsdaten, wie Auftragsverwaltung, Bestandsverwaltung, Lieferantenverwaltung usw.;
Anwendungsdienste: Implementierung spezifischer Geschäftslogik, z. B. Kassiererverwaltung, Inkassoverwaltung, Verkaufsverwaltung usw.;
Schnittstellendienst: die interaktive Schnittstelle zwischen externen Anwendungen und Dienstsystemen, einschließlich WebService, RESTfulAPI, SOAP usw.;
Integrationsdienste: Integrieren Sie verschiedene Anwendungssysteme, einschließlich ERP, CRM, HCM usw.;
Authentifizierungs- und Autorisierungsdienste: Bereitstellung von Benutzerauthentifizierungs- und Zugriffskontrollmechanismen;
Managementdienste: Überwachung, Statistik, Alarmierung usw. des gesamten Systembetriebs;
Derzeit ist SOA ein gängiges Architekturmodell für den Aufbau von Anwendungssystemen auf Unternehmensebene. Viele große Unternehmen haben die SOA-Architektur übernommen oder sind dabei, sie einzuführen. Darüber hinaus gibt es im In- und Ausland zahlreiche SOA-bezogene Schulungen, Foren, Bücher, Tools und andere Ressourcen, von denen jeder lernen kann. Im Folgenden werde ich eine kurze Einführung in die SOA-Architektur geben.
2. Erläuterung grundlegender Konzepte und Begriffe
2.1 Was ist SOA?
SOA (Service-Oriented Architecture) ist eine serviceorientierte Architektur. SOA ist ein Architekturmuster, das eine Reihe von Diensten definiert, die unterschiedliche Funktionen und Anforderungen von Unternehmens-IT-Systemen umfassen und gemäß Geschäftsprozessen oder bestimmten Geschäftsprotokollen zusammenarbeiten und über bestimmte leichtgewichtige Protokolle miteinander kommunizieren. Diese Kommunikation kann Anrufe und den Datenaustausch zwischen verschiedenen Diensten einfach und effizient gestalten. SOA unterteilt Unternehmensanwendungssysteme in verschiedene Serviceeinheiten. Jede Serviceeinheit ist für die Erledigung bestimmter Aufgaben verantwortlich und verbindet diese Serviceeinheiten dann zu einem Ganzen. In der SOA-Architektur besteht ein Anwendungssystem aus mehreren Diensten, und Dienste kommunizieren über genau definierte Schnittstellen. Dadurch kann die Modularität, Robustheit und Skalierbarkeit des Systems erreicht werden.
2.2 Warum wird SOA benötigt?
Das traditionelle monolithische Anwendungsmodell weist die folgenden Probleme auf:
- Hoher Grad an Systemkopplung: Sobald ein Modul ein Problem hat, kann das gesamte System nicht mehr laufen.
- Schlechte Skalierbarkeit: Wenn die Größe des Anwendungssystems zunimmt, wird es sehr schwierig, neue Module hinzuzufügen, zu ersetzen oder zu ändern.
- Das System ist schwer zu verstehen und zu warten: Das Anwendungssystem wird komplex und schwer zu verstehen und zu warten;
- Niedrige Code-Wiederverwendungsrate: Es wird weniger Code im System wiederverwendet.
- Zu viele Module erschweren die Entwicklung: Jedes Mal, wenn ein Modul hinzugefügt wird, müssen Entwickler viel Zeit und Energie aufwenden;
- Hohe Testkosten: Der Mangel an effektiven Testlösungen macht es schwierig, die Qualität des Systems zu gewährleisten;
- Geringe Einführungseffizienz: Das Anwendungssystem ändert sich häufig und der Einführungszyklus ist lang, was sich auf die Produkt- und Marktförderung auswirkt.
- Anhäufung technischer Schulden: Technische Schulden wie Anwendungssystemarchitektur, Entwicklungstools und Programmiertechniken häufen sich.
Daher ist SOA erforderlich, um die oben genannten Probleme zu lösen.
2.3 Die Rolle der SOA-Architektur
Zu den Funktionen der SOA-Architektur gehören:
Reduzieren Sie die Systemkomplexität: Durch die SOA-Architektur können komplexe Systeme in unabhängige Dienste aufgeteilt werden, wodurch sie einfacher zu verstehen und zu warten sind.
Verbessern Sie die Systemzuverlässigkeit: Durch die SOA-Architektur können Dienste zentral verwaltet werden, um die Systemzuverlässigkeit zu verbessern.
Verbessern Sie die Skalierbarkeit des Systems: Durch die SOA-Architektur kann die Kapazität des Systems einfach erweitert werden;
Förderung der Wiederverwendung von Diensten: Die SOA-Architektur kann die Wiederverwendung von Diensten fördern und eine wiederholte Entwicklung vermeiden.
Bequeme Kommunikation von Produkten und Projekten: Die SOA-Architektur ermöglicht hochautomatisierte Entwicklung, Tests, Bereitstellung, Betrieb und andere Aspekte von Produkten und Projekten und fördert die Interoperabilität zwischen Informationssystemen;
Verbessern Sie die Flexibilität der Organisationsstruktur: Die SOA-Architektur ermöglicht es mehreren Abteilungen, unabhängig voneinander ihre eigenen Anwendungssysteme zu entwickeln und bereitzustellen, um den tatsächlichen Anforderungen der Organisation gerecht zu werden.
2.4 SOA-Architekturmodell
Das SOA-Architekturmodell wird auch SOAM-Modell (Service-Oriented Architecture Model) genannt. Das SOAM-Modell ist eine Definition der SOA-Architektur. Es handelt sich um ein Multi-View-Modell mit fünf Ansichten:
Service-Ansicht: beschreibt die Services im Unternehmens-IT-System und die Beziehungen zwischen ihnen;
Nachrichtenansicht: Beschreibt die Kommunikationsmethoden und den Nachrichtenfluss zwischen Diensten.
Vertragsansicht: definiert detaillierte Spezifikationen für die Kommunikation zwischen Diensten;
Architekturansicht: zeigt die interne Struktur von Diensten und wie sie zu einem Gesamtsystem kombiniert werden;
Betriebsansicht: Beschreibt den Lebenszyklus des Dienstes und beschreibt die Leistung, Verfügbarkeit und Zuverlässigkeit des Dienstes.
3. Erläuterung der Grundprinzipien des Algorithmus, spezifischer Arbeitsschritte und mathematischer Formeln
3.1 Die Rolle des Service-Registrierungszentrums
Das Service-Registrierungscenter ist eine der wichtigen Komponenten der SOA-Architektur. Die Funktion des Dienstregistrierungszentrums besteht darin, die Metadateninformationen des Dienstes zu speichern, einschließlich Dienstname, Adresse, Port, Protokoll usw., und umfasst normalerweise auch die Dienstversionsnummer, Alias, Gewicht, Upstream- und Downstream-Abhängigkeiten usw . Das Service-Registrierungscenter hilft Service-Kunden dabei, Informationen über die benötigten Services zu finden und die Adressliste des Services zu erhalten, wodurch der Remote-Aufruf des Services realisiert wird.
Die Dienstregistrierung besteht normalerweise aus zwei Teilen:
Dienstverzeichnis: Speichert Metadateninformationen von Diensten, einschließlich Dienstname, Adresse, Port, Protokoll usw.;
Dienstinstanz: Die tatsächlich laufende Instanz des Dienstes, die Heartbeat-Pakete an das Dienstverzeichnis sendet, um den Dienst verfügbar zu halten.
Um zu verhindern, dass die Informationen im Dienstverzeichnis ablaufen, sendet die Dienstinstanz regelmäßig Heartbeat-Pakete an das Dienstverzeichnis und aktualisiert regelmäßig die Metadateninformationen des Dienstes.
Die Dienstregistrierung bietet folgende Vorteile:
Verbessern Sie die Effizienz der Diensterkennung: Dienstkonsumenten können die Adressliste der erforderlichen Dienste über das Dienstregistrierungscenter finden und müssen den Standort und den Port des Dienstes nicht selbst konfigurieren.
Lösen Sie das Konsistenzproblem: Das Dienstregistrierungszentrum kann die Abhängigkeit der Dienstkonsumenten vom Dienstverzeichnis verringern und so die Kommunikation zwischen Diensten stabiler machen.
Verbessern Sie die Dienstverfügbarkeit: Das Dienstregistrierungszentrum kann Dienste in einem Cluster bereitstellen. Wenn ein Knoten ausfällt, können andere Knoten weiterhin Dienste bereitstellen.
3.2 Detaillierte Erläuterung des Service-Aufrufprozesses
Angenommen, es gibt zwei Dienste A und B. Sie müssen kommunizieren und daher eine Verbindung herstellen. Der erste Schritt besteht darin, den Dienst im Dienstregistrierungszentrum (z. B. Zookeeper) zu registrieren und die Metadateninformationen des Dienstes hinzuzufügen, z Dienstname, Adresse, Port, Protokoll usw. Nach der Registrierung im Dienstverzeichnis muss der Dienstkonsument (z. B. der Anrufer) im zweiten Schritt den entsprechenden Dienst im Dienstregistrierungszentrum finden und die Adressliste des Dienstes abrufen , und tätigen Sie dann Fernanrufe über die Adressliste. Das Folgende ist der spezifische Prozess:
Service A meldet sich bei der Service-Registrierungsstelle an:
- Dienst A sendet ein Heartbeat-Paket an das Dienstregistrierungszentrum, um sich über Dienstnamen, Adresse, Port und andere Informationen zu informieren.
- Nach dem Empfang des Heartbeat-Pakets registriert das Dienstregistrierungszentrum die Metadateninformationen des Dienstes im Dienstverzeichnis.
Service B meldet sich bei der Service-Registrierungsstelle an:
- Dienst B sendet ein Heartbeat-Paket an das Dienstregistrierungszentrum, um sich über den Dienstnamen, die Adresse, den Port und andere Informationen zu informieren.
- Nach dem Empfang des Heartbeat-Pakets registriert das Dienstregistrierungszentrum die Metadateninformationen des Dienstes im Dienstverzeichnis.
Der Dienstkonsument sucht in der Dienstregistrierung nach der Adressliste von Dienst A:
- Der Dienstkonsument sendet eine Anfrage an das Dienstregistrierungszentrum, um nach der Adressliste von Dienst A zu suchen.
- Das Dienstregistrierungszentrum fragt die Dienstmetadateninformationen im Dienstverzeichnis ab und gibt die Adressliste von Dienst A zurück.
Der Dienstkonsument ruft Dienst A aus der Ferne gemäß der Adressliste von Dienst A auf:
- Der Dienstkonsument wählt eine Adresse aus der Adressliste von Dienst A aus, um einen Fernanruf zu tätigen.
- Der Dienstkonsument führt einen Fernaufruf an Dienst A durch, um die Funktionen von Dienst A abzuschließen.
3.3 Detaillierte Erläuterung des verteilten Service-Frameworks
Das Entwerfen einer SOA-Architektur bringt neue Komplexität mit sich. Die Vereinfachung der SOA-Architektur in einer verteilten Umgebung ist ein Thema, das es wert ist, untersucht zu werden. Die derzeit beliebte Microservice-Architektur zerlegt die SOA-Architektur in mehrere unabhängige Dienste. Jeder Dienst wird über Protokolle wie HTTP/RPC verfügbar gemacht, und ein Dienstregistrierungszentrum wird für die Dienstverwaltung verwendet, sodass jeder Dienst unabhängig bereitgestellt, erweitert und flexibel erweitert werden kann . Allerdings ist die Microservice-Architektur kein Allheilmittel, sie weist auch einige Mängel auf:
Die Kommunikation zwischen Diensten ist komplex: Obwohl die Microservice-Architektur Protokolle wie HTTP/RPC verwendet, weisen diese dennoch einen gewissen Grad an Komplexität auf;
Komplexes Konfigurationsmanagement: Unter der Microservice-Architektur muss die Konfiguration jedes Dienstes manuell verwaltet werden;
Komplexes Testen, Überwachen und Planen: Unter der Microservice-Architektur ist der Lebenszyklus jedes Dienstes komplex und viele Aspekte wie Testen, Überwachen und Planen müssen berücksichtigt werden;
Die abteilungsübergreifende Kommunikation ist komplex: Unter der Microservice-Architektur ist das F&E-Personal aus verschiedenen Abteilungen möglicherweise nicht in der Lage, direkt zu kommunizieren, und es muss Kommunikationskanäle für eine Win-Win-Zusammenarbeit einrichten.
Eine weitere Implementierung der SOA-Architektur ist das Distributed Service Framework, das den Entwicklungsprozess verteilter Systeme vereinfachen soll. Das verteilte Service-Framework vereinfacht den Entwicklungsprozess verteilter Systeme durch Modularisierung, Verfeinerung der Service-Granularität und nachrichtengesteuerte Methoden. Es abstrahiert zunächst das verteilte System und teilt das verteilte System in mehrere Dienste auf. Jeder Dienst kann unabhängig entwickelt, bereitgestellt, getestet und ausgeführt werden. Im Distributed Service Framework wird der Nachrichtenbus eingeführt, um die Komplexität der Kommunikation zwischen Diensten zu vereinfachen. Der Nachrichtenbus wird als Knotenpunkt für die Kommunikation zwischen Diensten betrachtet, und alle Dienste können den Nachrichtenbus zur Kommunikation verwenden. Serviceentwickler müssen sich nur auf ihre eigene Geschäftslogik konzentrieren und müssen sich nicht um das zugrunde liegende Netzwerk, den Speicher, die Datenverarbeitung und andere Ressourcen kümmern. Der Nachrichtenbus ist für die Übertragung von Nachrichten sowie für das Weiterleiten, Orchestrieren, Konvertieren und andere Aufgaben von Nachrichten verantwortlich. Schließlich ist der Nachrichtenbus auch für die Überwachung, Fehlerbehebung und Planung verteilter Systeme verantwortlich. Daher kann das Distributed Service Framework die Entwicklung verteilter Systeme erheblich vereinfachen und die Entwicklungseffizienz verbessern.
Die grundlegende Architektur des verteilten Service-Frameworks ist in der folgenden Abbildung dargestellt:
Serviceentwickler: Hauptverantwortlich für das Schreiben von Geschäftslogikcode. Serviceentwickler müssen sich nur auf ihre eigene Geschäftslogik konzentrieren. Sie müssen weder das zugrunde liegende Netzwerk, den Speicher, die Computerressourcen und andere Ressourcen verstehen noch auf die Kommunikation achten Protokolle zwischen Diensten, Nachrichtenwarteschlangen usw. im Detail.
Framework-Manager: Hauptverantwortlich für die Registrierung und Verwaltung von Diensten, einschließlich Dienstregistrierung, Erkennung, Routing, Leistungsschalter, Konfigurationsverwaltung usw. Er ist auch für Gesundheitsprüfung, Flusskontrolle, Flussüberwachung, Fehlertoleranzwiederherstellung, Protokollierung usw. verantwortlich. usw. des Dienstes.
Nachrichtenbus: Hauptsächlich für die Kommunikation zwischen Diensten verantwortlich. Der Nachrichtenbus stellt eine einheitliche Nachrichtenschnittstelle für alle Dienste bereit. Dienste können Nachrichten über den Nachrichtenbus veröffentlichen und abonnieren, wodurch die Kommunikation zwischen Diensten einfacher und einheitlicher wird. Der Nachrichtenbus bietet eine hohe Leistung und einen hohen Durchsatz und kann Dienste in einer verteilten Umgebung horizontal erweitern.
Servercluster: Hauptverantwortlich für die Betriebsumgebung des Dienstes. Er stellt Dienste über mehrere physische Maschinen oder virtuelle Maschinen bereit. Er nutzt die hohe Verfügbarkeit, Ressourcenfreigabe, elastische Skalierung und andere vom Servercluster bereitgestellte Funktionen, um das Problem der Dienstverfügbarkeit zu lösen.
Überwachungszentrum: Hauptverantwortlich für die Überwachung von Diensten, einschließlich Verzögerungen bei Dienstanfragen, Fehlerraten, Durchsatz usw. Das Überwachungszentrum ermöglicht es Entwicklern, den aktuellen Betriebsstatus von Diensten anhand von Alarmen, Protokollen, Indikatoren usw. anzuzeigen und Ausnahmen zu erkennen und zu behandeln rechtzeitig. .
3.4 Vor- und Nachteile der Microservice-Architektur unter SOA-Architektur
Vorteile der Microservice-Architektur unter SOA-Architektur:
Fokus auf das Geschäft: Die SOA-Architektur kann sich auf das Geschäft konzentrieren, und jedes Unternehmen verfügt über spezifische Dienste.
Leichter zu verstehen: Die Granularität der Dienste wird verfeinert, wodurch die Beziehung zwischen Diensten klarer und leichter verständlich wird.
Hoher Automatisierungsgrad: Die Entwicklung, Bereitstellung, Prüfung, der Betrieb und die Wartung von Diensten im Rahmen der Microservice-Architektur sind alle automatisiert, wodurch der Prozess rationalisiert und standardisiert wird.
Kopplung reduzieren: Unter der Microservice-Architektur ist die Granularität der Dienste klein genug, und Entwickler müssen sich nur auf ihre eigene Geschäftslogik konzentrieren, was die Komplexität der Entwicklung verringert.
Nachteile der Microservice-Architektur unter SOA-Architektur:
Der Kommunikationsaufwand für Dienste ist hoch: Da die Granularität der Dienste zu fein ist, müssen Entwickler mit verschiedenen Teams oder Abteilungen kommunizieren, um Anforderungen zu ermitteln und Dienste bereitzustellen.
Hohe Abhängigkeit zwischen Diensten: Aufgrund der großen Anzahl von Diensten unter der Microservice-Architektur nimmt auch die Abhängigkeit zwischen Diensten zu. Wenn sich ein Dienst ändert, sind mehrere Dienste beteiligt, was sich auf die Stabilität des Systems auswirkt.
Die Komplexität der Bereitstellung sowie des Betriebs und der Wartung nimmt zu: Unter der Microservice-Architektur nimmt die Komplexität der Bereitstellung sowie des Betriebs und der Wartung zu, die Anzahl der Dienste nimmt ebenfalls zu und es muss eine große Anzahl von Maschinen und Tools berücksichtigt werden.
Die Autonomie des Dienstes ist schwach: Aufgrund der zu feinen Granularität des Dienstes ist die Autonomie des Dienstes schwach und kann die Anforderungen der gemeinsamen Entwicklung mehrerer Abteilungen nicht erfüllen.