Inhaltsverzeichnis
2. Wenden Sie eine Datentrennungsarchitektur an
3. Architektur des Anwendungsdienst-Clusters
4. Lese- und Schreibtrennung/Master-Slave-Trennungsarchitektur
5. Einführung in die Cache-Architektur zur Trennung von heißem und kaltem Wasser
7. Business-Splitting-Microservices
8. Einführung der Containerisierung – Container-Orchestrierungsarchitektur
1. Eigenständige Architektur
In der Anfangsphase müssen wir unser kompetentes technisches Team einsetzen, um das Geschäftssystem schnell zum Testen auf den Markt zu bringen und schnell auf sich ändernde Anforderungen zu reagieren. Aber glücklicherweise war die Anzahl der Benutzerbesuche in der Anfangsphase sehr gering und es wurden keine hohen Anforderungen an unsere Leistung, Sicherheit usw. gestellt. Die Systemarchitektur ist einfach und erfordert kein professionelles Betriebs- und Wartungsteam Es empfiehlt sich, eine eigenständige Architektur zu wählen.
Der Benutzer gibt www.baidu.com in den Browser ein. Zuerst wird der Domänenname über den DNS-Dienst in die IP-Adresse 10.102.41.1 aufgelöst, und dann greift der Browser auf den der IP entsprechenden Anwendungsdienst zu.
Vorteile: einfache Bereitstellung, niedrige Kosten
Nachteile: Es besteht ein gravierender Leistungsengpass, die Datenbank und die Anwendung konkurrieren miteinander um Ressourcen
2. Wenden Sie eine Datentrennungsarchitektur an
Als das System online ging, erzielten wir den erwarteten Erfolg. Auf dem Markt erschien eine Gruppe treuer Benutzer, die die Anzahl der Besuche des Systems schrittweise erhöhte und sich allmählich der Grenze der Hardwareressourcen näherte. Gleichzeitig sammelte das Team in dieser Zeit auch viel Erfahrung in Geschäftsprozessen. Angesichts des aktuellen Leistungsdrucks müssen wir Vorkehrungen treffen, um Systemrekonstruktionen und architektonische Herausforderungen durchzuführen, um die Tragfähigkeit des Systems zu verbessern. Da das Budget jedoch immer noch sehr knapp ist, haben wir uns für die Trennung von Anwendungen und Daten entschieden, wodurch die Tragfähigkeit des Systems bei minimalen Kosten erhöht werden kann.
Der Hauptunterschied zur vorherigen Architektur besteht darin, dass der Datenbankdienst unabhängig auf anderen Servern im selben Rechenzentrum bereitgestellt wird und der Anwendungsdienst über das Netzwerk auf die Daten zugreift.
Vorteile: Die Kosten sind relativ kontrollierbar, die Leistung ist im Vergleich zu einem einzelnen Computer verbessert, die Datenbank ist separat isoliert, die Datenbank wird nicht durch Anwendungen beschädigt und sie verfügt über bestimmte Notfallwiederherstellungsfunktionen
Nachteile: Die Hardwarekosten werden höher, die Leistung weist Engpässe auf und kann nicht mit massiver Parallelität umgehen
3. Architektur des Anwendungsdienst-Clusters
Unser System wurde von den Benutzern begrüßt und erfreut sich großer Beliebtheit. Ein einzelner Anwendungsserver kann die Nachfrage nicht mehr erfüllen. Unser eigenständiger Anwendungsserver stieß zunächst auf einen Engpass. Vor unserem technischen Team standen zwei Optionen zur Verfügung. Alle diskutierten heftig über die Vor- und Nachteile der Lösungen:
• Vertikale Erweiterung / vertikale Erweiterung Scale Up. Bewältigen Sie mehr Datenverkehr, indem Sie Anwendungsserver mit besserer Leistung und höheren Preisen kaufen. Der Vorteil dieser Lösung besteht darin, dass keine Anpassungen an der Systemsoftware erforderlich sind; der Nachteil liegt jedoch auch auf der Hand: Der Zusammenhang zwischen Hardwareleistung und Preiswachstum ist nichtlinear, was bedeutet, dass die Wahl von Hardware mit der doppelten Leistung unter Umständen Kosten verursacht mehr als das Vierfache des Preises. Zweitens gibt es eine klare Obergrenze für die Verbesserung der Hardwareleistung.
• Scale-Out/Scale-Out. Durch Anpassen der Softwarearchitektur, Hinzufügen von Hardware auf Anwendungsebene und Zuweisen von Benutzerverkehr zu verschiedenen Servern auf Anwendungsebene kann die Tragfähigkeit des Systems verbessert werden. Der Vorteil dieser Lösung besteht darin, dass die Kosten relativ gering sind und die Obergrenze für Verbesserungen ebenfalls groß ist. Der Nachteil besteht jedoch darin, dass es das System komplexer macht und mehr Erfahrung vom technischen Team erfordert. Nach der Untersuchung, Recherche und Diskussion des Teams haben wir uns schließlich für die horizontale Erweiterungslösung entschieden, um dieses Problem zu lösen. Dies erforderte jedoch die Einführung einer neuen Komponente – Lastausgleich: Um das Problem zu lösen, auf welchen Anwendungsserver der Benutzerverkehr verteilt wird , Spezialisierte Systemkomponenten übernehmen die Verkehrsverteilung. In der Praxis bezieht sich der Lastausgleich nicht nur auf die Arbeit in der Anwendungsschicht, sondern kann sogar in anderen Netzwerkschichten stattfinden. Gleichzeitig gibt es viele Arten von Verkehrsplanungsalgorithmen. Hier sind einige gängige:
• Round-Robin-Abfragealgorithmus. Das heißt, die Anfragen werden sehr fair auf verschiedene Anwendungsserver verteilt.
• Weight-Round-Robin-Round-Robin-Algorithmus. Geben Sie verschiedenen Servern (z. B. mit unterschiedlicher Leistung)
und denen, die mehr Arbeit leisten können, unterschiedliche Gewichtungen.
• Konsistenter Hash-Hashing-Algorithmus. Der Hash-Wert wird durch Berechnung des charakteristischen Werts des Benutzers (z. B. IP-Adresse) ermittelt und basierend auf dem Hash-Ergebnis verteilt. Der Vorteil besteht darin, sicherzustellen, dass Anfragen desselben Benutzers immer dem angegebenen Server zugewiesen werden. Das ist der besondere Account-Manager-Service, den wir normalerweise antreffen.
Vorteile: Hohe Verfügbarkeit von Anwendungsdiensten: Anwendungen erfüllen eine hohe Verfügbarkeit, und die gesamte Site hängt nicht, wenn ein Problem mit einem Dienst auftritt. Anwendungsdienste weisen eine bestimmte hohe Leistung auf: Wenn nicht auf die Datenbank zugegriffen wird, kann die anwendungsbezogene Verarbeitung unterstützt werden Schnelle Reaktion auf massive Anfragen durch Erweiterung; Anwendungsdienste verfügen über eine gewisse Skalierbarkeit: Unterstützt horizontale Erweiterung
Nachteile: Die Datenbank ist zu einem Leistungsengpass geworden und kann die massiven Abfragen der Datenbank nicht bewältigen. Die Datenbank ist ein einzelner Punkt und weist keine hohe Verfügbarkeit auf. Der Betriebs- und Wartungsaufwand nimmt zu, und der Bereitstellungs- sowie Betriebs- und Wartungsaufwand nimmt danach zu Erweiterung, und entsprechende Tools müssen entwickelt werden, um eine schnelle Bereitstellung zu bewältigen; die Hardwarekosten sind hoch
4. Lese- und Schreibtrennung/Master-Slave-Trennungsarchitektur
Wie bereits erwähnt, können Benutzeranforderungen, nachdem wir sie durch Lastausgleich auf verschiedene Anwendungsserver verteilt haben, parallel verarbeitet werden. Wenn das Unternehmen wächst, kann die Anzahl der Server dynamisch erweitert werden, um den Druck zu verringern. Aber in der aktuellen Architektur lesen und schreiben diese Anforderungen unabhängig von der Anzahl der Server schließlich Daten aus der Datenbank. Ab einem bestimmten Grad wird der Druck auf die Daten zum Engpass der Tragfähigkeit des Systems. Können wir den Datenbankserver auf die gleiche Weise skalieren wie den Anwendungsserver? Die Antwort ist nein, denn Datenbankdienste haben ihre Besonderheiten: Wenn die Daten auf verschiedene Server verteilt sind, kann die Konsistenz der Daten nicht gewährleistet werden. Die sogenannte Datenkonsistenz bezieht sich hier auf: Für dasselbe System, egal wann und wo, sollten wir konsistente Daten sehen. Stellen Sie sich den von einer Bank verwalteten Kontobetrag vor. Wenn nach Erhalt einer Überweisung die Daten in einer Datenbank geändert werden, die andere Datenbank jedoch nicht, ist der vom Benutzer erhaltene Einzahlungsbetrag falsch. Die von uns gewählte Lösung bestand darin, eine Primärdatenbank als Schreibdatenbank und die anderen Datenbanken als Slave-Datenbanken zu behalten. Alle Daten in der Slave-Datenbank stammen aus den Daten in der Master-Datenbank. Nach der Synchronisierung kann die Slave-Datenbank die Daten beibehalten, die mit der Master-Datenbank konsistent sind. Um den Druck auf die Datenbank zu verteilen, können wir dann alle Schreibdatenanforderungen zur Verarbeitung an die Hauptbibliothek übergeben, die Leseanforderungen jedoch auf verschiedene Slave-Bibliotheken verteilen. Da in den meisten Systemen die Lese- und Schreibanforderungen unverhältnismäßig sind, beispielsweise 100 Lesevorgänge und 1 Schreibvorgang, ist der Druck auf die Datenbank nicht so groß, solange die Leseanforderungen von den Slave-Bibliotheken gemeinsam genutzt werden. Natürlich ist dieser Prozess nicht kostenlos. Die Datensynchronisierung von der Master-Datenbank zur Slave-Datenbank ist tatsächlich mit Zeitaufwand verbunden, wir werden dieses Problem jedoch vorerst nicht weiter diskutieren.
Vorteile: Die Leseleistung der Datenbank wird verbessert; das Lesen wird von anderen Servern gemeinsam genutzt und die Schreibleistung wird indirekt verbessert; die Datenbank verfügt über Slave-Bibliotheken und die Verfügbarkeit der Datenbank wird verbessert
Nachteile: Häufiges Lesen von Hotspot-Daten führt zu einer hohen Datenbanklast. Wenn die Synchronisierung fehlschlägt oder die Synchronisierungsverzögerung relativ groß ist, sind die in die Datenbank geschriebenen Daten und die gelesene Datenbank inkonsistent; die Serverkosten müssen weiter erhöht werden
5. Einführung in die Cache-Architektur zur Trennung von heißem und kaltem Wasser
Da die Anzahl der Besuche weiter zunimmt, zeigt sich, dass die Lesehäufigkeit einiger Daten im Unternehmen viel größer ist als die anderer Daten. Wir nennen diesen Teil der Daten „heiße Daten“, was kalten Daten entspricht. Für heiße Daten können Sie zur Verbesserung der Reaktionszeit beim Lesen einen lokalen Cache und einen externen verteilten Cache hinzufügen, um beliebte Produktinformationen oder HTML-Seiten beliebter Produkte usw. zwischenzuspeichern. Durch Caching können die meisten Anfragen vor dem Lesen und Schreiben in die Datenbank abgefangen werden, wodurch der Datenbankdruck erheblich reduziert wird. Zu den beteiligten Technologien gehören: die Verwendung von Memcached als lokaler Cache und die Verwendung von Redis als verteilter Cache. Dazu gehören auch Probleme wie Cache-Konsistenz, Cache-Penetration/-Ausfall, Cache-Lawine und zentralisierte Hotspot-Datenausfälle.
Vorteile: Reduzieren Sie die Zugriffsanforderungen an die Datenbank erheblich und die Leistungsverbesserung ist sehr offensichtlich.
Nachteile: Es führt zu Cache-Konsistenz, Cache-Aufschlüsselung, Cache-Fehlern, Cache-Lawine und anderen Problemen; die Serverkosten müssen weiter erhöht werden; mit zunehmendem Geschäftsvolumen nehmen die Daten weiter zu, die einzelne Datenbank ist zu groß und die Größe von Eine einzelne Tabelle ist ebenfalls groß. Wenn sie zu groß ist, ist die Datenabfrage sehr langsam, was dazu führt, dass die Datenbank erneut zum Systemengpass wird.
6. Vertikale Unterbibliothek
Da die Menge an Geschäftsdaten zunimmt, ist das Speichern großer Datenmengen in derselben Datenbank etwas überwältigend geworden, sodass die Daten je nach Unternehmen separat gespeichert werden können. Beispielsweise können Kommentardaten entsprechend der Produkt-ID gehasht und zur Speicherung an die entsprechende Tabelle weitergeleitet werden. Für Zahlungsdatensätze kann eine Tabelle pro Stunde erstellt werden, und jede Stundentabelle kann in kleine Tabellen aufgeteilt werden Benutzer-ID oder Datensatznummer können zum Weiterleiten der Daten verwendet werden. Solange die Menge der in Echtzeit verarbeiteten Tabellendaten klein genug ist und Anforderungen gleichmäßig auf kleine Tabellen auf mehreren Servern verteilt werden können, kann die Leistung der Datenbank durch horizontale Erweiterung verbessert werden. Das zuvor erwähnte Mycat unterstützt auch die Zugriffskontrolle, wenn eine große Tabelle in kleine Tabellen aufgeteilt wird. Dieser Ansatz erhöht die Schwierigkeit des Datenbankbetriebs und der Datenbankwartung erheblich und stellt höhere Anforderungen an Datenbankadministratoren. Wenn die Datenbank mit dieser Struktur entworfen wird, kann sie bereits als verteilte Datenbank bezeichnet werden, es handelt sich jedoch lediglich um eine logische Datenbank als Ganzes. Verschiedene Komponenten in der Datenbank werden separat durch verschiedene Komponenten implementiert, z. B. die Verwaltung und Anforderung von Unter- Datenbanken und Untertabellen. Die Verteilung wird durch Mycat implementiert, die SQL-Analyse wird durch eine eigenständige Datenbank implementiert, die Lese-/Schreibtrennung kann durch Gateways und Nachrichtenwarteschlangen implementiert werden, die Zusammenfassung der Abfrageergebnisse kann durch die Datenbankschnittstellenschicht implementiert werden usw Bei dieser Architektur handelt es sich eigentlich um eine MPP-Architektur (Large-Scale A Class of Implementation of Parallel Processing).
Vorteile: Der Datenbankdurchsatz wird erheblich verbessert und stellt keinen Engpass mehr dar;
Nachteile: Probleme wie datenbankübergreifende Verknüpfungen und verteilte Transaktionen müssen entsprechend gelöst werden. Das aktuelle MPP verfügt über entsprechende Lösungen. Die Kombination aus Datenbank und Cache kann derzeit massiven Anforderungen standhalten, der gesamte Anwendungscode ist jedoch miteinander gekoppelt. , Änderung einer Zeile Eine große Anzahl von Codes erfordert die erneute Veröffentlichung des gesamten Codes
7. Business-Splitting-Microservices
Wenn die Anzahl der Mitarbeiter zunimmt und sich das Unternehmen weiterentwickelt, teilen wir das Unternehmen zur Wartung in verschiedene Entwicklungsteams auf. Jedes Team implementiert unabhängig seine eigenen Microservices und isoliert dann den direkten Zugriff auf Daten voneinander. Technologien wie Gateway und Message Bus können sein verwendet. , um eine gegenseitige Anrufzuordnung zu erreichen. Sie können sogar einige Dienste wie die Benutzerverwaltung in öffentliche Dienste umwandeln.
Vorteile: Hohe Flexibilität: unabhängiges Testen, Bereitstellen, Upgraden und Freigeben von Diensten; unabhängige Erweiterung: jeder Dienst kann unabhängig erweitert werden; verbesserte Fehlertoleranz: ein Dienstproblem lähmt nicht das gesamte System; einfache Anwendung neuer Technologien: unterstützt mehrere Programmiersprachen
Nachteile: Hohe Komplexität von Betrieb und Wartung: Mit der kontinuierlichen Geschäftsentwicklung wird die Anzahl der Anwendungen und Dienste weiter zunehmen und die Bereitstellung von Anwendungen und Diensten wird komplizierter. Die Bereitstellung mehrerer Dienste auf demselben Server erfordert auch die Lösung des Problems Problem von Konflikten in der Betriebsumgebung. Darüber hinaus erfordern beispielsweise Szenarien wie große Werbeaktionen, die eine dynamische Erweiterung und Kontraktion erfordern, eine horizontale Erweiterung der Dienstleistung, was die Vorbereitung der Betriebsumgebung auf neue Dienste, die Bereitstellung von Diensten usw. erfordert. Betrieb und Wartung werden sehr schwierig; die Ressourcennutzung wird zunehmen: Alle diese Microservices, die unabhängig ausgeführt werden, müssen Speicher und CPU belegen; es ist schwierig, Fehler zu behandeln: Eine Anfrage umfasst mehrere Serviceaufrufe und Sie müssen die Protokolle verschiedener Services überprüfen, um die Problemlokalisierung abzuschließen
8. Einführung der Containerisierung – Container-Orchestrierungsarchitektur
Als das Unternehmen wuchs, stellte sich heraus, dass die Ressourcenauslastung des Systems nicht hoch war. Viele Ressourcen wurden für die Bewältigung kurzfristig hoher Parallelität verwendet und waren zu normalen Zeiten inaktiv. Es waren dynamische Erweiterungen und Kontraktionen erforderlich. Es gab keine Möglichkeit um den Server direkt offline zu schalten, und jeden Tag während der Entwicklung, des Testens und der Produktion war In einer Umgebung, in der alle Umgebungssätze isoliert werden müssen, wird der Arbeitsaufwand für Betrieb und Wartung sehr groß. Das Aufkommen der Containerisierungstechnologie hat neue Ideen zur Lösung dieser Probleme hervorgebracht.
Derzeit ist Docker die beliebteste Containerisierungstechnologie und Kubernetes (K8S) der beliebteste Containerverwaltungsdienst. Anwendungen/Dienste können als Docker-Images gepackt werden und die Images können über K8S dynamisch verteilt und bereitgestellt werden. Ein Docker-Image kann als minimales Betriebssystem verstanden werden, das Ihre Anwendung/Ihren Dienst ausführen kann. Es enthält den laufenden Code der Anwendung/des Dienstes. Die Betriebsumgebung wird entsprechend den tatsächlichen Anforderungen festgelegt. Nachdem das gesamte „Betriebssystem“ in ein Image gepackt wurde, kann es an die Maschinen verteilt werden, auf denen zugehörige Dienste bereitgestellt werden müssen. Der Dienst kann durch direktes Starten des Docker-Images gestartet werden, wodurch die Bereitstellung sowie der Betrieb und die Wartung des Dienstes erfolgen einfach. Dienste
verfügen normalerweise über Produktions- und F&E-K8S-Cluster, die im Allgemeinen nicht öffentlich geteilt werden. F&E-Cluster verwenden Namespaces, um die Anwendungsisolation abzuschließen. Einige Unternehmen sind je nach F&E-Zweck in F&E- und Testcluster unterteilt, und einige Unternehmen vervollständigen abteilungsübergreifende Ressourcen durch Organisationsstrukturen . Wiederverwendung.
Vorteile: Bereitstellung, Betrieb und Wartung sind einfach und schnell: Ein Befehl kann die Bereitstellung oder Erweiterung und Kontraktion von Hunderten von Diensten abschließen; gute Isolierung: Das Dateisystem, das Netzwerk usw. zwischen Containern sind voneinander isoliert, und das wird auch so sein keine Umgebungskonflikte; einfacher Support Rolling Update: Der Wechsel zwischen Versionen kann mit einem einzigen Befehl aktualisiert oder zurückgesetzt werden
Nachteile: Die Anzahl der Technologie-Stacks nimmt zu und die Anforderungen an das F&E-Team sind hoch; die Maschinen müssen immer noch vom Unternehmen selbst verwaltet werden. Wenn es keine große Förderung gibt, müssen immer noch viele Maschinenressourcen ungenutzt bleiben, um damit fertig zu werden mit der großen Aktion. Die Kosten für die Maschine selbst sowie die Betriebs- und Wartungskosten sind extrem hoch. Hohe und niedrige Ressourcenauslastung, die durch den Kauf von Servern von Cloud-Anbietern gelöst werden kann.
Zusammenfassen
Zu diesem Zeitpunkt ist der grundlegende Prototyp eines Systems mit einigermaßen hoher Verfügbarkeit und hoher Parallelität entstanden. Beachten Sie, dass die oben erwähnte Architekturentwicklungssequenz nur eine separate Verbesserung für einen bestimmten Aspekt darstellt. In tatsächlichen Szenarien müssen möglicherweise mehrere Probleme gleichzeitig gelöst werden, oder ein anderer Aspekt kann zuerst den Engpass erreichen. Zu diesem Zeitpunkt Es sollte praktische Probleme entsprechend den tatsächlichen Problemen lösen. Beispielsweise ist in Regierungsszenarien, in denen der Umfang der Parallelität möglicherweise nicht groß, das Unternehmen jedoch sehr umfangreich ist, eine hohe Parallelität nicht das Hauptproblem, das gelöst werden muss. Zu diesem Zeitpunkt kann die Priorität auf Lösungen liegen, die umfangreiche Anforderungen erfüllen. Bei einmalig implementierten Systemen mit klaren Leistungskennzahlen reicht es aus, wenn die Architektur so gestaltet ist, dass sie die Leistungskennzahlenanforderungen des Systems unterstützt, für den Notfall sollten jedoch Schnittstellen zur Erweiterung der Architektur bestehen bleiben. Bei sich ständig weiterentwickelnden Systemen wie E-Commerce-Plattformen sollten diese so konzipiert sein, dass sie den Anforderungen an Benutzervolumen und Leistungsindex der nächsten Stufe entsprechen, und die Architektur sollte basierend auf dem Geschäftswachstum iterativ aktualisiert werden, um eine höhere Parallelität und umfassendere Dienste zu unterstützen. Das sogenannte „Big Data“ ist eigentlich ein Sammelbegriff für Szenariolösungen wie massive Datenerfassung, -bereinigung und -konvertierung, Datenspeicherung, Datenanalyse und Datendienste. Jedes Szenario umfasst eine Vielzahl optionaler Technologien wie Flume, Sqoop , Kettle usw.; die Datenspeicherung umfasst verteilte Dateisysteme HDFS, FastDFS, NoSQL-Datenbank HBase, MongoDB usw.; die Datenanalyse umfasst Spark-Technologie-Stack, maschinelle Lernalgorithmen usw. Im Allgemeinen handelt es sich bei der Big-Data-Architektur um eine Architektur, die je nach Geschäftsanforderungen verschiedene Big-Data-Komponenten integriert und im Allgemeinen verteilten Speicher, verteiltes Rechnen, mehrdimensionale Analysen, Data Warehouse, Algorithmen für maschinelles Lernen und andere Funktionen bereitstellt. Die serverseitige Architektur bezieht sich eher auf die Architektur auf Anwendungsorganisationsebene, und die zugrunde liegenden Funktionen werden häufig von der Big-Data-Architektur bereitgestellt.