Aquest article conté alguns patrons comuns per ajudar els enginyers a treballar amb serveis a gran escala als quals accedeixen milions d'usuaris.
Segons l'experiència de l'autor, aquesta no és una llista exhaustiva, però sí eficaç consell. Així doncs, comencem.
Traduït amb suport .
Primer nivell
Les mesures que s'enumeren a continuació són relativament senzilles d'implementar, però tenen un gran impacte. Si no els heu provat abans, us sorprendrà les millores significatives.
Infraestructura com a codi
La primera part del consell és implementar la infraestructura com a codi. Això vol dir que heu de tenir una manera programàtica de desplegar tota la infraestructura. Sembla complicat, però en realitat estem parlant del codi següent:
Desplegament de 100 màquines virtuals
- amb Ubuntu
- 2 GB de RAM cadascun
- tindran el codi següent
- amb aquests paràmetres
Podeu fer un seguiment dels canvis a la vostra infraestructura i tornar-hi ràpidament mitjançant el control de versions.
El modernista en mi diu que podeu utilitzar Kubernetes/Docker per fer tot l'anterior, i té raó.
A més, podeu proporcionar automatització mitjançant Chef, Puppet o Terraform.
Integració i lliurament contínues
Per crear un servei escalable, és important tenir una canalització de compilació i prova per a cada sol·licitud d'extracció. Fins i tot si la prova és molt senzilla, almenys s'assegurarà que el codi que implementeu es compila.
Cada vegada que en aquesta etapa responeu a la pregunta: el meu muntatge compilarà i passarà proves, és vàlid? Pot semblar una barra baixa, però resol molts problemes.
No hi ha res més bonic que veure aquestes paparres
Per a aquesta tecnologia podeu avaluar Github, CircleCI o Jenkins.
Equilibradors de càrrega
Per tant, volem executar un equilibrador de càrrega per redirigir el trànsit i assegurar una càrrega igual a tots els nodes o el servei continua en cas de fallada:
Un equilibrador de càrrega normalment fa una bona feina distribuïnt el trànsit. La millor pràctica és sobreequilibrar perquè no tinguis ni un sol punt de fallada.
Normalment, els equilibradors de càrrega es configuren al núvol que utilitzeu.
RayID, identificador de correlació o UUID per a les sol·licituds
Alguna vegada us heu trobat amb un error d'aplicació amb un missatge com aquest: "Alguna cosa ha anat malament. Deseu aquest identificador i envieu-lo al nostre equip d'assistència"?
Un identificador únic, identificador de correlació, RayID o qualsevol de les variacions, és un identificador únic que us permet fer el seguiment d'una sol·licitud al llarg del seu cicle de vida. Això us permet fer un seguiment de tota la ruta de la sol·licitud als registres.
L'usuari fa una sol·licitud al sistema A, després A contacta amb B, que contacta amb C, l'emmagatzema a X i, a continuació, la sol·licitud es retorna a A
Si us connecteu de forma remota a màquines virtuals i intenteu traçar el camí de la sol·licitud (i correlacioneu manualment quines trucades s'estan fent), us tornaria boig. Tenir un identificador únic fa la vida molt més fàcil. Aquesta és una de les coses més senzilles que podeu fer per estalviar temps a mesura que el vostre servei creix.
Nivell intermedi
Els consells aquí són més complexos que els anteriors, però les eines adequades faciliten la tasca, proporcionant un retorn de la inversió fins i tot a les petites i mitjanes empreses.
Registre centralitzat
Felicitats! Heu desplegat 100 màquines virtuals. L'endemà, el CEO ve i es queixa d'un error que va rebre mentre provava el servei. Informa de l'identificador corresponent del qual hem parlat més amunt, però haureu de mirar els registres de 100 màquines per trobar la que va provocar l'accident. I cal trobar-lo abans de la presentació de demà.
Tot i que sembla una aventura divertida, el millor és assegurar-vos que teniu la possibilitat de cercar totes les revistes en un sol lloc. Vaig resoldre el problema de centralitzar els registres mitjançant la funcionalitat integrada de la pila ELK: admet la col·lecció de registres cercables. Això realment ajudarà a resoldre el problema de trobar una revista específica. Com a avantatge, podeu crear gràfics i altres coses divertides com aquesta.
Funcionalitat de pila ELK
Agents de seguiment
Ara que el vostre servei està en funcionament, heu d'assegurar-vos que funcioni correctament. La millor manera de fer-ho és executar-ne diversos agents, que treballen en paral·lel i comproven que funciona i es fan les operacions bàsiques.
En aquest punt ho comproveu la construcció en funcionament se sent bé i funciona bé.
Per a projectes de mida petita i mitjana, recomano Postman per supervisar i documentar les API. Però, en general, només voleu assegurar-vos que teniu una manera de saber quan s'ha produït una interrupció i rebre una notificació oportuna.
Autoescala en funció de la càrrega
És molt senzill. Si teniu sol·licituds de servei de VM i s'aproxima al 80% d'ús de memòria, podeu augmentar els seus recursos o afegir més VM al clúster. L'execució automàtica d'aquestes operacions és excel·lent per als canvis de potència elàstica sota càrrega. Però sempre heu de tenir cura de quants diners gasteu i establir límits raonables.
Amb la majoria de serveis al núvol, podeu configurar-lo per a escala automàtica utilitzant més servidors o servidors més potents.
Sistema d'experimentació
Una bona manera de llançar actualitzacions de manera segura és poder provar alguna cosa per a l'1% dels usuaris durant una hora. Per descomptat, heu vist aquests mecanismes en acció. Per exemple, Facebook mostra a parts de l'audiència un color diferent o canvia la mida de la lletra per veure com els usuaris perceben els canvis. Això s'anomena prova A/B.
Fins i tot el llançament d'una funció nova es pot iniciar com a experiment i, a continuació, determinar com llançar-lo. També teniu la possibilitat de "recordar" o canviar la configuració sobre la marxa en funció de la funció que està causant la degradació del vostre servei.
Nivell avançat
Aquí hi ha consells que són bastant difícils d'implementar. Probablement necessitareu una mica més de recursos, de manera que una empresa petita o mitjana tindrà dificultats per gestionar-ho.
Desplegaments blau-verd
Això és el que jo anomeno la manera de desplegar-se "Erlang". Erlang es va fer molt utilitzat quan van aparèixer les companyies telefòniques. Els softswitches van començar a utilitzar-se per encaminar les trucades telefòniques. L'objectiu principal del programari d'aquests commutadors era no deixar caure les trucades durant les actualitzacions del sistema. Erlang té una bona manera de carregar un mòdul nou sense bloquejar l'anterior.
Aquest pas depèn de la presència d'un equilibrador de càrrega. Imaginem que teniu la versió N del vostre programari i després voleu implementar la versió N+1.
Vostè podriem només heu d'aturar el servei i llançar la següent versió en un moment que funcioni per als vostres usuaris i obtenir un temps d'inactivitat. Però suposem que ho tens de veritat condicions estrictes de SLA. Per tant, un SLA del 99,99% significa que podeu sortir de línia només 52 minuts a l'any.
Si realment voleu aconseguir aquests indicadors, necessiteu dos desplegaments alhora:
- el que és ara mateix (N);
- següent versió (N+1).
Digueu a l'equilibrador de càrrega que redirigeixi un percentatge del trànsit a la versió nova (N+1) mentre monitoreu activament les regressions.
Aquí tenim un desplegament N verd que funciona bé. Estem intentant passar a la següent versió d'aquest desplegament
Primer enviem una prova molt petita per veure si el nostre desplegament N+1 funciona amb una petita quantitat de trànsit:
Finalment, tenim un conjunt de comprovacions automatitzades que eventualment executem fins que finalitzi el nostre desplegament. Si tu molt molt Aneu amb compte, també podeu desar el vostre desplegament N per sempre per a una recuperació ràpida en cas de regressió dolenta:
Si voleu anar a un nivell encara més avançat, deixeu que tot el desplegament blau-verd s'executi automàticament.
Detecció d'anomalies i mitigació automàtica
Atès que teniu un registre centralitzat i una bona recollida de registres, ja podeu establir objectius més alts. Per exemple, predir els errors de manera proactiva. Es fan un seguiment de les funcions als monitors i als registres i es creen diversos diagrames, i podeu predir amb antelació què sortirà malament:
Un cop detectades anomalies, comenceu a examinar algunes de les pistes que ofereix el servei. Per exemple, un augment de la càrrega de la CPU pot indicar que un disc dur està fallant, mentre que un augment de les sol·licituds pot indicar que cal augmentar l'escala. Aquest tipus de dades estadístiques permeten fer el servei proactiu.
Amb aquests coneixements, podeu escalar en qualsevol dimensió i canviar de manera proactiva i reactiva les característiques de les màquines, bases de dades, connexions i altres recursos.
Això és tot!
Aquesta llista de prioritats us estalviarà molts problemes si esteu creant un servei al núvol.
L'autor de l'article original convida els lectors a deixar els seus comentaris i fer canvis. L'article es distribueix com a codi obert, sol·licituds d'extracció de l'autor .
Què més cal llegir sobre el tema:
Font: www.habr.com