Josh Evans fala do caótico e colorido mundo dos microservizos de Netflix, comezando polos conceptos básicos: a anatomía dos microservizos, os retos asociados aos sistemas distribuídos e os seus beneficios. Partindo desta base, explora as prácticas culturais, arquitectónicas e operativas que conducen ao dominio dos microservizos.
A diferenza da deriva operativa, a introdución de novos idiomas para a internacionalización dos servizos e as novas tecnoloxías como os contedores son decisións conscientes para engadir nova complexidade ao medio ambiente. O meu equipo de operacións normalizou a mellor folla de ruta tecnolóxica para Netflix, que se integrou en mellores prácticas predefinidas baseadas en Java e EC2, pero a medida que o negocio creceu, os desenvolvedores comezaron a engadir novos compoñentes como Python, Ruby, Node-JS e Docker.
Estou moi orgulloso de que fomos os primeiros en defender que o noso produto funcione ben sen esperar as queixas dos clientes. Todo empezou bastante sinxelo: tiñamos programas operativos en Python e algunhas aplicacións de back-office en Ruby, pero as cousas fixéronse moito máis interesantes cando os nosos desenvolvedores web anunciaron que ían abandonar a JVM e mover a web. aplicación á plataforma de software Node. js. Despois da introdución de Docker, as cousas fixéronse moito máis complexas. Seguimos a lóxica e as tecnoloxías que creamos fixéronse realidade cando as implementamos para os clientes porque tiñan moito sentido. Vouche dicir por que é así.
API Gateway realmente ten a capacidade de integrar excelentes scripts que poden actuar como puntos finais para os desenvolvedores de IU. Converteron cada un destes scripts de tal xeito que despois de facer cambios podían implantalos na produción e despois nos dispositivos dos usuarios, e todos estes cambios sincronizáronse con puntos finais que se executaban na pasarela da API.
Non obstante, isto repetiu o problema de crear un novo monolito onde o servizo API estaba sobrecargado de código de tal xeito que se producían varios escenarios de fallo. Por exemplo, elimináronse algúns puntos finais ou os scripts xeraron aleatoriamente tantas versións de algo que as versións ocuparon toda a memoria dispoñible do servizo API.
Era lóxico tomar estes puntos finais e retiralos do servizo API. Para iso, creamos compoñentes Node.js que se executaban como pequenas aplicacións en contedores Docker. Isto permitiunos illar calquera problema e fallo causado por estas aplicacións de nodos.
O custo destes cambios é bastante elevado e consta dos seguintes factores:
- Ferramentas de produtividade. A xestión das novas tecnoloxías requiría de novas ferramentas porque o equipo da IU, utilizando moi bos scripts para crear un modelo eficiente, non tiña que dedicar moito tempo á xestión da infraestrutura, só tiña que escribir scripts e comprobar a súa funcionalidade.
Perspicacia e clasificación de oportunidades: un exemplo clave son as novas ferramentas necesarias para descubrir información do controlador de rendemento. Era necesario saber canto ocupaba o procesador, como se utilizaba a memoria e recoller esta información requiría diferentes ferramentas. - Fragmentación de imaxes básicas: a AMI base simple tornouse máis fragmentada e especializada.
- Xestión de nodos. Non hai unha arquitectura ou tecnoloxía estándar dispoñible que che permita xestionar nós na nube, polo que creamos Titus, unha plataforma de xestión de contedores que ofrece implementación de contedores escalables e fiables e integración na nube con Amazon AWS.
- Duplicación dunha biblioteca ou plataforma. Proporcionar novas tecnoloxías coa mesma funcionalidade básica da plataforma requiriu duplicalas en ferramentas de desenvolvedores Node.js baseadas na nube.
- Curva de aprendizaxe e experiencia industrial. A introdución das novas tecnoloxías crea inevitablemente novos retos que hai que superar e aprender dos que.
Así, non podíamos limitarnos a unha "estrada asfaltada" e tivemos que construír constantemente novas formas de avanzar nas nosas tecnoloxías. Para reducir os custos, limitamos o soporte centralizado e centrámonos na JVM, novos nodos e Docker. Priorizamos o impacto efectivo, informamos aos equipos sobre o custo das súas decisións e animámolos a buscar formas de reutilizar as solucións de alto impacto que xa desenvolveran. Usamos este enfoque ao traducir o servizo a linguas estranxeiras para entregar o produto a clientes internacionais. Os exemplos inclúen bibliotecas cliente relativamente sinxelas que se poden xerar automaticamente, polo que é bastante sinxelo crear unha versión de Python, unha versión de Ruby, unha versión de Java, etc.
Buscabamos constantemente oportunidades para utilizar tecnoloxías comprobadas que se demostraran nun lugar e noutras situacións similares.
Falemos do último elemento: cambios ou variacións. Mira como o consumo do noso produto varía de forma desigual segundo o día da semana e por hora ao longo do día. Poderíase dicir que as 9 da mañá é o momento máis difícil para Netflix, cando a carga do sistema alcanza o seu máximo.
Como podemos conseguir unha alta velocidade de implementación de innovacións de software, é dicir, facer constantemente novos cambios no sistema, sen causar interrupcións na prestación do servizo e sen crear molestias aos nosos clientes? Netflix conseguiu isto mediante o uso de Spinnaker, unha nova plataforma global de xestión e entrega continua (CD) baseada na nube.
Esencialmente, Spinnaker foi deseñado para integrar as nosas mellores prácticas para que a medida que implantamos compoñentes na produción, poidamos integrar a saída directamente na nosa tecnoloxía de entrega de medios.
Puidemos incorporar dúas tecnoloxías ao noso pipeline de entrega que valoramos moito: análise canaria automatizada e despregamento por etapas. A análise de Canary significa que diriximos un reguero de tráfico á nova versión do código e pasamos o resto do tráfico de produción pola versión antiga. Despois comprobamos como o novo código fai fronte á tarefa, mellor ou peor que o existente.
Un lanzamento escalonado significa que se un lanzamento nunha rexión ten problemas, pasamos a un lanzamento noutra rexión. Neste caso, a lista de verificación mencionada anteriormente debe incluírse no proceso de produción. Aforrarei tempo e recoméndoche que consultes a miña charla anterior, Engineering Global Netflix Operations in the Cloud, se estás interesado en profundizar neste tema. Pódese ver a gravación en vídeo da intervención seguindo o enlace que aparece na parte inferior da diapositiva.
Ao remate da charla, falarei brevemente da organización e arquitectura de Netflix. Ao principio tiñamos un esquema chamado Electronic Delivery, que era a primeira versión do streaming multimedia NRDP 1.x. O termo "backstream" pódese usar aquí porque inicialmente o usuario só podía descargar contido para reproducilo posteriormente no dispositivo. A primeira plataforma de entrega dixital de Netflix, en 2009, parecía algo así.
O dispositivo do usuario contiña a aplicación Netflix, que consistía nunha interface de IU, módulos de seguridade, activación do servizo e reprodución, baseada na plataforma NRDP - Netflix Ready Device Platform.
Daquela a interface de usuario era moi sinxela. Contiña o que se chamaba Lector Queque, e o usuario ía ao sitio para engadir algo a Queque e despois ver o contido engadido no seu dispositivo. O positivo foi que o equipo de front-end e o back-end pertencían á mesma organización de Electronic Delivery e tiñan unha estreita relación de traballo. A carga útil foi creada baseándose en XML. Ao mesmo tempo, creouse a API de Netflix para o negocio do DVD, que animaba a aplicacións de terceiros a dirixir o tráfico ao noso servizo.
Non obstante, a API de Netflix estaba ben preparada para axudarnos cunha interface de usuario innovadora, que contén metadatos de todo o contido, información sobre que películas estaban dispoñibles, o que creou a posibilidade de xerar listas de vixilancia. Tiña unha API REST xenérica baseada no esquema JSON, o código de resposta HTTP, o mesmo que se usa na arquitectura moderna, e un modelo de seguridade OAuth, que era o que se requiría naquel momento para unha aplicación front-end. Isto permitiu pasar dun modelo público de entrega de contido en streaming a outro privado.
O problema coa transición foi a fragmentación, xa que agora o noso sistema operaba dous servizos baseados en principios de funcionamento completamente diferentes: un en Rest, JSON e OAuth, o outro en RPC, XML e un mecanismo de seguridade do usuario baseado no sistema de tokens NTBA. Esta foi a primeira arquitectura híbrida.
Había esencialmente un cortalumes entre os nosos dous equipos porque inicialmente a API non se ampliou moi ben con NCCP e isto provocou friccións entre os equipos. As diferenzas estaban en servizos, protocolos, circuítos, módulos de seguridade e os desenvolvedores tiñan que cambiar a miúdo entre contextos completamente diferentes.
A este respecto, mantiven unha conversación cun dos enxeñeiros superiores da empresa, a quen lle fixen a pregunta: "Cal debería ser a arquitectura correcta a longo prazo?" e fixo a contrapregunta: "Probablemente estea máis preocupado". sobre as consecuencias organizativas: que pasa se integramos estas cousas e rompen o que aprendimos a facer ben? Este enfoque é moi relevante para a Lei de Conway: "As organizacións que deseñan sistemas están restrinxidas por un deseño que replica a estrutura de comunicación desa organización". Esta é unha definición moi abstracta, polo que prefiro outra máis específica: "Calquera peza de software reflicte a estrutura organizativa que o creou". Aquí está a miña cita favorita de Eric Raymond: "Se tes catro equipos de desenvolvedores traballando nun compilador, acabarás cun compilador de catro pasos". Ben, Netflix ten un compilador de catro pasos, e así traballamos.
Podemos dicir que neste caso o rabo vai meneando o can. A nosa primeira prioridade non é a solución, senón a organización; é a organización que impulsa a arquitectura que temos. Aos poucos, dunha mestura de servizos, pasamos a unha arquitectura que chamamos Blade Runner, porque aquí estamos a falar de servizos de borde e da capacidade de NCCP para ser separado e integrado directamente no proxy Zuul, a pasarela de API e a funcionalidade correspondente. "anacos" convertéronse en novos microservizos con funcións de seguridade, reprodución, clasificación de datos, etc. máis avanzadas.
Así, pódese dicir que as estruturas departamentais e a dinámica da empresa xogan un papel importante na configuración do deseño do sistema e son un factor que favorece ou impide o cambio. A arquitectura de microservizos é complexa e orgánica, e a súa saúde baséase na disciplina e no caos introducido.
Un pouco de publicidade
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com