Josh Evans vertelt over de chaotische en kleurrijke wereld van Netflix-microservices, beginnend bij de basis: de anatomie van microservices, de uitdagingen die gepaard gaan met gedistribueerde systemen, en hun voordelen. Voortbouwend op deze basis onderzoekt hij de culturele, architecturale en operationele praktijken die leiden tot microservice-beheersing.
In tegenstelling tot operationele drift zijn de introductie van nieuwe talen voor de internationalisering van diensten en nieuwe technologieën zoals containers bewuste beslissingen om nieuwe complexiteit aan de omgeving toe te voegen. Mijn operationele team standaardiseerde op basis van de beste technologische roadmap voor Netflix, die werd ingebed in vooraf gedefinieerde best practices op basis van Java en EC2, maar naarmate het bedrijf groeide, begonnen ontwikkelaars nieuwe componenten toe te voegen, zoals Python, Ruby, Node-JS en Docker.
Ik ben er erg trots op dat wij de eersten waren die pleitten voor een goede werking van ons product, zonder te wachten op klachten van klanten. Het begon allemaal eenvoudig genoeg: we hadden besturingsprogramma's in Python en een paar backoffice-applicaties in Ruby, maar het werd een stuk interessanter toen onze webontwikkelaars aankondigden dat ze de JVM gingen dumpen en het web gingen verhuizen. toepassing op het Node-softwareplatform.js. Na de introductie van Docker werd het veel complexer. We volgden de logica en de technologieën die we bedachten werden werkelijkheid toen we ze voor klanten implementeerden, omdat ze heel logisch waren. Ik zal je vertellen waarom dit zo is.
API Gateway heeft feitelijk de mogelijkheid om geweldige scripts te integreren die kunnen fungeren als eindpunten voor UI-ontwikkelaars. Ze hebben elk van deze scripts zo geconverteerd dat ze, na het aanbrengen van wijzigingen, deze konden implementeren op productie en vervolgens op gebruikersapparaten, en al deze wijzigingen werden gesynchroniseerd met eindpunten die in de API-gateway draaiden.
Dit herhaalde echter het probleem van het creëren van een nieuwe monoliet waarbij de API-service zodanig werd overladen met code dat verschillende faalscenario's zich voordeden. Sommige eindpunten zijn bijvoorbeeld verwijderd, of scripts genereerden willekeurig zoveel versies van iets dat de versies al het beschikbare geheugen van de API-service in beslag namen.
Het was logisch om deze eindpunten uit de API-service te halen. Om dit te doen, hebben we Node.js-componenten gemaakt die als kleine applicaties in Docker-containers draaiden. Hierdoor konden we eventuele problemen en crashes die door deze knooppunttoepassingen werden veroorzaakt, isoleren.
De kosten van deze veranderingen zijn vrij groot en bestaan uit de volgende factoren:
- Productiviteitstools. Het beheren van nieuwe technologieën vereiste nieuwe tools omdat het UI-team, dat zeer goede scripts gebruikte om een efficiënt model te creëren, niet veel tijd hoefde te besteden aan het beheren van de infrastructuur, ze hoefden alleen maar scripts te schrijven en hun functionaliteit te controleren.
Opportunity Insight and Sorting - Een belangrijk voorbeeld zijn de nieuwe tools die nodig zijn om informatie over prestatiefactoren te achterhalen. Het was nodig om te weten hoeveel de processor bezet was, hoe het geheugen werd gebruikt, en voor het verzamelen van deze informatie waren verschillende hulpmiddelen nodig. - Fragmentatie van basisafbeeldingen - de eenvoudige basis-AMI is meer gefragmenteerd en gespecialiseerd geworden.
- Knooppuntbeheer. Er is geen kant-en-klare architectuur of technologie beschikbaar waarmee u knooppunten in de cloud kunt beheren. Daarom hebben we Titus gebouwd, een containerbeheerplatform dat schaalbare en betrouwbare containerimplementatie en cloudintegratie met Amazon AWS biedt.
- Duplicatie van een bibliotheek of platform. Om nieuwe technologieën met dezelfde kernfunctionaliteit van het platform te kunnen bieden, moesten deze worden gedupliceerd naar cloudgebaseerde Node.js-ontwikkelaarstools.
- Leercurve en industriële ervaring. De introductie van nieuwe technologieën creëert onvermijdelijk nieuwe uitdagingen die overwonnen moeten worden en waarvan geleerd moet worden.
We konden ons dus niet beperken tot één ‘verharde weg’ en moesten voortdurend nieuwe manieren bedenken om onze technologieën vooruit te helpen. Om de kosten laag te houden, hebben we de gecentraliseerde ondersteuning beperkt en ons geconcentreerd op de JVM, nieuwe knooppunten en Docker. We gaven prioriteit aan effectieve impact, informeerden teams over de kosten van hun beslissingen en moedigden hen aan om te zoeken naar manieren om de oplossingen met grote impact die ze al hadden ontwikkeld, opnieuw te gebruiken. We hebben deze aanpak gebruikt bij het vertalen van de dienst in vreemde talen om het product aan internationale klanten te leveren. Voorbeelden hiervan zijn relatief eenvoudige clientbibliotheken die automatisch kunnen worden gegenereerd, zodat het vrij eenvoudig is om een Python-versie, een Ruby-versie, een Java-versie, etc. te maken.
We waren voortdurend op zoek naar mogelijkheden om bewezen technologieën te gebruiken die zich op de ene plek en in andere vergelijkbare situaties hadden bewezen.
Laten we het hebben over het laatste element: veranderingen of variaties. Kijk hoe de consumptie van ons product ongelijkmatig varieert per dag van de week en per uur gedurende de dag. Je zou kunnen zeggen dat 9 uur 's ochtends de moeilijkste tijd is voor Netflix, wanneer de belasting van het systeem zijn maximum bereikt.
Hoe kunnen we een hoge implementatiesnelheid van software-innovaties bereiken, dat wil zeggen door voortdurend nieuwe wijzigingen aan het systeem aan te brengen, zonder onderbrekingen in de dienstverlening te veroorzaken en zonder ongemak voor onze klanten te veroorzaken? Netflix heeft dit bereikt door het gebruik van Spinnaker, een nieuw wereldwijd cloudgebaseerd platform voor beheer en continue levering (CD).
Cruciaal is dat Spinnaker is ontworpen om onze best practices te integreren, zodat we, wanneer we componenten in de productie implementeren, de output rechtstreeks in onze medialeveringstechnologie kunnen integreren.
We hebben twee technologieën in onze leveringspijplijn kunnen opnemen die we zeer waarderen: geautomatiseerde kanarie-analyse en gefaseerde implementatie. Canarische analyse betekent dat we een klein beetje verkeer naar de nieuwe versie van de code leiden en de rest van het productieverkeer door de oude versie laten gaan. Vervolgens controleren we hoe de nieuwe code met de taak omgaat - beter of slechter dan de bestaande.
Een gespreide uitrol betekent dat als een uitrol in de ene regio problemen oplevert, we overgaan tot een uitrol in een andere regio. In dit geval moet de bovengenoemde checklist in de productiepijplijn worden opgenomen. Ik zal je wat tijd besparen en raad je aan mijn vorige lezing, Engineering Global Netflix Operations in the Cloud, te lezen als je geïnteresseerd bent om dieper in dit onderwerp te duiken. De video-opname van de toespraak kan worden bekeken door de link onderaan de dia te volgen.
Aan het einde van het gesprek zal ik kort ingaan op de organisatie en architectuur van Netflix. Helemaal aan het begin hadden we een schema genaamd Electronic Delivery, de eerste versie van NRDP 1.x mediastreaming. De term "backstream" kan hier worden gebruikt omdat de gebruiker aanvankelijk alleen inhoud kon downloaden om deze later op het apparaat af te spelen. Het allereerste digitale leveringsplatform van Netflix, in 2009, zag er ongeveer zo uit.
Het gebruikersapparaat bevatte de Netflix-applicatie, die bestond uit een UI-interface, beveiligingsmodules, service-activatie en -weergave, gebaseerd op het NRDP-platform - Netflix Ready Device Platform.
Destijds was de gebruikersinterface heel eenvoudig. Het bevatte een zogenaamde Queque Reader, en de gebruiker ging naar de site om iets aan Queque toe te voegen en vervolgens de toegevoegde inhoud op zijn apparaat te bekijken. Het positieve was dat het frontendteam en het backendteam tot dezelfde Electronic Delivery-organisatie behoorden en een nauwe werkrelatie hadden. De payload is gemaakt op basis van XML. Tegelijkertijd werd de Netflix API voor de dvd-business gecreëerd, die applicaties van derden aanmoedigde om verkeer naar onze service te leiden.
De Netflix API was echter goed voorbereid om ons te helpen met een innovatieve gebruikersinterface, met metadata van alle inhoud en informatie over welke films beschikbaar waren, waardoor de mogelijkheid ontstond om volglijsten te genereren. Het had een generieke REST API gebaseerd op het JSON-schema, HTTP Response Code, dezelfde die wordt gebruikt in de moderne architectuur, en een OAuth-beveiligingsmodel, wat destijds nodig was voor een front-end-applicatie. Dit maakte het mogelijk om van een openbaar model voor het leveren van streaming content over te stappen naar een privémodel.
Het probleem met de transitie was fragmentatie, aangezien ons systeem nu twee services exploiteert die gebaseerd zijn op totaal verschillende werkingsprincipes: de ene op Rest, JSON en OAuth, de andere op RPC, XML en een gebruikersbeveiligingsmechanisme gebaseerd op het NTBA-tokensysteem. Dit was de eerste hybride architectuur.
Er was in wezen een firewall tussen onze twee teams, omdat de API aanvankelijk niet erg goed schaalde met NCCP en dit leidde tot wrijving tussen de teams. De verschillen zaten in services, protocollen, circuits, beveiligingsmodules, en ontwikkelaars moesten vaak schakelen tussen totaal verschillende contexten.
In dit verband had ik een gesprek met een van de senior ingenieurs van het bedrijf, aan wie ik de vraag stelde: “Wat zou de juiste architectuur voor de lange termijn moeten zijn?” en hij stelde de tegenvraag: “U maakt zich waarschijnlijk meer zorgen over de gevolgen voor de organisatie – wat gebeurt er als we deze dingen integreren, en ze breken met wat we hebben geleerd goed te doen? Deze benadering is zeer relevant voor de wet van Conway: "Organisaties die systemen ontwerpen, worden beperkt door een ontwerp dat de communicatiestructuur van die organisatie repliceert." Dit is een heel abstracte definitie, dus ik geef de voorkeur aan een meer specifieke definitie: “Elk stukje software weerspiegelt de organisatiestructuur die het heeft gecreëerd.” Hier is mijn favoriete quote van Eric Raymond: "Als je vier teams van ontwikkelaars hebt die aan een compiler werken, krijg je uiteindelijk een compiler met vier passages." Nou, Netflix heeft een vier-pass-compiler, en zo werken wij.
We kunnen zeggen dat in dit geval de staart de hond kwispelt. Onze eerste prioriteit is niet de oplossing, maar de organisatie; het is de organisatie die de architectuur aanstuurt die we hebben. Geleidelijk aan zijn we van een mengelmoes van services overgestapt op een architectuur die we Blade Runner noemden, omdat we het hier hebben over edge-services en de mogelijkheid om NCCP te scheiden en direct te integreren in de Zuul-proxy, API-gateway en de bijbehorende functionele “stukjes” zijn omgezet in nieuwe microservices met meer geavanceerde functies op het gebied van beveiliging, herhaling, gegevenssortering, enz.
Er kan dus worden gezegd dat afdelingsstructuren en bedrijfsdynamiek een belangrijke rol spelen bij het vormgeven van systeemontwerp en een factor zijn die verandering bevordert of belemmert. De architectuur van microservices is complex en organisch, en de gezondheid ervan is gebaseerd op discipline en geïntroduceerde chaos.
wat reclame
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com