Habr está cambiando o mundo. Levamos máis dun ano blogueando. Hai uns seis meses, recibimos un feedback completamente lóxico de Khabrovites: "Dodo, dis en todas partes que tes o teu propio sistema. E cal é este sistema? E por que o precisa unha cadea de pizzas?
Sentámonos, pensamos e decatámonos de que tes razón. Intentamos explicar todo cos nosos dedos, pero sae en anacos e en ningún lado hai unha descrición completa do sistema. Comezou así unha longa viaxe de recollida de información, busca de autores e de redacción dunha serie de artigos sobre Dodo IS. Imos!
Agradecementos: Grazas por compartir os teus comentarios connosco. Grazas a el, por fin describimos o sistema, compilamos un radar técnico e en breve lanzaremos unha gran descrición dos nosos procesos. Sen vós estariamos alí sentados 5 anos máis.
Serie de artigos "Que é Dodo IS?" fala de:
- Monolito temperán en Dodo IS (2011-2015). (En progreso...)
- O camiño de back office: bases separadas e autobús. (estás aquí)
- Camiño do cliente: fachada sobre a base (2016-2017). (En progreso...)
- A historia dos verdadeiros microservizos. (2018-2019). (En progreso...)
- Acabado de serrado do monolito e estabilización da arquitectura. (En progreso...)
Se estás interesado en saber algo máis, escribe nos comentarios.
Opinión sobre a descrición cronolóxica do autor
Mantivo regularmente unha reunión para novos empregados sobre o tema "Arquitectura do sistema". Chamámoslle "Intro a Dodo IS Architecture" e forma parte do proceso de incorporación de novos desenvolvedores. Contando dunha forma ou doutra a nosa arquitectura, as súas características, nacín un certo enfoque histórico da descrición.
Tradicionalmente, consideramos o sistema como un conxunto de compoñentes (técnicos ou de nivel superior), módulos de negocio que interactúan entre si para acadar algún obxectivo. E se tal punto de vista está xustificado para o deseño, entón non é adecuado para a descrición e a comprensión. Hai varias razóns aquí:
- A realidade é diferente da que está no papel. Non todo sae como estaba previsto. E estamos interesados en saber como resultou e como funciona.
- Presentación coherente da información. De feito, pódese ir cronoloxicamente dende o principio ata o estado actual.
- De simple a complexo. Non universalmente, pero no noso caso si. A arquitectura pasou de enfoques máis simples a outros máis complexos. Moitas veces, a través da complicación, resolveuse problemas de velocidade e estabilidade de implementación, así como decenas doutras propiedades da lista de requisitos non funcionais ( ben dito sobre o contraste da complexidade con outros requisitos).
En 2011, a arquitectura Dodo IS tiña este aspecto:
Para 2020, volveuse un pouco máis complicado e quedou así:
Como se produciu esta evolución? Por que son necesarias diferentes partes do sistema? Que decisións arquitectónicas se tomaron e por que? Descubrímolo nesta serie de artigos.
Os primeiros problemas de 2016: por que os servizos deberían abandonar o monolito
Os primeiros artigos do ciclo versarán sobre os servizos que foron os primeiros en separarse do monolito. Para poñervos en contexto, vouvos contar que problemas tiñamos no sistema a principios de 2016, que tivemos que facer fronte á separación de servizos.
Unha única base de datos MySql, na que todas as aplicacións que existían nese momento en Dodo IS escribiron os seus rexistros. As consecuencias foron:
- Carga pesada (co 85% das solicitudes contabilizadas por lectura).
- A base creceu. Por iso, o seu custo e apoio converteuse nun problema.
- Punto único de falla. Se unha aplicación que escribía na base de datos de súpeto comezou a facelo de forma máis activa, entón outras aplicacións sentíano por si mesmas.
- Ineficiencia no almacenamento e consultas. Moitas veces os datos almacenábanse nalgunha estrutura que era conveniente para algúns escenarios pero non axeitada para outros. Os índices aceleran algunhas operacións, pero poden retardar outras.
- Algúns dos problemas foron eliminados mediante cachés feitos precipitadamente e réplicas de lectura nas bases (este será un artigo separado), pero só lles permitiu gañar tempo e non resolveron fundamentalmente o problema.
O problema era a presenza do propio monolito. As consecuencias foron:
- Lanzamentos únicos e raros.
- Dificultade no desenvolvemento conxunto dun gran número de persoas.
- Incapacidade para incorporar novas tecnoloxías, novos marcos e bibliotecas.
Os problemas coa base e o monolito foron descritos moitas veces, por exemplo, no contexto de accidentes a principios de 2018 (, и ), así que non me demore moito. Permítanme dicir que queriamos dar máis flexibilidade á hora de desenvolver servizos. Primeiro de todo, isto concernía aos que estaban máis cargados e rooteados en todo o sistema: Auth e Tracker.
O camiño do back office: bases e autobús separados
Navegación por capítulos
Esquema monolítico 2016
Aquí están os principais bloques do monólito Dodo IS 2016, e xusto debaixo hai unha transcrición das súas principais tarefas.
Entrega de caixa. Contabilidade de correos, expedición de pedidos a correos.
Centro de contacto. Aceptación de pedidos a través do operador.
Web. Os nosos sitios web (dodopizza.ru, dodopizza.co.uk, dodopizza.by, etc.).
Auth. Servizo de autorización e autenticación para o back office.
Rastreador. Rastreador de pedidos na cociña. Servizo de marcación de estados de preparación á hora de preparar un pedido.
Caixa do Restaurante. Toma de pedidos nun restaurante, interfaces de caixa.
Exportar. Carga de informes en 1C para a contabilidade.
Notificacións e facturas. Comandos de voz na cociña (por exemplo, "Chegou unha pizza nova") + impresión de facturas para mensaxeiros.
Xerente de quendas. Interfaces para o traballo do xefe de quenda: lista de pedidos, gráficos de rendemento, traslado de empregados á quenda.
Gerente de oficina. Interfaces para o traballo do franqueado e do xestor: recepción de empregados, informes sobre o traballo da pizzería.
Marcador de restaurante. Visualización de menús nos televisores das pizzerías.
administrador. Configuración dunha pizzería específica: menú, prezos, contabilidade, códigos promocionais, promocións, banners do sitio web, etc.
Conta persoal do empregado. Horarios de traballo dos empregados, información sobre os empregados.
Taboleiro de motivación de cociña. Unha pantalla separada que colga na cociña e mostra a velocidade das pizzas.
Comunicación. Envío de sms e correo electrónico.
Almacenamento de ficheiros. Servizo propio para recibir e emitir ficheiros estáticos.
Os primeiros intentos de solucionar os problemas axudáronnos, pero só foron un respiro temporal. Non se converteron en solucións do sistema, polo que estaba claro que había que facer algo coas bases. Por exemplo, para dividir a base de datos xeral en varias máis especializadas.
Comezando a descargar o Monolith: Separación de Auth e Tracker
Os principais servizos que despois gravaron e leron na base de datos máis que outros:
- Auth. Servizo de autorización e autenticación para o back office.
- Rastreador. Rastreador de pedidos na cociña. Servizo de marcación de estados de preparación á hora de preparar un pedido.
Que fai Auth?
Auth é un servizo a través do cal os usuarios inician sesión no back office (hai unha entrada independente independente no lado do cliente). Tamén se solicita na solicitude que se asegure de que os dereitos de acceso necesarios están presentes e de que estes dereitos non cambiaron desde o último inicio de sesión. A través dela, os dispositivos entran na pizzería.
Por exemplo, queremos abrir unha pantalla cos estados dos pedidos rematados no televisor colgado no salón. Despois abrimos auth.dodopizza.ru, seleccionamos "Iniciar sesión como dispositivo", aparece un código que se pode introducir nunha páxina especial no ordenador do xestor de quendas, indicando o tipo de dispositivo (dispositivo). O propio televisor cambiará á interface desexada da súa pizzería e comezará a mostrar os nomes dos clientes cuxos pedidos están listos alí.
De onde son as cargas?
Cada usuario iniciado no back office vai á base de datos, á táboa de usuarios de cada solicitude, saca ao usuario mediante unha consulta sql e comproba se ten o acceso e os dereitos necesarios para esta páxina.
Cada un dos dispositivos fai o mesmo só coa táboa de dispositivos, comprobando a súa función e o seu acceso. Un gran número de solicitudes á base de datos mestra leva á súa carga e ao desperdicio de recursos da base de datos común para estas operacións.
Descargando Auth
Auth ten un dominio illado, é dicir, os datos sobre usuarios, inicios de sesión ou dispositivos entran no servizo (polo momento) e permanecen alí. Se alguén os necesita, acudirá a este servizo para buscar datos.
FOI. O esquema de traballo orixinal era o seguinte:
Gustaríame explicar un pouco como funcionou:
- Unha solicitude do exterior chega ao backend (hai Asp.Net MVC), trae consigo unha cookie de sesión, que se usa para obter datos de sesión de Redis(1). Contén información sobre accesos e, a continuación, o acceso ao controlador está aberto (3,4) ou non.
- Se non hai acceso, cómpre pasar polo procedemento de autorización. Aquí, para simplificar, móstrase como parte do camiño no mesmo atributo, aínda que é unha transición á páxina de inicio de sesión. No caso dun escenario positivo, obteremos unha sesión correctamente completada e iremos ao controlador de Backoffice.
- Se hai datos, cómpre comprobalos a súa relevancia na base de usuarios. O seu papel cambiou, non debería estar permitido na páxina agora? Neste caso, despois de recibir a sesión (1), cómpre ir directamente á base de datos e comprobar o acceso do usuario mediante a capa lóxica de autenticación (2). A continuación, vai á páxina de inicio de sesión ou vai ao controlador. Un sistema tan sinxelo, pero non moi estándar.
- Se todos os procedementos son aprobados, entón saltamos máis a lóxica en controladores e métodos.
Os datos do usuario están separados de todos os demais datos, almacénanse nunha táboa de pertenza separada, as funcións da capa lóxica AuthService poden converterse en métodos de API. Os límites do dominio están definidos con bastante claridade: usuarios, os seus roles, datos de acceso, concesión e revogación de acceso. Todo parece que se pode sacar nun servizo separado.
CONVERTE. Así que fixeron:
Este enfoque ten unha serie de problemas. Por exemplo, chamar a un método dentro dun proceso non é o mesmo que chamar a un servizo externo a través de http. A latencia, a fiabilidade, o mantemento e a transparencia da operación son completamente diferentes. Andrey Morevskiy falou con máis detalle sobre estes problemas no seu informe. .
O servizo de autenticación e, con el, o servizo de dispositivos utilízanse para o back office, é dicir, para servizos e interfaces empregados na produción. A autenticación dos servizos de cliente (como un sitio web ou unha aplicación móbil) realízase por separado sen utilizar Auth. A separación levou aproximadamente un ano, e agora volvemos a tratar este tema, trasladando o sistema a novos servizos de autenticación (con protocolos estándar).
Por que levou tanto tempo a separación?
Houbo moitos problemas no camiño que nos frearon:
- Queriamos mover os datos de usuarios, dispositivos e autenticación das bases de datos específicas do país nun só. Para iso, tivemos que traducir todas as táboas e o uso do identificador int ao identificador global UUId (reelaborado recentemente este código e proxecto de código aberto ). O almacenamento dos datos dos usuarios (xa que é información persoal) ten as súas limitacións e para algúns países é necesario almacenalos por separado. Pero o identificador global do usuario debe ser.
- Moitas táboas da base de datos teñen información de auditoría sobre o usuario que realizou a operación. Isto requiriu un mecanismo adicional para a coherencia.
- Despois da creación dos servizos api, houbo un longo e gradual período de transición a outro sistema. O cambio tiña que ser fluido para os usuarios e requiría un traballo manual.
Esquema de rexistro do dispositivo nunha pizzería:
Arquitectura xeral despois da extracción do servizo Auth and Devices:
Nota. Para 2020, estamos a traballar nunha nova versión de Auth, que se basea no estándar de autorización OAuth 2.0. Este estándar é bastante complexo, pero é útil para desenvolver un servizo de autenticación de paso. No artigo "» Nós Alexey Chernyaev tentamos falar sobre o estándar da forma máis sinxela e clara posible para que aforrades tempo en estudalo.
Que fai o Tracker?
Agora sobre o segundo dos servizos cargados. O rastreador realiza unha dobre función:
- Por unha banda, o seu cometido é mostrar aos empregados da cociña cales son os pedidos que se están a traballar actualmente, que produtos hai que cociñar agora.
- Por outra banda, dixitalizar todos os procesos na cociña.
Cando aparece un produto novo nun pedido (por exemplo, pizza), vai á estación de seguimento de lanzamento. Nesta estación, hai un fabricante de pizzas que toma un bollo do tamaño necesario e lánzao, despois sinala na tableta de seguimento que completou a súa tarefa e transfire a base de masa enrolada á seguinte estación: "Iniciación". .
Alí, o seguinte fabricante de pizza enche a pizza, despois anota na tableta que completou a súa tarefa e mete a pizza no forno (esta tamén é unha estación separada que debe anotarse na tableta). Tal sistema estivo desde o principio en Dodo e desde o comezo da existencia de Dodo IS. Permítelle rastrexar e dixitalizar completamente todas as transaccións. Ademais, o rastreador suxire como cociñar un determinado produto, guía cada tipo de produto segundo os seus esquemas de fabricación, almacena o tempo de cocción óptimo para o produto e fai un seguimento de todas as operacións do produto.
Así se ve a pantalla da tableta na estación do rastreador "Raskatka"
De onde son as cargas?
Cada unha das pizzerías ten unhas cinco tabletas cun rastreador. En 2016, tiñamos máis de 100 pizzerías (e agora máis de 600). Cada unha das tabletas realiza unha solicitude ao backend unha vez cada 10 segundos e elimina os datos da táboa de pedidos (conexión co cliente e enderezo), a composición do pedido (conexión co produto e indicación da cantidade), a táboa de contabilidade de motivación (o o tempo de prensado está rexistrado nel). Cando un fabricante de pizza fai clic nun produto no rastreador, as entradas de todas estas táboas actualízanse. A táboa de pedidos é xeral, tamén contén insercións ao aceptar un pedido, actualizacións doutras partes do sistema e numerosas lecturas, por exemplo, nun televisor que colga nunha pizzería e mostra os pedidos rematados aos clientes.
Durante o período de loita coas cargas, cando todo e todo foi almacenado en caché e transferido á réplica asíncrona da base, estas operacións co rastreador continuaron indo á base mestra. Non debería haber ningún retraso, os datos deberían estar actualizados, a dessincronización é inaceptable.
Ademais, a falta de táboas e índices propios sobre elas non permitiu escribir consultas máis específicas adaptadas ao seu uso. Por exemplo, pode ser eficaz para un rastreador ter un índice dunha pizzería nunha táboa de pedidos. Sempre eliminamos os pedidos de pizzerías da base de datos do rastreador. Ao mesmo tempo, para recibir un pedido, non é tan importante en que pizzería cae, é máis importante que cliente fixo este pedido. E significa que é necesario o índice do cliente. Tampouco é necesario que o rastreador almacene o ID do recibo impreso ou das promocións de bonificación asociadas ao pedido na táboa de pedidos. Esta información non é de interese para o noso servizo de seguimento. Nunha base de datos monolítica común, as táboas só poderían ser un compromiso entre todos os usuarios. Este foi un dos problemas orixinais.
FOI. A arquitectura orixinal foi:
Mesmo despois de ser separados en procesos separados, a maior parte do código base seguía sendo común para diferentes servizos. Todo abaixo dos controladores era único e vivía no mesmo repositorio. Usamos métodos comúns de servizos, repositorios, unha base común, na que se atopan táboas comúns.
Rastreador de descarga
O principal problema co rastreador é que os datos deben estar sincronizados entre diferentes bases de datos. Esta é tamén a súa principal diferenza coa separación do servizo Auth, a orde e o seu estado poden cambiar e deben mostrarse en diferentes servizos.
Aceptamos un pedido na caixa do restaurante (este é un servizo), gárdase na base de datos no estado "Aceptado". Despois diso, debería chegar ao rastreador, onde cambiará o seu estado varias veces máis: de "Cociña" a "Embalado". Ao mesmo tempo, algunhas influencias externas do caixeiro ou da interface do xestor de quendas poden ocorrer coa orde. Darei os estados dos pedidos coa súa descrición na táboa:
O esquema para cambiar o estado da orde é o seguinte:
Os estados cambian entre os distintos sistemas. E aquí o rastreador non é un sistema final no que se pechen os datos. Vimos varios enfoques posibles para particionar neste caso:
- Concentramos todas as accións de pedido nun só servizo. No noso caso, esta opción require demasiado servizo para traballar co pedido. Se nos paramos nel, conseguiriamos o segundo monolito. Non resolveriamos o problema.
- Un sistema fai unha chamada a outro. A segunda opción xa é máis interesante. Pero con el, as cadeas de chamadas son posibles (), a conectividade dos compoñentes é maior, é máis difícil de xestionar.
- Organizamos eventos, e cada servizo comunícase con outro a través destes eventos. Como resultado, foi a terceira opción que se elixiu, segundo a cal todos os servizos comezan a intercambiar eventos entre si.
O feito de escoller a terceira opción supuxo que o rastreador tivese a súa propia base de datos, e por cada cambio na orde, enviaría un evento ao respecto, ao que se subscriban outros servizos e que tamén entra na base de datos mestra. Para iso necesitábamos algún servizo que garantise a entrega de mensaxes entre servizos.
Nese momento, xa tiñamos RabbitMQ na pila, de aí a decisión final de usalo como intermediario de mensaxes. O diagrama mostra a transición dun pedido desde o caixeiro do restaurante ata o rastreador, onde cambia o seu estado e a súa visualización na interface de pedidos do xestor. CONVERTE:
Orde de ruta paso a paso
A ruta do pedido comeza nun dos servizos de orixe do pedido. Aquí está o caixeiro do restaurante:
- Na compra, o pedido está completamente listo e é hora de envialo ao rastreador. Xógase o evento ao que está subscrito o rastreador.
- O rastreador, aceptando un pedido por si mesmo, gárdao na súa propia base de datos, facendo o evento "Pedido aceptado polo rastreador" e enviándoo a RMQ.
- Xa hai varios controladores subscritos ao bus de eventos por pedido. Para nós é importante o que fai a sincronización cunha base monolítica.
- O controlador recibe un evento, selecciona a partir del os datos que son significativos para el: no noso caso, este é o estado da orde "Aceptado polo rastreador" e actualiza a súa entidade de pedido na base de datos principal.
Se alguén precisa un pedido das mesas monolíticas, tamén pode lelo desde alí. Por exemplo, a interface Pedidos do Xestor de quendas precisa isto:
Todos os demais servizos tamén poden subscribirse para solicitar eventos do rastreador para usalos por si mesmos.
Se despois dun tempo a orde ponse en funcionamento, entón o seu estado cambia primeiro na súa base de datos (base de datos Tracker) e despois xérase inmediatamente o evento "OrderIn Progress". Tamén entra en RMQ, desde onde se sincroniza nunha base de datos monolítica e se entrega a outros servizos. Pode haber varios problemas ao longo do camiño, pódense atopar máis detalles sobre eles no informe de Zhenya Peshkov .
Arquitectura final despois de cambios en Auth e Tracker
Resumindo o resultado intermedio: Inicialmente, tiven a idea de agrupar a historia de nove anos do sistema Dodo IS nun artigo. Quería falar rápida e sinxelamente das etapas da evolución. Sen embargo, sentándome para o material, decateime de que todo é moito máis complicado e interesante do que parece.
Reflexionando sobre os beneficios (ou a falta dos mesmos) deste material, cheguei á conclusión de que o desenvolvemento continuo é imposible sen anais completos dos acontecementos, retrospectivas detalladas e análise das miñas decisións pasadas.
Espero que vos fose útil e interesante coñecer o noso camiño. Agora estou ante a elección de que parte do sistema Dodo IS describir no seguinte artigo: escribir nos comentarios ou votar.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Que parte de Dodo IS che gustaría saber no seguinte artigo?
-
24,1%Monolito temperán en Dodo IS (2011-2015)14
-
24,1%Primeiros problemas e as súas solucións (2015-2016)14
-
20,7%O camiño do cliente: fachada sobre base (2016-2017)12
-
36,2%A historia dos microservizos reais (2018-2019)21
-
44,8%Serrado completo do monolito e estabilización da arquitectura26
-
29,3%Sobre outros plans para o desenvolvemento do sistema17
-
19,0%Non quero saber nada de Dodo IS11
Votaron 58 usuarios. 6 usuarios abstivéronse.
Fonte: www.habr.com