Des del 2019, Rússia té una llei sobre l'etiquetatge obligatori. La llei no s'aplica a tots els grups de béns, i les dates d'entrada en vigor de l'etiquetatge obligatori per a grups de productes són diferents. El tabac, les sabates i els medicaments seran els primers subjectes a l'etiquetatge obligatori; més endavant s'hi afegiran altres productes, com ara perfums, tèxtils i llet. Aquesta innovació legislativa va impulsar el desenvolupament de noves solucions informàtiques que permetran fer el seguiment de tota la cadena de vida d'un producte, des de la producció fins a la compra per part del consumidor final, fins a tots els participants en el procés: tant el propi estat com totes les organitzacions que venen béns amb etiquetatge obligatori.
A X5, el sistema que farà un seguiment dels productes etiquetats i intercanviarà dades amb l'estat i els proveïdors s'anomena "Marcus". Us expliquem per ordre com i qui el va desenvolupar, quina és la seva pila de tecnologia i per què tenim alguna cosa de què estar orgullosos.
Alta càrrega real
"Marcus" resol molts problemes, el principal és la interacció d'integració entre els sistemes d'informació X5 i el sistema d'informació estatal per a productes etiquetats (GIS MP) per fer un seguiment del moviment dels productes etiquetats. La plataforma també emmagatzema tots els codis d'etiquetatge que rebem i tot l'historial del moviment d'aquests codis entre objectes, i ajuda a eliminar la requalificació dels productes etiquetats. Utilitzant l'exemple dels productes del tabac, que es van incloure en els primers grups de productes etiquetats, només un camió carregat de cigarrets conté uns 600 paquets, cadascun dels quals té el seu propi codi únic. I la tasca del nostre sistema és fer el seguiment i verificar la legalitat dels moviments de cadascun d'aquests paquets entre magatzems i botigues i, en definitiva, verificar l'admissibilitat de la seva venda al comprador final. I registrem unes 000 transaccions en efectiu per hora, i també hem de registrar com cada paquet d'aquest tipus va entrar a la botiga. Així, tenint en compte tots els moviments entre objectes, esperem desenes de milers de milions de registres a l'any.
Equip M
Malgrat que Marcus es considera un projecte dins de X5, s'està implementant mitjançant un enfocament de producte. L'equip treballa segons Scrum. El projecte va començar l'estiu passat, però els primers resultats van arribar només a l'octubre: el nostre propi equip estava completament muntat, es va desenvolupar l'arquitectura del sistema i es va comprar l'equip. Ara l'equip compta amb 16 persones, sis de les quals estan involucrades en el desenvolupament de backend i frontend, tres de les quals estan involucrades en l'anàlisi del sistema. Sis persones més participen en proves manuals, de càrrega, automàtiques i manteniment del producte. A més, comptem amb un especialista en SRE.
No només els desenvolupadors escriuen codi al nostre equip; gairebé tots els nois saben com programar i escriure autotests, carregar scripts i scripts d'automatització. Prestem especial atenció a això, ja que fins i tot el suport del producte requereix un alt nivell d'automatització. Sempre intentem assessorar i ajudar els companys que no s'han programat abans, i donar-los petites tasques per treballar.
A causa de la pandèmia de coronavirus, vam traslladar tot l'equip al treball remot; la disponibilitat de totes les eines per a la gestió del desenvolupament, el flux de treball construït a Jira i GitLab va permetre passar fàcilment aquesta etapa. Els mesos passats a distància van demostrar que la productivitat de l'equip no es va patir com a conseqüència; per a molts, la comoditat a la feina va augmentar, l'únic que faltava era la comunicació en directe.
Reunió d'equip a distància
Reunions durant el treball a distància
Pila de tecnologia de la solució
El repositori estàndard i l'eina CI/CD per a X5 és GitLab. L'utilitzem per a l'emmagatzematge de codi, proves contínues i desplegament a servidors de prova i producció. També fem servir la pràctica de la revisió del codi, quan almenys 2 col·legues necessiten aprovar els canvis fets pel desenvolupador al codi. Els analitzadors de codis estàtics SonarQube i JaCoCo ens ajuden a mantenir el nostre codi net i a garantir el nivell necessari de cobertura de proves unitàries. Tots els canvis al codi han de passar per aquestes comprovacions. Tots els scripts de prova que s'executen manualment s'automatitzen posteriorment.
Per a la implementació exitosa dels processos de negoci per part de "Marcus", vam haver de resoldre una sèrie de problemes tecnològics, cadascun en ordre.
Tasca 1. La necessitat d'escalabilitat horitzontal del sistema
Per resoldre aquest problema, vam triar un enfocament de microservei a l'arquitectura. Al mateix temps, era molt important entendre les àrees de responsabilitat dels serveis. Hem intentat dividir-los en operacions empresarials, tenint en compte les especificitats dels processos. Per exemple, l'acceptació en un magatzem no és una operació molt freqüent, però molt gran, durant la qual cal obtenir ràpidament informació del regulador estatal sobre les unitats de mercaderies que s'accepta, el nombre de les quals en un lliurament arriba a 600000. , comproveu l'admissibilitat d'acceptar aquest producte al magatzem i retorneu tota la informació necessària per al sistema d'automatització del magatzem. Però l'enviament des dels magatzems té una intensitat molt més gran, però al mateix temps opera amb volums reduïts de dades.
Implementem tots els serveis de manera sense estat i fins i tot intentem dividir les operacions internes en passos, utilitzant el que anomenem autotemes de Kafka. És quan un microservei s'envia un missatge a si mateix, la qual cosa us permet equilibrar la càrrega d'operacions més intensives en recursos i simplifica el manteniment del producte, però en parlarem més endavant.
Vam decidir separar els mòduls per a la interacció amb sistemes externs en serveis separats. Això va permetre resoldre el problema de canvis freqüents d'API de sistemes externs, pràcticament sense impacte en els serveis amb funcionalitat empresarial.
Tots els microserveis es despleguen en un clúster OpenShift, que resol tant el problema d'escalar cada microservei com ens permet no utilitzar eines de descoberta de serveis de tercers.
Tasca 2. La necessitat de mantenir una càrrega elevada i un intercanvi de dades molt intensiu entre els serveis de la plataforma: Només durant la fase de llançament del projecte, es realitzen unes 600 operacions per segon. Esperem que aquest valor augmenti fins a 5000 operacions/s a mesura que els punts de venda es connectin a la nostra plataforma.
Aquest problema es va resoldre mitjançant la implementació d'un clúster Kafka i l'abandó gairebé completament de la interacció sincrònica entre els microserveis de la plataforma. Això requereix una anàlisi molt acurada dels requisits del sistema, ja que no totes les operacions poden ser asíncrones. Al mateix temps, no només transmetem esdeveniments a través del corredor, sinó que també transmetem tota la informació comercial necessària al missatge. Així, la mida del missatge pot arribar a diversos centenars de kilobytes. El límit de mida del missatge a Kafka ens obliga a predir amb precisió la mida del missatge i, si cal, els dividim, però la divisió és lògica, relacionada amb les operacions empresarials.
Per exemple, dividim les mercaderies que arriben en un cotxe en caixes. Per a les operacions sincròniques, s'assignen microserveis separats i es duen a terme proves de càrrega exhaustives. L'ús de Kafka ens va presentar un altre repte: provar el funcionament del nostre servei tenint en compte la integració de Kafka fa que totes les nostres proves unitàries siguin asíncrones. Hem resolt aquest problema escrivint els nostres propis mètodes d'utilitat mitjançant Embedded Kafka Broker. Això no elimina la necessitat d'escriure proves unitàries per a mètodes individuals, però preferim provar casos complexos amb Kafka.
Es va prestar molta atenció al seguiment dels registres perquè el seu TraceId no es perdés quan es produeixin excepcions durant el funcionament dels serveis o quan es treballa amb Kafka batch. I si no hi ha hagut problemes especials amb el primer, en el segon cas, ens veiem obligats a registrar tots els TraceIds amb què va venir el lot i seleccionar-ne un per continuar el seguiment. Aleshores, quan cerqui amb el TraceId original, l'usuari esbrinarà fàcilment amb què ha continuat el traçat.
Tasca 3. La necessitat d'emmagatzemar una gran quantitat de dades: Més de 1 milions d'etiquetes a l'any només per al tabac arriben a X5. Requereixen un accés constant i ràpid. En total, el sistema ha de processar uns 10 milions de registres de l'historial de moviments d'aquestes mercaderies etiquetades.
Per resoldre el tercer problema, es va triar la base de dades NoSQL MongoDB. Hem construït un fragment de 5 nodes i cada node té un conjunt de rèplica de 3 servidors. Això us permet escalar el sistema horitzontalment, afegint nous servidors al clúster i garantir la seva tolerància a errors. Aquí ens hem trobat amb un altre problema: assegurar la transaccionalitat al clúster mongo, tenint en compte l'ús de microserveis escalables horitzontalment. Per exemple, una de les tasques del nostre sistema és identificar els intents de revendre productes amb els mateixos codis d'etiquetatge. Aquí, apareixen superposicions amb exploracions errònies o operacions errònies dels caixers. Hem trobat que aquests duplicats es poden produir tant dins d'un lot de Kafka que s'està processant com dins de dos lots que es processen en paral·lel. Per tant, comprovar si hi ha duplicats consultant la base de dades no va donar res. Per a cada microservei, vam resoldre el problema per separat en funció de la lògica empresarial d'aquest servei. Per exemple, per als xecs, hem afegit un xec dins del lot i un processament separat per a l'aparició de duplicats en inserir.
Per garantir que el treball dels usuaris amb l'historial d'operacions no afecti de cap manera el més important: el funcionament dels nostres processos empresarials, hem separat totes les dades històriques en un servei independent amb una base de dades separada, que també rep informació a través de Kafka. . D'aquesta manera, els usuaris treballen amb un servei aïllat sense afectar els serveis que tracten dades per a les operacions en curs.
Tasca 4: reprocessament i supervisió de la cua:
En els sistemes distribuïts, inevitablement sorgeixen problemes i errors en la disponibilitat de bases de dades, cues i fonts de dades externes. En el cas de Marcus, l'origen d'aquests errors és la integració amb sistemes externs. Calia trobar una solució que permetés sol·licituds repetides de respostes errònies amb algun temps d'espera especificat, però que al mateix temps no deixis de processar sol·licituds satisfactòries a la cua principal. Per a això, es va escollir el concepte denominat "reintent basat en temes". Per a cada tema principal, es creen un o més temes de reintent als quals s'envien missatges erronis i alhora s'elimina el retard en el processament dels missatges del tema principal. Esquema d'interacció -
Per implementar aquest esquema, necessitàvem el següent: integrar aquesta solució amb Spring i evitar la duplicació de codi. Mentre navegàvem per la web, ens vam trobar amb una solució similar basada en Spring BeanPostProccessor, però ens va semblar innecessàriament feixuc. El nostre equip ha creat una solució més senzilla que ens permet integrar-nos al cicle Spring per crear consumidors i afegir, a més, Retry Consumers. Vam oferir un prototip de la nostra solució a l'equip de Spring, el podeu veure . El nombre de Retry Consumers i el nombre d'intents per a cada consumidor es configuren mitjançant paràmetres, en funció de les necessitats del procés empresarial, i perquè tot funcioni, només queda afegir l'anotació org.springframework.kafka.annotation.KafkaListener , que és familiar per a tots els desenvolupadors de Spring.
Si el missatge no es pot processar després de tots els intents de reintentar, passa a DLT (tema de lletra morta) mitjançant Spring DeadLetterPublishingRecoverer. A petició de suport, hem ampliat aquesta funcionalitat i hem creat un servei independent que us permet veure els missatges inclosos a DLT, stackTrace, traceId i altra informació útil sobre ells. A més, a tots els temes DLT s'hi van afegir monitoratges i alertes, i ara, de fet, l'aparició d'un missatge en un tema DLT és un motiu per analitzar i solucionar un defecte. Això és molt convenient: pel nom del tema, entenem immediatament en quin pas del procés va sorgir el problema, la qual cosa accelera significativament la recerca de la seva causa arrel.
Darrerament hem implementat una interfície que ens permet tornar a enviar missatges utilitzant el nostre suport després d'eliminar-ne les causes (per exemple, restaurar la funcionalitat del sistema extern) i, per descomptat, establir el defecte corresponent per a l'anàlisi. Aquí és on els nostres temes personals són útils: per no reiniciar una cadena de processament llarga, podeu reiniciar-la des del pas desitjat.
Operació de la plataforma
La plataforma ja està en funcionament productiu, cada dia realitzem lliuraments i enviaments, connectem nous centres de distribució i botigues. Com a part del pilot, el sistema treballa amb els grups de productes "Tabac" i "Sabates".
Tot el nostre equip participa en la realització de proves pilot, analitza problemes emergents i fa suggeriments per millorar el nostre producte, des de millorar els registres fins a canviar els processos.
Per no repetir els nostres errors, tots els casos trobats durant el pilot es reflecteixen en proves automatitzades. La presència d'un gran nombre d'autotests i proves d'unitat us permet realitzar proves de regressió i instal·lar una correcció, literalment, en poques hores.
Ara continuem desenvolupant i millorant la nostra plataforma, i afrontem constantment nous reptes. Si esteu interessats, parlarem de les nostres solucions en els articles següents.
Font: www.habr.com