Levaches meses redeseñando o teu monolito en microservizos e, finalmente, todos uníronse para cambiar o interruptor. Vas á primeira páxina web... e non pasa nada. Volve cargalo, e outra vez nada bo, o sitio é tan lento que non responde durante varios minutos. Que pasou?
Na súa charla, Jimmy Bogard realizará unha "autopsia" sobre un desastre de microservizos da vida real. Mostrará os problemas de modelado, desenvolvemento e produción que descubriu, e como o seu equipo transformou lentamente o novo monolito distribuído na imaxe final da cordura. Aínda que é imposible evitar completamente os erros de deseño, polo menos pode identificar os problemas no inicio do proceso de deseño para garantir que o produto final se converta nun sistema distribuído fiable.
Ola a todos, son Jimmy e hoxe ides escoitar como evitar megadesastres ao crear microservizos. Esta é a historia dunha empresa na que traballei durante aproximadamente ano e medio para evitar que o seu barco chocase cun iceberg. Para contar esta historia correctamente, teremos que retroceder no tempo e falar de onde comezou esta empresa e de como creceu a súa infraestrutura de TI co paso do tempo. Para protexer os nomes dos inocentes neste desastre, cambiei o nome desta empresa a Bell Computers. A seguinte diapositiva mostra como era a infraestrutura de TI de tales empresas a mediados dos anos 90. Esta é unha arquitectura típica dun gran servidor HP Tandem Mainframe universal tolerante a fallos para operar unha ferretería informática.
Necesitaban construír un sistema para xestionar todos os pedidos, vendas, devolucións, catálogos de produtos e base de clientes, polo que escolleron a solución mainframe máis común naquel momento. Este sistema xigantesco contiña toda a información sobre a empresa, todo o posible, e cada transacción realizábase a través deste mainframe. Eles gardaban todos os seus ovos nunha mesma cesta e pensaron que iso era normal. O único que non se inclúe aquí son os catálogos de pedidos por correo e a realización de pedidos por teléfono.
Co paso do tempo, o sistema fíxose cada vez máis grande e acumulouse nel unha gran cantidade de lixo. Ademais, COBOL non é a linguaxe máis expresiva do mundo, polo que o sistema acabou sendo un gran e monolítico lixo. En 2000, viron que moitas empresas tiñan sitios web a través dos cales realizaban absolutamente todos os seus negocios, e decidiron construír o seu primeiro sitio web comercial de punto com.
O deseño inicial parecía bastante agradable e consistía nun sitio de nivel superior bell.com e unha serie de subdominios para aplicacións individuais: catalog.bell.com, accounts.bell.com, orders.bell.com, busca de produtos search.bell. com. Cada subdominio usou o marco ASP.Net 1.0 e as súas propias bases de datos, e todos falaron co backend do sistema. Non obstante, todas as ordes seguían procesándose e executándose nun único e enorme mainframe, no que quedaba todo o lixo, pero o front end eran sitios web separados con aplicacións individuais e bases de datos separadas.
Polo tanto, o deseño do sistema parecía ordenado e lóxico, pero o sistema real era o que se mostra na seguinte diapositiva.
Todos os elementos dirixían chamadas entre si, accedeu ás API, dlls de terceiros incrustadas e similares. Moitas veces ocorría que os sistemas de control de versións agarraban o código doutra persoa, metíano dentro do proxecto e despois todo se rompería. MS SQL Server 2005 usou o concepto de servidores de ligazóns, e aínda que non mostrei as frechas na diapositiva, cada unha das bases de datos tamén se falaba entre elas, porque non hai nada de malo en construír táboas baseadas en datos obtidos de varias bases de datos.
Dado que agora tiñan certa separación entre as diferentes áreas lóxicas do sistema, isto converteuse en manchas de sucidade distribuídas, quedando a maior parte de lixo no backend do mainframe.
O curioso foi que este mainframe foi construído polos competidores de Bell Computers e aínda era mantido polos seus consultores técnicos. Convencida do rendemento insatisfactorio das súas aplicacións, a empresa decidiu desfacerse delas e redeseñar o sistema.
A aplicación existente levaba 15 anos en produción, o que supón un récord para as aplicacións baseadas en ASP.Net. O servizo aceptou pedidos de todo o mundo e os ingresos anuais desta única aplicación alcanzaron os mil millóns de dólares. Unha parte importante do beneficio foi xerada polo sitio web bell.com. Os venres negros, o número de pedidos realizados a través do sitio alcanzou varios millóns. Non obstante, a arquitectura existente non permitiu ningún desenvolvemento, xa que as ríxidas interconexións dos elementos do sistema practicamente non permitían realizar ningún cambio no servizo.
O problema máis grave foi a imposibilidade de facer un pedido dun país, pagalo noutro e envialo a un terceiro, a pesar de que ese esquema comercial é moi común nas empresas globais. O sitio web existente non permitía nada parecido, polo que tiveron que aceptar e facer estes pedidos por teléfono. Isto levou á empresa a pensar cada vez máis en cambiar a arquitectura, en particular en cambiar aos microservizos.
Fixeron o intelixente mirando outras empresas para ver como resolveran un problema semellante. Unha destas solucións foi a arquitectura de servizos de Netflix, que consta de microservizos conectados mediante unha API e unha base de datos externa.
A dirección de Bell Computers decidiu construír esa arquitectura, uníndose a certos principios básicos. En primeiro lugar, eliminaron a duplicación de datos mediante un enfoque de base de datos compartida. Non se enviaron datos, pola contra, todos os que o necesitaban tiñan que acudir a unha fonte centralizada. A isto seguiu o illamento e a autonomía: cada servizo era independente dos outros. Decidiron usar a API web para absolutamente todo: se quería obter datos ou facer cambios noutro sistema, todo facíase a través da API web. A última gran cousa foi un novo mainframe chamado "Bell on Bell" en oposición ao mainframe "Bell" baseado no hardware dos competidores.
Entón, ao longo de 18 meses, construíron o sistema arredor destes principios fundamentais e levárono á preprodución. Volvendo ao traballo despois da fin de semana, os desenvolvedores reuníronse e acenderon todos os servidores aos que estaba conectado o novo sistema. 18 meses de traballo, centos de desenvolvedores, o hardware Bell máis moderno e ningún resultado positivo! Isto decepcionou a moita xente porque executaron este sistema nos seus portátiles moitas veces e todo estaba ben.
Foron intelixentes para botar todo o seu diñeiro para resolver este problema. Instalaron os racks de servidores máis modernos con interruptores, usaron fibra óptica gigabit, o hardware de servidor máis poderoso cunha cantidade insólita de RAM, conectárono todo, configurárono e, de novo, nada! Entón comezaron a sospeitar que o motivo podería ser os tempos de espera, polo que entraron en todas as configuracións web, todas as configuracións da API e actualizaron toda a configuración de tempo de espera aos valores máximos, de xeito que o único que podían facer era sentarse e esperar a que pasase algo. ao sitio. Agardaron e esperaron e esperaron 9 minutos e medio ata que por fin se cargara o sitio web.
Despois diso, decatáronse de que a situación actual precisaba dunha análise exhaustiva e convidáronnos. O primeiro que descubrimos foi que, durante os 18 meses de desenvolvemento, non se creou nin un só "micro" real: todo se fixo máis grande. Despois disto, comezamos a escribir unha autopsia, tamén coñecida como "retrospectiva", ou "retrospectiva triste", tamén coñecida como "tormenta de culpas", semellante a unha "tormenta de cerebros", para comprender a causa do desastre.
Tiñamos varias pistas, unha delas era a completa saturación do tráfico no momento da chamada API. Cando utilizas unha arquitectura de servizo monolítica, podes comprender de inmediato o que pasou mal porque tes un único rastro de pila que informa de todo o que puido causar o fallo. No caso de que unha morea de servizos accedan simultaneamente á mesma API, non hai forma de rastrexar o rastrexo, excepto empregar ferramentas adicionais de monitorización da rede como WireShark, grazas ás cales pode examinar unha única solicitude e descubrir o que pasou durante a súa implementación. Así que tomamos unha páxina web e pasamos case 2 semanas xuntando as pezas do crebacabezas, facendo unha variedade de chamadas e analizando a que conduciu cada unha delas.
Mira esta imaxe. Mostra que unha solicitude externa solicita ao servizo que faga moitas chamadas internas que regresan. Resulta que cada chamada interna fai saltos adicionais para poder atender esta solicitude de forma independente, porque non pode virar a ningún outro lugar para obter a información necesaria. Esta imaxe parece unha fervenza de chamadas sen sentido, xa que a solicitude externa chama a servizos adicionais, que chaman a outros servizos adicionais, etc., case ata o infinito.
A cor verde deste diagrama mostra un semicírculo no que os servizos se chaman entre si: o servizo A chama ao servizo B, o servizo B chama ao servizo C e volve chamar ao servizo A. Como resultado, obtemos un "bloqueo distribuído". Unha única solicitude creou mil chamadas de API de rede e, dado que o sistema non contaba con tolerancia a fallos e protección contra bucles, a solicitude fallaría se mesmo unha destas chamadas API fallase.
Fixemos un pouco de matemáticas. Cada chamada de API tiña un SLA de non máis de 150 ms e un tempo de actividade do 99,9 %. Unha solicitude provocou 200 chamadas diferentes e, no mellor dos casos, a páxina podería mostrarse en 200 x 150 ms = 30 segundos. Por suposto, isto non foi bo. Multiplicando o 99,9 % do tempo de actividade por 200, obtivemos un 0 % de dispoñibilidade. Resulta que esta arquitectura estivo condenada ao fracaso dende o primeiro momento.
Preguntámoslles aos desenvolvedores como non recoñeceron este problema despois de 18 meses de traballo? Resultou que só contaban o SLA para o código que executaban, pero se o seu servizo chamaba a outro servizo, non contaban ese tempo no seu SLA. Todo o que se lanzou nun proceso adheriuse ao valor de 150 ms, pero o acceso a outros procesos de servizo aumentou o atraso total moitas veces. A primeira lección aprendida foi: "Tes ti o control do teu SLA ou o SLA tes o control?" No noso caso, foi o último.
O seguinte que descubrimos foi que sabían sobre o concepto de conceptos erróneos de computación distribuída, formulado por Peter Deitch e James Gosling, pero ignoraron a primeira parte do mesmo. Afirma que as declaracións "a rede é fiable", "latencia cero" e "rendemento infinito" son conceptos erróneos. Outros conceptos erróneos inclúen as afirmacións "a rede é segura", "a topoloxía nunca cambia", "sempre hai un só administrador", "o custo da transferencia de datos é cero" e "a rede é homoxénea".
Cometeron un erro porque probaron o seu servizo en máquinas locais e nunca se conectaron con servizos externos. Ao desenvolver localmente e usar unha caché local, nunca atoparon saltos de rede. En todos os 18 meses de desenvolvemento, nunca se preguntaron que podería pasar se os servizos externos se viron afectados.
Se observas os límites do servizo na imaxe anterior, podes ver que todos son incorrectos. Hai moitas fontes que aconsellan sobre como definir os límites do servizo, e a maioría fano mal, como Microsoft na seguinte diapositiva.
Esta imaxe é do blog de MS sobre o tema "Como crear microservizos". Isto mostra unha aplicación web sinxela, un bloque de lóxica empresarial e unha base de datos. A solicitude vén directamente, probablemente haxa un servidor para a web, un servidor para a empresa e outro para a base de datos. Se aumentas o tráfico, a imaxe cambiará un pouco.
Aquí vén un equilibrador de carga para distribuír o tráfico entre dous servidores web, unha caché situada entre o servizo web e a lóxica empresarial e outra caché entre a lóxica empresarial e a base de datos. Esta é exactamente a arquitectura que Bell utilizou para a súa aplicación de equilibrio de carga e implementación azul/verde a mediados da década de 2000. Ata algún tempo todo funcionou ben, xa que este esquema estaba pensado para unha estrutura monolítica.
A seguinte imaxe mostra como MS recomenda pasar dun monolito a microservizos, simplemente dividindo cada un dos servizos principais en microservizos separados. Foi durante a implementación deste esquema cando Bell cometeu un erro.
Dividiron todos os seus servizos en diferentes niveis, cada un dos cales constaba de moitos servizos individuais. Por exemplo, o servizo web incluía microservizos para a representación e autenticación de contidos, o servizo de lóxica empresarial consistía en microservizos para procesar pedidos e información de contas, a base de datos estaba dividida nun grupo de microservizos con datos especializados. Tanto a web, a lóxica empresarial como a base de datos eran servizos sen estado.
Non obstante, esta imaxe era completamente errónea porque non mapeaba ningunha unidade de negocio fóra do clúster de TI da empresa. Este esquema non tivo en conta ningunha conexión co mundo exterior, polo que non estaba claro como, por exemplo, obter análises comerciais de terceiros. Observo que tamén tiñan varios servizos inventados simplemente para desenvolver a carreira de empregados individuais que buscaban xestionar o maior número de persoas posible para conseguir máis cartos por iso.
Crían que pasar aos microservizos era tan sinxelo como levar a súa infraestrutura interna de capa física N-tier e pegar Docker nela. Vexamos como é a arquitectura tradicional de N-tier.
Consta de 4 niveis: o nivel de interface de usuario da IU, o nivel de lóxica empresarial, o nivel de acceso aos datos e a base de datos. Máis progresivo é o DDD (Domain-Driven Design), ou arquitectura orientada ao software, onde os dous niveis medios son obxectos de dominio e un repositorio.
Tentei mirar diferentes áreas de cambio, diferentes áreas de responsabilidade nesta arquitectura. Nunha aplicación típica de N niveis, clasifícanse diferentes áreas de cambio que permean a estrutura verticalmente de arriba a abaixo. Estes son o Catálogo, os axustes de configuración realizados en ordenadores individuais e as comprobacións de pago, que foron xestionadas polo meu equipo.
A peculiaridade deste esquema é que os límites destas áreas de cambio afectan non só ao nivel da lóxica empresarial, senón que tamén se estenden á base de datos.
Vexamos o que significa ser un servizo. Hai 6 propiedades características dunha definición de servizo: é un software que:
- creado e utilizado por unha organización específica;
- é responsable do contido, tratamento e/ou subministración dun determinado tipo de información dentro do sistema;
- pódese construír, despregar e executar de forma independente para satisfacer necesidades operativas específicas;
- comunícase cos consumidores e outros servizos, proporcionando información baseada en acordos ou garantías contractuais;
- protéxese contra accesos non autorizados e a súa información contra a perda;
- trata os fallos de forma que non supoñan danos informativos.
Todas estas propiedades pódense expresar nunha palabra "autonomía". Os servizos funcionan independentemente uns dos outros, satisfacen certas restricións e definen contratos en función dos cales as persoas poden recibir a información que necesitan. Non mencionei tecnoloxías específicas, cuxo uso é evidente.
Agora vexamos a definición de microservizos:
- un microservizo é de pequeno tamaño e está deseñado para resolver un problema específico;
- O microservizo é autónomo;
- Ao crear unha arquitectura de microservizos utilízase a metáfora urbanística. Esta é a definición do libro de Sam Newman, Building Microservices.
A definición de Contexto limitado está tomada do libro de Eric Evans Domain-Driven Design. Este é un patrón central en DDD, un centro de deseño de arquitectura que traballa con modelos arquitectónicos volumétricos, dividíndoos en diferentes contextos limitados e definindo explícitamente as interaccións entre eles.
En pocas palabras, un contexto limitado indica o ámbito no que se pode usar un módulo en particular. Dentro deste contexto atópase un modelo loxicamente unificado que se pode ver, por exemplo, no seu dominio empresarial. Se lle pregunta "quen é un cliente" ao persoal que participa nos pedidos, obterá unha definición, se lle pregunta aos implicados nas vendas, obterá outra e os intérpretes darán unha terceira definición.
Entón, Bounded Context di que se non podemos dar unha definición clara do que é un consumidor dos nosos servizos, definamos os límites dentro dos que podemos falar do significado deste termo, e despois definamos os puntos de transición entre estas diferentes definicións. É dicir, se falamos dun cliente dende o punto de vista de facer pedidos, isto significa isto e aquelo, e se dende o punto de vista das vendas, isto significa isto e aquelo.
A seguinte definición dun microservizo é a encapsulación de calquera tipo de operacións internas, evitando a "fuga" dos compoñentes do proceso de traballo ao ambiente. A continuación vén a "definición de contratos explícitos para interaccións externas, ou comunicacións externas", que se representa coa idea de contratos que retornan dos SLA. A última definición é a metáfora dunha célula, ou célula, que significa o encapsulamento completo dun conxunto de operacións dentro dun microservizo e a presenza nel de receptores para a comunicación co mundo exterior.
Entón dixemos aos mozos de Bell Computers: "Non podemos arranxar ningún caos que creaches porque non tes diñeiro para facelo, pero só arranxaremos un servizo para que todo se faga. sentido." Neste punto, comezarei contándoche como arranxamos o noso único servizo para que respondese ás solicitudes máis rápido de 9 minutos e medio.
22:30 min
Para continuar moi pronto...
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