{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Wie man aufh\u00f6rt, sich Sorgen zu machen, und anf\u00e4ngt, ohne Monolith zu leben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wie
\n
\nWir alle lieben Geschichten. Es gef\u00e4llt uns, am Lagerfeuer zu sitzen und von unseren fr\u00fcheren Siegen, K\u00e4mpfen oder einfach von unseren Erfahrungen zu erz\u00e4hlen.<\/p>\n

Heute ist genau so ein Tag. Und auch wenn Sie jetzt nicht am Lagerfeuer sitzen, haben wir eine Geschichte f\u00fcr Sie. Eine Geschichte dar\u00fcber, wie wir begonnen haben, mit dem Speicher auf Tarantool zu arbeiten.<\/p>\n

Vor langer Zeit gab es in unserem Unternehmen ein paar \u201eMonolithen\u201c und eine gemeinsame \u201eDecke\u201c, der diese Monolithen langsam, aber sicher n\u00e4her kamen und den Flug unseres Unternehmens, unser Wachstum, einschr\u00e4nkten. Und es gab ein klares Bewusstsein: Eines Tages w\u00fcrden wir heftig gegen diese Decke sto\u00dfen.
\n<\/a><\/noindex>
\nHeute herrscht bei uns die Ideologie der Trennung von allem und jedem, angefangen bei der Hardware bis hin zur Gesch\u00e4ftslogik. Infolgedessen haben wir beispielsweise zwei DCs, die auf netzwerktechnischer Ebene praktisch unabh\u00e4ngig sind. Damals war alles jedoch ganz anders.<\/p>\n

Heutzutage gibt es eine Vielzahl von Werkzeugen und Mitteln zur Implementierung von \u00c4nderungen, wie CI\/CD, K8S usw. In der \u201emonolithischen\u201c Zeit ben\u00f6tigten wir nicht so viele Fremdw\u00f6rter. Es gen\u00fcgte, einfach das \u201eSpeicherding\u201c in der Datenbank zu \u00e4ndern.<\/p>\n

Doch die Zeit schritt voran, und die Anzahl der Anfragen stieg entsprechend, sodass gelegentlich unsere M\u00f6glichkeiten \u00fcbertroffen wurden. Mit dem Markteintritt in den GUS-Staaten fiel die Belastung auf dem Prozessor der ersten Monolith-Datenbank nicht unter 90 % und die RPS lagen bei 2400. Und das waren nicht einfach kleine Selektionen, sondern riesige Anfragen mit einer Vielzahl von \u00dcberpr\u00fcfungen und JOINs, die fast \u00fcber die H\u00e4lfte der Daten im Hintergrund bei gro\u00dfem IO laufen konnten.<\/p>\n

Als dann richtige Verkaufsaktionen zum \u201eBlack Friday\u201c begannen \u2013 und Wildberries damit einer der ersten in Russland war \u2013 wurde die Situation ganz traurig. Denn die Belastung an solchen Tagen steigt um das Dreifache.
\nOh, diese \u201emonolithischen Zeiten\u201c! Ich bin mir sicher, dass auch Sie damit konfrontiert waren und immer noch nicht verstehen k\u00f6nnen, wie das Ihnen passieren konnte.<\/p>\n

Was kann man tun \u2013 Trends betreffen auch Technologien. Vor etwa 5 Jahren mussten wir einen solchen Trend \u00fcberdenken, der sich in der vorhandenen Website auf .NET und MS SQL-Server manifestierte, die sorgf\u00e4ltig die gesamte Logik der Funktionsweise der Website speicherte. Sie speicherte sie so sorgsam, dass das Zerschneiden eines solchen Monolithen ein langwieriges und keineswegs einfaches Vergn\u00fcgen war.
\nEine kleine Bemerkung. <\/p>\n

Auf verschiedenen Veranstaltungen sage ich: \u201eWenn Sie das Monolith nicht zers\u00e4gt haben, dann sind Sie nicht gewachsen!\u201c Ich bin gespannt auf Ihre Meinung dazu, bitte schreiben Sie sie in die Kommentare.<\/p>\n

Und es donnert<\/h3>\n

\nKehren wir zu unserem \u201eKamin\u201c zur\u00fcck. Um die Last der \u201emonolithischen\u201c Funktionalit\u00e4t zu verteilen, haben wir beschlossen, das System in Mikrodienste zu unterteilen, die auf Open-Source-Technologien basieren. Denn deren Skalierung ist zumindest g\u00fcnstiger. Und wir waren uns zu 100 % bewusst, dass wir es skalieren m\u00fcssen (und das nicht wenig). Denn bereits zu diesem Zeitpunkt hatten wir M\u00e4rkte in Nachbarl\u00e4ndern erschlossen, und die Anzahl der Registrierungen sowie die Anzahl der Bestellungen begann noch st\u00e4rker zu wachsen.<\/p>\n

Nachdem wir die ersten Kandidaten f\u00fcr den Ausstieg aus dem Monolithen in Mikrodienste analysiert hatten, verstanden wir, dass in 80 % der F\u00e4lle die Daten in 99 % aus Backoffice-Systemen stammen, w\u00e4hrend das Lesen von der Front kommt. Dies betraf in erster Linie zwei wichtige Teilsysteme f\u00fcr uns \u2013 die Benutzerdaten und das System zur Berechnung der Endpreise von Waren basierend auf Informationen \u00fcber zus\u00e4tzliche Kundenerm\u00e4\u00dfigungen und Gutscheine.<\/p>\n

Am Rande. Es ist erschreckend sich vorzustellen, aber neben den oben genannten Teilsystemen wurden auch die Produktkataloge, der Warenkorb, das Produktsuchsystem, das Filtersystem f\u00fcr die Produktkataloge und verschiedene Empfehlungssysteme aus unserem Monolithen ausgelagert. F\u00fcr die Arbeit jedes einzelnen existieren separate Klassen von spezialisierten Systemen, aber einst lebten sie alle in einem \u201eH\u00e4uschen\u201c. <\/p>\n

Die Daten unserer Kunden wollten wir sofort in ein shardiertes System auslagern. Die Auslagerung der Funktionalit\u00e4t zur Berechnung der Endpreise f\u00fcr Waren erforderte jedoch eine gute Leseskalierbarkeit, da diese die gr\u00f6\u00dfte Belastung in Bezug auf RPS verursachte und f\u00fcr die Datenbank am schwierigsten umzusetzen war (sehr viele Daten sind in den Berechnungsprozess involviert). <\/p>\n

Infolgedessen entstand ein Schema, das gut mit Tarantool harmonierte.<\/p>\n

Zu diesem Zeitpunkt wurden f\u00fcr die Arbeit mit Mikrodiensten Modelle gew\u00e4hlt, die mehrere Rechenzentren auf virtuellen und physischen Maschinen unterst\u00fctzen. Wie in den Abbildungen gezeigt, wurden Tarantool-Replikationsvarianten sowohl im Master-Master- als auch im Master-Slave-Modus angewendet. <\/p>\n

\"Wie
\nArchitektur. Variante 1. Benutzerservice<\/i><\/p>\n

Aktuell sind es 24 Shards, von denen jeder \u00fcber 2 Instanzen (jeweils eine in jedem DC) verf\u00fcgt, alle im Master-Master-Modus.<\/p>\n

\u00dcber der Datenbank befinden sich Anwendungen, die auf die Replikate der Datenbank zugreifen. Die Anwendungen arbeiten \u00fcber unsere benutzerdefinierte Bibliothek mit Tarantool, die die Schnittstelle des Go-Tarantool-Treibers implementiert. Sie sieht alle Replikate und kann sowohl mit dem Master zum Lesen als auch zum Schreiben arbeiten. Im Grunde implementiert sie das Modell des Replikatensatzes, in das Logik zur Auswahl von Replikaten, zur Durchf\u00fchrung von Wiederholungsversuchen, Circuit Breaker und Ratenbegrenzung integriert ist.<\/p>\n

Dabei besteht die M\u00f6glichkeit, die Auswahlrichtlinie der Replikate im Hinblick auf Shards zu konfigurieren. Zum Beispiel Round-Robin.<\/p>\n

\"Wie
\nArchitektur. Variante 2. Dienst zur Berechnung der Endkosten eines Produkts<\/i><\/p>\n

Vor einigen Monaten gingen die meisten Anfragen zur Berechnung der Endkosten von Produkten an einen neuen Dienst, der grunds\u00e4tzlich ohne Datenbanken funktioniert, aber eine Zeit lang wurden 100 % von einem Dienst mit Tarantool im Hintergrund verarbeitet.<\/p>\n

Die Datenbank des Dienstes besteht aus 4 Master-Knoten, in die der Synchronisierer Daten sammelt, und jeder dieser Master verteilte die Daten \u00fcber Replikation auf readonly-Replikate. Jeder Master hat ungef\u00e4hr 15 solcher Replikate.<\/p>\n

Sowohl im ersten als auch im zweiten Schema kann die Anwendung bei Nichterreichbarkeit eines Rechenzentrums die Daten im zweiten erhalten.<\/p>\n

Es ist erw\u00e4hnenswert, dass die Replikation in Tarantool ziemlich flexibel ist und zur Laufzeit konfiguriert werden kann. In anderen Systemen gab es oft Schwierigkeiten. Zum Beispiel erfordert die \u00c4nderung der Parameter max_wal_senders und max_replication_slots in PostgreSQL einen Neustart des Masters, was in einigen F\u00e4llen zu Verbindungsabbr\u00fcchen zwischen der Anwendung und der Datenbank f\u00fchren kann.<\/p>\n

Suchen und finden!<\/h3>\n

\nWarum haben wir nicht \u201ewie normale Menschen\u201c gemacht, sondern einen untypischen Weg gew\u00e4hlt? Es kommt darauf an, was man f\u00fcr normal h\u00e4lt. Viele machen \u00fcberhaupt einen Cluster aus Mongo und verteilen ihn \u00fcber drei geo-verteilte Rechenzentren.<\/p>\n

Zu dieser Zeit hatten wir bereits zwei Projekte auf Redis. Das erste war ein Cache, das zweite stellte ein persistentes Speicher f\u00fcr nicht allzu kritische Daten dar. Damit hatten wir es ziemlich schwer, teilweise auch wegen unserer Schuld. Manchmal lagen recht gro\u00dfe Mengen Daten im Schl\u00fcssel, und es wurde dem System gelegentlich schlecht. Dieses System nutzten wir im Master-Slave-Modus. Es gab viele F\u00e4lle, in denen etwas mit dem Master passierte und die Replikation fehlschlug. <\/p>\n

Das hei\u00dft, Redis eignet sich gut f\u00fcr zustandslose Aufgaben, aber nicht f\u00fcr zustandsbehaftete. Grunds\u00e4tzlich konnte es die meisten Aufgaben l\u00f6sen, aber nur, wenn es sich um Schl\u00fcssel-Werte-L\u00f6sungen mit ein paar Indizes handelte. Zu diesem Zeitpunkt hatte Redis jedoch erhebliche Probleme mit Persistenz und Replikation. Au\u00dferdem gab es Beschwerden \u00fcber die Leistung.<\/p>\n

Wir haben \u00fcber MySQL und PostgreSQL nachgedacht. Aber der erste hat sich irgendwie nicht bei uns durchgesetzt, und der zweite ist an sich ein recht komplexes Produkt, weshalb es unpraktisch w\u00e4re, auf ihm einfache Dienste aufzubauen.
\nWir haben RIAK, Cassandra und sogar grafische Datenbanken ausprobiert. All diese L\u00f6sungen sind ziemlich nischenhaft und eigneten sich nicht als allgemeines, universelles Werkzeug zur Erstellung von Diensten.<\/p>\n

Letztendlich haben wir uns f\u00fcr Tarantool entschieden.<\/p>\n

Wir haben ihn in der Version 1.6 kontaktiert. Wir waren an dem Zusammenspiel von Schl\u00fcssel-Wert und der Funktionalit\u00e4t einer relationalen Datenbank interessiert. Es gibt sekund\u00e4re Indizes, Transaktionen und Spaces, das sind wie Tabellen, aber keine einfachen; man kann unterschiedlich viele Spalten darin speichern. Das Killer-Feature von Tarantool waren die sekund\u00e4ren Indizes in Kombination mit Schl\u00fcssel-Wert und Transaktionsf\u00e4higkeit.<\/p>\n

Auch die hilfsbereite russischsprachige Community spielte eine Rolle, die bereit war, im Chat zu helfen. Wir haben dies aktiv genutzt und lebten praktisch im Chat. Und man sollte nicht die anst\u00e4ndige Persistenz ohne klare Fehler und M\u00e4ngel vergessen. Wenn man unsere Geschichte mit Tarantool betrachtet, hatten wir viele Probleme und Schwierigkeiten mit der Replikation, aber wir haben nie Daten aufgrund seiner Schuld verloren!<\/p>\n

Die Implementierung begann schwierig.<\/h3>\n

\nZu diesem Zeitpunkt war .NET unser Hauptentwicklungsstapel, f\u00fcr den es keinen Connector f\u00fcr Tarantool gab. Wir begannen sofort, etwas in Go zu machen. Mit Lua klappte es auch ganz gut. Das Hauptproblem zu diesem Zeitpunkt war das Debugging: In .NET war alles gro\u00dfartig, aber danach in die Welt des eingebetteten Lua einzutauchen, wenn man au\u00dfer Logs kein Debugging hat, war ziemlich herausfordernd. Au\u00dferdem brach die Replikation aus unerkl\u00e4rlichen Gr\u00fcnden gelegentlich zusammen, weshalb wir uns intensiver mit der Funktionsweise der Tarantool-Engine befassen mussten. Der Chat half dabei, weniger die Dokumentation, manchmal schauten wir uns den Code an. Zu diesem Zeitpunkt war die Dokumentation eher m\u00e4\u00dfig.<\/p>\n

So dauerte es mehrere Monate, um Erfahrung zu sammeln und anst\u00e4ndige Ergebnisse bei der Arbeit mit Tarantool zu erzielen. Wir haben in Git Referenzimplementierungen erstellt, die bei der Entwicklung neuer Mikrodienste halfen. Zum Beispiel, wenn die Aufgabe auftauchte, einen weiteren Mikrodienst zu erstellen, schaute der Entwickler sich den Quellcode der Referenzl\u00f6sung im Repository an, und die Erstellung eines neuen dauerte nicht mehr als eine Woche. <\/p>\n

Das waren besondere Zeiten. Man konnte damals einfach zum Administrator am Nachbartisch gehen und sagen: \u201eGib mir eine VM.\u201c Nach etwa drei\u00dfig Minuten hatte man bereits die Maschine. Man hat sich selbst verbunden, alles installiert, und man bekam den Traffic daf\u00fcr.<\/p>\n

Heute funktioniert das so nicht mehr: Man muss das Monitoring f\u00fcr den Service einrichten, Protokollierung vornehmen, die Funktionalit\u00e4t mit Tests abdecken, eine VM oder eine Bereitstellung in K8s anfordern usw. Insgesamt wird es so besser sein, obwohl es l\u00e4nger dauert und aufwendiger ist.<\/p>\n

Teile und herrsche. Wie steht es um Lua?<\/h3>\n

\nEs gab ein ernstes Dilemma: Einige Teams hatten Schwierigkeiten, \u00c4nderungen in einem Service mit viel Logik in Lua zuverl\u00e4ssig auszurollen. Oft endete dies in einer Nichtexistenz des Services. <\/p>\n

Das hei\u00dft, die Entwickler bereiten eine \u00c4nderung vor. Tarantool beginnt mit der Migration, und die Replikation l\u00e4uft noch mit altem Code; dort trifft ein DDL ein, noch etwas anderes, und der Code bricht einfach zusammen, weil das nicht ber\u00fccksichtigt wird. Infolgedessen war das Update-Verfahren f\u00fcr die Administratoren auf einem A4-Blatt niedergeschrieben: Replikation stoppen, dies aktualisieren, Replikation einschalten, hier ausschalten, dort aktualisieren. Ein Albtraum! <\/p>\n

Letztendlich versuchen wir jetzt h\u00e4ufig, in Lua nichts zu tun. Einfach \u00fcber iproto (das bin\u00e4re Protokoll zur Interaktion mit dem Server) und das war's. Vielleicht liegt es am Mangel an Wissen der Entwickler, aber aus dieser Sicht ist das System komplex.<\/p>\n

Wir folgen diesem Szenario nicht immer blind. Heute gibt es bei uns kein Schwarz und Wei\u00df: entweder alles in Lua oder alles in Go. Wir verstehen bereits, wie es kombiniert werden kann, um sp\u00e4ter keine Probleme mit der Migration zu bekommen.<\/p>\n

Wo gibt es derzeit Tarantool?
\nTarantool wird im Dienst zur Berechnung des endg\u00fcltigen Preises von Waren unter Ber\u00fccksichtigung von Rabattgutscheinen, auch bekannt als \u201ePromotizer\u201c, eingesetzt. Wie bereits erw\u00e4hnt, zieht er sich derzeit zur\u00fcck: Ein neuer Katalogdienst mit vorab berechneten Preisen ersetzt ihn. Aber vor einem halben Jahr wurden alle Berechnungen im \u201ePromotizer\u201c durchgef\u00fchrt. Fr\u00fcher war die H\u00e4lfte seiner Logik in Lua geschrieben. Vor zwei Jahren wurde der Dienst zu einem Speicher und die Logik in Go umgeschrieben, da die Mechanik der Rabatte sich etwas ge\u00e4ndert hat und der Dienst nicht gen\u00fcgend Leistung hatte. <\/p>\n

Einer der kritischsten Dienste ist das Benutzerprofil. Das hei\u00dft, alle Benutzer von Wildberries werden in Tarantool gespeichert, und es sind etwa 50 Millionen. Ein nach Benutzer-ID shardiertes System, verteilt auf mehrere DCs mit einer Anbindung an Go-Dienste.
\nBei RPS war fr\u00fcher der \u201ePromotizer\u201c der F\u00fchrer, es kam bis zu 6.000 Anfragen. In einem bestimmten Moment hatten wir 50-60 Instanzen. Jetzt ist der F\u00fchrer bei RPS - die Benutzerprofile, etwa 12.000. In diesem Dienst wird ein kundenspezifisches Sharding mit einer Aufteilung nach Benutzer-ID-Bereichen angewendet. Der Dienst bedient mehr als 20 Maschinen, aber das ist zu viel; wir planen, die zugewiesenen Ressourcen zu reduzieren, da 4-5 Maschinen ausreichend Leistung bieten.<\/p>\n

Der Dienst f\u00fcr Sitzungen ist unser erster Dienst auf vshard und Cartridge. Die Konfiguration von vshard und das Update von Cartridge erforderten einige Arbeitsaufw\u00e4nde von uns, aber am Ende hat alles geklappt.<\/p>\n

Der Dienst zur Anzeige verschiedener Banner auf der Website und in der mobilen Anwendung war einer der ersten, die sofort auf Tarantool ver\u00f6ffentlicht wurden. Dieser Dienst ist bemerkenswert, da er etwa 6-7 Jahre alt ist, immer noch im Einsatz ist und nie neu gestartet wurde. Es wurde eine Master-Master-Replikation verwendet. Es gab nie Probleme.<\/p>\n

Es gibt ein Beispiel f\u00fcr die Nutzung von Tarantool f\u00fcr die Funktionalit\u00e4t schneller Nachschlagewerke im Lagerverwaltungssystem, um in bestimmten F\u00e4llen Informationen schnell zu \u00fcberpr\u00fcfen. Wir haben versucht, daf\u00fcr Redis zu verwenden, aber die Daten im Speicher nahmen mehr Platz ein als bei Tarantool.<\/p>\n

Die Dienste f\u00fcr Wartelisten, Kundenabonnements, die derzeit angesagten Stories und die zwischenzeitlich aufgegebenen Waren arbeiten ebenfalls mit Tarantool. Der letzte Dienst ben\u00f6tigt im Speicher etwa 120 GB. Das ist der umfangreichste Dienst aus den genannten Gr\u00fcnden. <\/p>\n

Fazit<\/h3>\n

\nDank sekund\u00e4ren Indizes in Kombination mit Key-Value und Transaktionsf\u00e4higkeit eignet sich Tarantool hervorragend f\u00fcr architektonische L\u00f6sungen, die auf Mikrodiensten basieren. Allerdings hatten wir Schwierigkeiten, als wir \u00c4nderungen in Diensten mit viel Logik in Lua ausrollten \u2013 die Dienste fielen h\u00e4ufig aus. Es gelang uns nicht, dieses Problem zu bew\u00e4ltigen, und im Laufe der Zeit kamen wir zu verschiedenen Kombinationen von Lua und Go: Wir wissen, wo einer der beiden Sprachen zum Einsatz kommen sollte.<\/p>\n

Was gibt es noch zu lesen<\/b><\/p>\n