Josh Evans spricht über die chaotische und farbenfrohe Welt der Netflix-Microservices, beginnend mit den Grundlagen – der Anatomie von Microservices, den Herausforderungen, die mit verteilten Systemen verbunden sind, und ihren Vorteilen. Aufbauend auf dieser Grundlage untersucht er die kulturellen, architektonischen und betrieblichen Praktiken, die zur Beherrschung von Microservices führen.
Im Gegensatz zur operativen Drift sind die Einführung neuer Sprachen zur Service-Internationalisierung und neuer Technologien wie Container bewusste Entscheidungen, um der Umgebung neue Komplexität zu verleihen. Mein Betriebsteam standardisierte die beste Technologie-Roadmap für Netflix, die in vordefinierte Best Practices auf Basis von Java und EC2 integriert wurde. Als das Unternehmen jedoch wuchs, begannen die Entwickler, neue Komponenten wie Python, Ruby, Node-JS und Docker hinzuzufügen.
Ich bin sehr stolz darauf, dass wir die ersten waren, die sich dafür eingesetzt haben, dass unser Produkt einwandfrei funktioniert, ohne auf Kundenbeschwerden warten zu müssen. Angefangen hat alles ganz einfach – wir hatten Betriebsprogramme in Python und ein paar Backoffice-Anwendungen in Ruby, aber die Dinge wurden viel interessanter, als unsere Webentwickler ankündigten, dass sie die JVM aufgeben und das Web verlagern würden Anwendung auf die Node-Softwareplattform.js. Nach der Einführung von Docker wurden die Dinge deutlich komplexer. Wir sind der Logik gefolgt und die Technologien, die wir entwickelt haben, wurden Wirklichkeit, als wir sie für Kunden implementierten, weil sie sehr sinnvoll waren. Ich sage Ihnen, warum das so ist.
API Gateway verfügt tatsächlich über die Fähigkeit, großartige Skripte zu integrieren, die als Endpunkte für UI-Entwickler fungieren können. Sie haben jedes dieser Skripte so konvertiert, dass sie sie nach der Durchführung von Änderungen in der Produktion und dann auf Benutzergeräten bereitstellen konnten. Alle diese Änderungen wurden mit Endpunkten synchronisiert, die im API-Gateway ausgeführt wurden.
Allerdings wiederholte sich dadurch das Problem, einen neuen Monolithen zu schaffen, bei dem der API-Dienst derart mit Code überlastet war, dass verschiedene Fehlerszenarien auftraten. Beispielsweise wurden einige Endpunkte entfernt oder Skripte generierten nach dem Zufallsprinzip so viele Versionen von etwas, dass die Versionen den gesamten verfügbaren Speicher des API-Dienstes belegten.
Es war logisch, diese Endpunkte aus dem API-Dienst herauszuziehen. Dazu haben wir Node.js-Komponenten erstellt, die als kleine Anwendungen in Docker-Containern ausgeführt wurden. Dadurch konnten wir alle durch diese Knotenanwendungen verursachten Probleme und Abstürze isolieren.
Die Kosten dieser Änderungen sind recht hoch und setzen sich aus folgenden Faktoren zusammen:
- Produktivitätswerkzeuge. Die Verwaltung neuer Technologien erforderte neue Tools, da das UI-Team, das sehr gute Skripte zur Erstellung eines effizienten Modells verwendete, nicht viel Zeit mit der Verwaltung der Infrastruktur verbringen musste, sondern lediglich Skripte schreiben und deren Funktionalität überprüfen musste.
Opportunity Insight and Sorting – Ein wichtiges Beispiel sind die neuen Tools, die zum Aufdecken von Informationen zu Leistungstreibern erforderlich sind. Es war notwendig zu wissen, wie stark der Prozessor ausgelastet war, wie der Speicher genutzt wurde, und um diese Informationen zu sammeln, waren verschiedene Tools erforderlich. - Fragmentierung von Basisbildern – das einfache Basis-AMI ist fragmentierter und spezialisierter geworden.
- Knotenverwaltung. Es gibt keine Standardarchitektur oder -technologie, mit der Sie Knoten in der Cloud verwalten können. Deshalb haben wir Titus entwickelt, eine Container-Management-Plattform, die eine skalierbare und zuverlässige Container-Bereitstellung und Cloud-Integration mit Amazon AWS ermöglicht.
- Duplizierung einer Bibliothek oder Plattform. Um neue Technologien mit derselben Kernfunktionalität der Plattform bereitzustellen, war eine Duplizierung in cloudbasierte Node.js-Entwicklertools erforderlich.
- Lernkurve und Industrieerfahrung. Die Einführung neuer Technologien bringt zwangsläufig neue Herausforderungen mit sich, die es zu meistern und daraus zu lernen gilt.
Daher konnten wir uns nicht auf eine „gepflasterte Straße“ beschränken und mussten ständig neue Wege finden, um unsere Technologien voranzutreiben. Um die Kosten niedrig zu halten, haben wir den zentralen Support eingeschränkt und uns auf die JVM, neue Knoten und Docker konzentriert. Wir priorisierten die effektive Wirkung, informierten die Teams über die Kosten ihrer Entscheidungen und ermutigten sie, nach Möglichkeiten zu suchen, die bereits entwickelten Lösungen mit hoher Wirkung wiederzuverwenden. Wir haben diesen Ansatz bei der Übersetzung des Dienstes in Fremdsprachen verwendet, um das Produkt an internationale Kunden zu liefern. Beispiele hierfür sind relativ einfache Client-Bibliotheken, die automatisch generiert werden können, sodass es relativ einfach ist, eine Python-Version, eine Ruby-Version, eine Java-Version usw. zu erstellen.
Wir waren ständig auf der Suche nach Möglichkeiten, bewährte Technologien einzusetzen, die sich an einem Ort und in anderen ähnlichen Situationen bewährt hatten.
Lassen Sie uns über das letzte Element sprechen – Änderungen oder Variationen. Sehen Sie, wie der Verbrauch unseres Produkts je nach Wochentag und Stunde im Laufe des Tages ungleichmäßig schwankt. Man könnte sagen, dass 9 Uhr morgens die schwierigste Zeit für Netflix ist, wenn die Belastung des Systems ihr Maximum erreicht.
Wie können wir eine hohe Geschwindigkeit bei der Umsetzung von Softwareinnovationen erreichen, also ständig neue Änderungen am System vornehmen, ohne dass es zu Unterbrechungen bei der Leistungserbringung kommt und ohne Unannehmlichkeiten für unsere Kunden zu schaffen? Netflix erreichte dies durch den Einsatz von Spinnaker, einer neuen globalen cloudbasierten Management- und Continuous-Delivery-Plattform (CD).
Entscheidend ist, dass Spinnaker darauf ausgelegt ist, unsere Best Practices zu integrieren, sodass wir bei der Bereitstellung von Komponenten in der Produktion die Ausgabe direkt in unsere Medienbereitstellungstechnologie integrieren können.
Wir konnten zwei Technologien in unsere Lieferpipeline integrieren, die wir sehr schätzen: automatisierte Canary-Analyse und stufenweise Bereitstellung. Canary-Analyse bedeutet, dass wir einen Teil des Datenverkehrs auf die neue Version des Codes leiten und den Rest des Produktionsdatenverkehrs über die alte Version weiterleiten. Anschließend prüfen wir, wie der neue Code die Aufgabe meistert – besser oder schlechter als der bestehende.
Eine gestaffelte Einführung bedeutet, dass wir, wenn bei der Einführung in einer Region Probleme auftreten, zu einer Einführung in einer anderen Region übergehen. In diesem Fall muss die oben genannte Checkliste in die Produktionspipeline aufgenommen werden. Ich spare Ihnen etwas Zeit und empfehle Ihnen, sich meinen vorherigen Vortrag „Engineering Global Netflix Operations in the Cloud“ anzuschauen, wenn Sie daran interessiert sind, tiefer in dieses Thema einzutauchen. Die Videoaufzeichnung der Rede kann über den Link am Ende der Folie angesehen werden.
Am Ende des Vortrags werde ich kurz auf die Organisation und Architektur von Netflix eingehen. Ganz am Anfang hatten wir ein Schema namens Electronic Delivery, die erste Version des NRDP 1.x-Medienstreamings. Der Begriff „Backstream“ kann hier verwendet werden, da der Nutzer Inhalte zunächst nur für die spätere Wiedergabe auf dem Gerät herunterladen konnte. Die allererste digitale Lieferplattform von Netflix im Jahr 2009 sah in etwa so aus.
Das Benutzergerät enthielt die Netflix-Anwendung, die aus einer UI-Schnittstelle, Sicherheitsmodulen, Dienstaktivierung und -wiedergabe bestand und auf der NRDP-Plattform – Netflix Ready Device Platform – basierte.
Damals war die Benutzeroberfläche sehr einfach. Es enthielt einen sogenannten Queque Reader, und der Benutzer ging auf die Website, um etwas zu Queque hinzuzufügen, und sah sich dann den hinzugefügten Inhalt auf seinem Gerät an. Das Positive war, dass das Front-End-Team und das Back-End-Team derselben Electronic-Delivery-Organisation angehörten und eine enge Zusammenarbeit hatten. Die Payload wurde auf Basis von XML erstellt. Gleichzeitig wurde die Netflix-API für das DVD-Geschäft erstellt, die Drittanbieteranwendungen dazu ermutigte, Datenverkehr zu unserem Dienst zu leiten.
Die Netflix-API war jedoch gut darauf vorbereitet, uns mit einer innovativen Benutzeroberfläche zu helfen, die Metadaten aller Inhalte und Informationen darüber, welche Filme verfügbar sind, enthält und die Möglichkeit bietet, Beobachtungslisten zu erstellen. Es verfügte über eine generische REST-API basierend auf dem JSON-Schema, einen HTTP-Antwortcode, der auch in der modernen Architektur verwendet wird, und ein OAuth-Sicherheitsmodell, das damals für eine Front-End-Anwendung erforderlich war. Dies ermöglichte den Übergang von einem öffentlichen Modell der Bereitstellung von Streaming-Inhalten zu einem privaten.
Das Problem bei der Umstellung war die Fragmentierung, da unser System nun zwei Dienste betrieb, die auf völlig unterschiedlichen Funktionsprinzipien basierten – einer auf Rest, JSON und OAuth, der andere auf RPC, XML und einem Benutzersicherheitsmechanismus basierend auf dem NTBA-Tokensystem. Dies war die erste Hybridarchitektur.
Im Wesentlichen gab es eine Firewall zwischen unseren beiden Teams, da sich die API anfangs nicht sehr gut mit NCCP skalieren ließ, was zu Spannungen zwischen den Teams führte. Die Unterschiede bestanden in Diensten, Protokollen, Schaltkreisen und Sicherheitsmodulen, und Entwickler mussten oft zwischen völlig unterschiedlichen Kontexten wechseln.
In diesem Zusammenhang hatte ich ein Gespräch mit einem der leitenden Ingenieure des Unternehmens, dem ich die Frage stellte: „Was sollte die richtige langfristige Architektur sein?“ und er stellte die Gegenfrage: „Sie sind wahrscheinlich mehr besorgt.“ über die organisatorischen Konsequenzen – was passiert, wenn wir diese Dinge integrieren und sie das, was wir gelernt haben, gut zu machen, zunichte machen? Dieser Ansatz ist für Conways Gesetz sehr relevant: „Organisationen, die Systeme entwerfen, werden durch ein Design eingeschränkt, das die Kommunikationsstruktur dieser Organisation nachbildet.“ Dies ist eine sehr abstrakte Definition, daher bevorzuge ich eine spezifischere: „Jede Software spiegelt die Organisationsstruktur wider, die sie erstellt hat.“ Hier ist mein Lieblingszitat von Eric Raymond: „Wenn vier Entwicklerteams an einem Compiler arbeiten, erhalten Sie am Ende einen Compiler mit vier Durchgängen.“ Nun, Netflix verfügt über einen Compiler mit vier Durchgängen, und so arbeiten wir.
Wir können sagen, dass in diesem Fall der Schwanz mit dem Hund wedelt. Unsere erste Priorität ist nicht die Lösung, sondern die Organisation; es ist die Organisation, die die Architektur vorantreibt, die wir haben. Nach und nach sind wir von einem Sammelsurium an Diensten zu einer Architektur übergegangen, die wir Blade Runner nannten, denn hier geht es um Edge-Dienste und die Fähigkeit von NCCP, getrennt und direkt in den Zuul-Proxy, das API-Gateway und die entsprechenden Funktionen integriert zu werden „Teile“ wurden in neue Microservices mit erweiterten Funktionen für Sicherheit, Wiedergabe, Datensortierung usw. umgewandelt.
Somit lässt sich sagen, dass Abteilungsstrukturen und Unternehmensdynamik eine wichtige Rolle bei der Gestaltung des Systemdesigns spielen und ein Faktor sind, der Veränderungen fördert oder behindert. Die Architektur von Microservices ist komplex und organisch, und ihre Gesundheit basiert auf Disziplin und eingeführtem Chaos.
Ein bisschen Werbung
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com