2019 оноос хойш Орос улсад заавал шошгоны тухай хууль хэрэгжиж эхэлсэн. Хууль нь бүх бүлгийн барааны хувьд хамаарахгүй бөгөөд бүтээгдэхүүний бүлгүүдэд заавал шошголох хугацаа нь өөр өөр байдаг. Тамхи, гутал, эм зэрэг нь заавал шошготой байх ёстой бөгөөд дараа нь үнэртэй ус, нэхмэл эдлэл, сүү зэрэг бусад бүтээгдэхүүнийг нэмж оруулах болно. Энэхүү хууль тогтоомжийн шинэчлэл нь мэдээллийн технологийн шинэ шийдлүүдийг боловсруулахад түлхэц болсон бөгөөд энэ нь бүтээгдэхүүний үйлдвэрлэлээс эцсийн хэрэглэгчийн худалдан авах хүртэлх бүх амьдралын гинжин хэлхээг, тухайн үйл явцад оролцогч бүх оролцогчид: төр өөрөө болон бараа бүтээгдэхүүн борлуулдаг бүх байгууллагуудын аль алинд нь хянах боломжийг олгоно. заавал тэмдэглэгээ хийх.
X5-д шошготой барааг хянах, улс болон ханган нийлүүлэгчидтэй мэдээлэл солилцох системийг "Маркус" гэж нэрлэдэг. Үүнийг хэн, хэрхэн бүтээсэн, ямар технологийн дэвтэр, яагаад бахархах зүйл байгааг дарааллаар нь хэлье.
Жинхэнэ өндөр ачаалал
"Маркус" нь олон асуудлыг шийддэг бөгөөд гол нь X5 мэдээллийн систем ба шошготой бүтээгдэхүүний хөдөлгөөнийг хянах улсын мэдээллийн систем (GIS MP) хоорондын харилцан үйлчлэл юм. Энэхүү платформ нь бидний хүлээн авсан бүх шошгоны кодууд болон эдгээр кодуудын объектуудаар дамжсан бүх түүхийг хадгалдаг бөгөөд шошготой бүтээгдэхүүний дахин зэрэглэлийг арилгахад тусалдаг. Шошготой барааны эхний бүлэгт багтсан тамхины бүтээгдэхүүний жишээг авч үзвэл, нэг ачааны машинд 600 хайрцаг тамхи агуулагддаг бөгөөд тус бүр нь өөр өөрийн гэсэн кодтой байдаг. Манай системийн үүрэг бол агуулах, дэлгүүрийн хооронд ийм сав баглаа боодол бүрийн хөдөлгөөний хууль ёсны байдлыг хянах, шалгах, эцэст нь эцсийн худалдан авагчид худалдах боломжтой эсэхийг шалгах явдал юм. Мөн бид цагт 000 бэлэн мөнгөний гүйлгээг бүртгэдэг бөгөөд ийм багц бүр дэлгүүрт хэрхэн орж ирснийг тэмдэглэх хэрэгтэй. Тиймээс, объектуудын хоорондох бүх хөдөлгөөнийг харгалзан үзэхэд бид жилд хэдэн арван тэрбум бичлэгийг хүлээж байна.
М баг
Маркусыг X5-ийн хүрээнд төсөл гэж үздэг ч бүтээгдэхүүний хандлагыг ашиглан хэрэгжүүлж байна. Баг нь Scrum-ийн дагуу ажилладаг. Төсөл өнгөрсөн зун эхэлсэн боловч эхний үр дүн нь зөвхөн 16-р сард гарсан - манай багийнхан бүрэн цугларч, системийн архитектурыг боловсруулж, тоног төхөөрөмж худалдаж авсан. Одоо тус баг XNUMX хүнтэй бөгөөд зургаа нь backend, frontend боловсруулах, гурав нь системийн шинжилгээнд хамрагдаж байна. Зургаан хүн гар ажиллагаа, ачаалал, автомат туршилт, бүтээгдэхүүний засвар үйлчилгээнд хамрагдаж байна. Үүнээс гадна манайд SRE мэргэжилтэн бий.
Манай багт зөвхөн хөгжүүлэгчид код бичдэггүй, бараг бүх залуус автомат тестийг хэрхэн програмчлах, бичих, скрипт ачаалах, автоматжуулалтын скрипт хийхийг мэддэг. Бүтээгдэхүүний дэмжлэг хүртэл өндөр түвшний автоматжуулалт шаарддаг тул бид үүнд онцгой анхаарал хандуулдаг. Бид өмнө нь программчлаагүй хамт олондоо зөвлөгөө өгч, туслахыг үргэлж хичээдэг бөгөөд тэдэнд ажиллах жижиг даалгавар өгдөг.
Коронавирусын тахлын улмаас бид бүхэл бүтэн багийг алсын зайн ажилд шилжүүлсэн; хөгжүүлэлтийн менежментийн бүх хэрэгслийн бэлэн байдал, Jira болон GitLab-д баригдсан ажлын урсгал нь энэ үе шатыг хялбархан давах боломжийг олгосон. Үүний үр дүнд багийн бүтээмж муудаагүйг алсаас өнгөрүүлсэн сарууд харуулсан; олон хүмүүсийн хувьд ажлын тав тух нэмэгдэж, цорын ганц зүйл бол амьд харилцаа холбоо байсан.
Алсын багийн хурал
Алсын ажлын үеэр уулзалт хийх
Шийдлийн технологийн стек
X5-д зориулсан стандарт репозитор болон CI/CD хэрэгсэл нь GitLab юм. Бид үүнийг код хадгалах, тасралтгүй туршилт хийх, серверүүдийг турших, үйлдвэрлэхэд ашиглахад ашигладаг. Хөгжүүлэгчийн кодонд оруулсан өөрчлөлтийг дор хаяж 2 хамт олон зөвшөөрөх шаардлагатай үед бид кодыг хянах дадлыг ашигладаг. Статик кодын анализатор SonarQube болон JaCoCo нь кодыг цэвэр байлгахад тусалдаг ба нэгжийн тестийн хамрах хүрээг шаардлагатай түвшинд байлгахад тусалдаг. Кодын бүх өөрчлөлт нь эдгээр шалгалтыг давах ёстой. Гараар ажиллуулдаг бүх туршилтын скриптүүд дараа нь автоматжуулсан болно.
Маркус бизнесийн үйл явцыг амжилттай хэрэгжүүлэхийн тулд бид технологийн хэд хэдэн асуудлыг дарааллаар нь шийдвэрлэх шаардлагатай болсон.
Даалгавар 1. Системийн хэвтээ өргөтгөлийн хэрэгцээ
Энэ асуудлыг шийдэхийн тулд бид архитектурт микро үйлчилгээний аргыг сонгосон. Үүний зэрэгцээ үйлчилгээний хариуцлагын чиглэлийг ойлгох нь маш чухал байсан. Бид үйл явцын онцлогийг харгалзан тэдгээрийг бизнесийн үйл ажиллагаанд хуваахыг хичээсэн. Жишээлбэл, агуулахад хүлээн авах нь тийм ч элбэг биш, гэхдээ маш том хэмжээний үйл ажиллагаа бөгөөд энэ үеэр улсын зохицуулагчаас хүлээн авч буй барааны нэгжийн талаарх мэдээллийг хурдан авах шаардлагатай бөгөөд нэг хүргэлтийн тоо 600000 хүрдэг. , энэ бүтээгдэхүүнийг агуулахад хүлээн авах боломжтой эсэхийг шалгаж, агуулахын автоматжуулалтын системд шаардлагатай бүх мэдээллийг буцааж өгнө үү. Гэхдээ агуулахаас тээвэрлэх нь илүү эрчимтэй боловч бага хэмжээний өгөгдөлтэй ажилладаг.
Бид бүх үйлчилгээг харьяалалгүй байдлаар хэрэгжүүлж, дотоод үйл ажиллагаагаа үе шат болгон хуваахыг хичээж, Кафкагийн өөрөө сэдэв гэж нэрлэдэг зүйлээ ашиглана. Энэ нь бичил үйлчилгээ өөр рүүгээ мессеж илгээдэг бөгөөд энэ нь танд илүү их нөөц шаардсан үйл ажиллагааны ачааллыг тэнцвэржүүлж, бүтээгдэхүүний засвар үйлчилгээг хялбаршуулах боломжийг олгодог боловч дараа нь илүү ихийг хэлнэ.
Бид гадаад системтэй харилцах модулиудыг тусдаа үйлчилгээ болгон хуваахаар шийдсэн. Энэ нь бизнесийн үйл ажиллагаа бүхий үйлчилгээнд бараг ямар ч нөлөө үзүүлэхгүйгээр гадаад системийн API-г байнга өөрчлөх асуудлыг шийдвэрлэх боломжтой болсон.
Бүх микро үйлчилгээг OpenShift кластерт байрлуулсан бөгөөд энэ нь микро үйлчилгээ тус бүрийн масштабыг нэмэгдүүлэх асуудлыг шийдэж, гуравдагч талын Үйлчилгээний нээлтийн хэрэгслийг ашиглахгүй байх боломжийг бидэнд олгодог.
Даалгавар 2. Платформын үйлчилгээнүүдийн хооронд өндөр ачаалал, маш эрчимтэй мэдээлэл солилцох хэрэгцээ: Зөвхөн төслийг эхлүүлэх үе шатанд секундэд 600 орчим үйлдэл хийдэг. Жижиглэн худалдааны цэгүүд манай платформтой холбогдож байгаа тул энэ үнэ цэнэ 5000 опс/сек хүртэл өснө гэж бид найдаж байна.
Энэ асуудлыг Кафка кластер байрлуулж, платформын микро үйлчилгээний хооронд синхрон харилцан үйлчлэлээс бараг бүрэн татгалзсанаар шийдсэн. Бүх үйлдлүүд асинхрон байж болохгүй тул энэ нь системийн шаардлагын талаар маш нарийн дүн шинжилгээ хийхийг шаарддаг. Үүний зэрэгцээ бид зөвхөн брокероор дамжуулан үйл явдлуудыг дамжуулаад зогсохгүй мессеж дэх шаардлагатай бүх бизнесийн мэдээллийг дамжуулдаг. Тиймээс мессежийн хэмжээ хэдэн зуун килобайт хүрч болно. Кафка дахь мессежийн хэмжээ хязгаар нь мессежийн хэмжээг нарийн урьдчилан таамаглахыг шаарддаг бөгөөд хэрэв шаардлагатай бол бид тэдгээрийг хуваах боловч бизнесийн үйл ажиллагаатай холбоотой хуваагдал нь логик юм.
Жишээлбэл, бид машинд ирсэн барааг хайрцагт хуваадаг. Синхрон үйлдлүүдийн хувьд тусдаа микро үйлчилгээг хуваарилж, ачааллын нарийвчилсан туршилтыг хийдэг. Кафкаг ашиглах нь бидэнд өөр нэг сорилттой тулгарсан - Кафка интеграцчлалыг харгалзан үйлчилгээнийхээ ажиллагааг шалгах нь бидний бүх нэгжийн тестүүдийг асинхрон болгодог. Бид Embedded Kafka Broker ашиглан өөрийн хэрэглээний аргуудыг бичиж энэ асуудлыг шийдсэн. Энэ нь бие даасан аргуудын хувьд нэгж тест бичих хэрэгцээг арилгадаггүй ч бид Кафка ашиглан нарийн төвөгтэй тохиолдлуудыг туршиж үзэхийг илүүд үздэг.
Үйлчилгээний үйл ажиллагааны явцад эсвэл Кафка багцтай ажиллах үед үл хамаарах зүйл тохиолдоход TraceId нь алдагдахгүй байхын тулд бүртгэлийг хянахад ихээхэн анхаарал хандуулсан. Хэрэв эхнийх нь ямар нэгэн онцгой асуудал гараагүй бол хоёр дахь тохиолдолд бид багцад ирсэн бүх TraceId-г бүртгэж, үргэлжлүүлэн мөрдөхийн тулд нэгийг нь сонгох шаардлагатай болно. Дараа нь анхны TraceId-ээр хайлт хийх үед хэрэглэгч ямар мөрийг үргэлжлүүлж байгааг хялбархан олж мэдэх болно.
Даалгавар 3. Их хэмжээний өгөгдөл хадгалах хэрэгцээ: Зөвхөн тамхины хувьд жилд 1 тэрбум гаруй шошго X5 дээр ирдэг. Тэд байнгын, хурдан нэвтрэхийг шаарддаг. Нийтдээ эдгээр шошготой барааны хөдөлгөөний түүхийн 10 тэрбум орчим бүртгэлийг систем боловсруулах ёстой.
Гурав дахь асуудлыг шийдэхийн тулд MongoDB NoSQL мэдээллийн санг сонгосон. Бид 5 зангилааны хэлтэрхий бүтээсэн бөгөөд зангилаа бүр нь 3 серверийн Replica Set-тэй. Энэ нь системийг хэвтээ байдлаар томруулж, кластерт шинэ сервер нэмж, алдааг тэсвэрлэх боломжийг олгоно. Энд бид өөр нэг асуудалтай тулгарсан - хэвтээ байдлаар өргөтгөх боломжтой микро үйлчилгээг ашиглахыг харгалзан mongo кластер дахь гүйлгээг хангах. Жишээлбэл, манай системийн нэг үүрэг бол ижил шошгоны код бүхий бүтээгдэхүүнийг дахин борлуулах оролдлогыг илрүүлэх явдал юм. Энд алдаатай сканнердсан эсвэл кассын алдаатай үйлдлээс бүрдсэн давхаргууд гарч ирдэг. Ийм давхардал нь Кафкагийн нэг багц болон зэрэгцээ боловсруулагдаж байгаа хоёр багц дотор хоёуланд нь тохиолдож болохыг бид олж мэдсэн. Тиймээс мэдээллийн сангаас асууж давхардсан эсэхийг шалгах нь юу ч өгсөнгүй. Бичил үйлчилгээ бүрийн хувьд бид энэ үйлчилгээний бизнесийн логик дээр үндэслэн асуудлыг тусад нь шийдсэн. Жишээлбэл, чекийн хувьд бид багц дотор чек нэмсэн бөгөөд оруулах үед давхардсан харагдах байдлыг тусад нь боловсруулдаг.
Хэрэглэгчдийн үйл ажиллагааны түүхтэй ажиллах нь хамгийн чухал зүйл болох бидний бизнесийн үйл явцын үйл ажиллагаанд ямар нэгэн байдлаар нөлөөлөхгүй байхын тулд бид бүх түүхэн өгөгдлийг тусдаа мэдээллийн сан бүхий тусдаа үйлчилгээ болгон тусгаарласан бөгөөд энэ нь Кафкагаар дамжуулан мэдээлэл хүлээн авдаг. . Ингэснээр хэрэглэгчид үргэлжилж буй үйл ажиллагааны өгөгдөл боловсруулдаг үйлчилгээнд нөлөөлөхгүйгээр тусгаарлагдсан үйлчилгээтэй ажилладаг.
Даалгавар 4: Дарааллыг дахин боловсруулах, хянах:
Түгээмэл системд мэдээллийн сан, дараалал, гадаад мэдээллийн эх үүсвэртэй холбоотой асуудал, алдаа зайлшгүй гардаг. Маркусын хувьд ийм алдааны эх үүсвэр нь гадаад системтэй нэгдэх явдал юм. Тодорхой хугацааны завсарлагатай алдаатай хариу өгөх хүсэлтийг давтан гаргах боломжийг олгодог шийдлийг олох шаардлагатай байсан, гэхдээ тэр үед үндсэн дараалалд амжилттай хүсэлтийг боловсруулахаа зогсоож болохгүй. Үүний тулд "сэдэв дээр суурилсан дахин оролдлого" гэж нэрлэгддэг үзэл баримтлалыг сонгосон. Үндсэн сэдэв бүрийн хувьд алдаатай мессеж илгээсэн нэг буюу хэд хэдэн дахин оролдох сэдвийг бий болгож, үндсэн сэдвийн мессежийг боловсруулах саатал арилдаг. Харилцааны схем -
Ийм схемийг хэрэгжүүлэхийн тулд бидэнд дараахь зүйл хэрэгтэй байсан: энэ шийдлийг Spring-тай нэгтгэж, кодын давхардлаас зайлсхийх хэрэгтэй. Бид вэбээр аялж байхдаа Spring BeanPostProccessor дээр суурилсан ижил төстэй шийдлийг олж мэдсэн боловч энэ нь бидэнд шаардлагагүй мэт санагдсан. Манай баг хэрэглэгчдийг бий болгох Хаврын мөчлөгт нэгтгэх, дахин оролдох хэрэглэгчдийг нэмэх боломжийг олгодог илүү хялбар шийдлийг гаргасан. Бид өөрсдийн шийдлийн загварыг Хаврын багт санал болгосон, та үүнийг харж болно . Дахин оролдох хэрэглэгчдийн тоо болон хэрэглэгч бүрийн оролдлогын тоог бизнесийн үйл явцын хэрэгцээ шаардлагаас хамааран параметрүүдээр тохируулдаг бөгөөд бүх зүйл ажиллахын тулд org.springframework.kafka.annotation.KafkaListener тайлбарыг нэмэхэд л үлддэг. , энэ нь бүх Spring хөгжүүлэгчдэд танил юм.
Хэрэв бүх дахин оролдлого хийсний дараа мессежийг боловсруулах боломжгүй бол Spring DeadLetterPublishingRecoverer ашиглан DLT (үхсэн үсгийн сэдэв) руу очно. Дэмжлэгийн хүсэлтээр бид энэ функцийг өргөжүүлж, DLT, stackTrace, traceId болон тэдгээрийн талаарх бусад хэрэгтэй мэдээллийг үзэх боломжийг танд олгодог тусдаа үйлчилгээг бий болгосон. Нэмж дурдахад DLT-ийн бүх сэдвүүдэд хяналт, сэрэмжлүүлэг нэмэгдсэн бөгөөд одоо үнэндээ DLT сэдвээр мессеж гарч ирэх нь согогийг задлан шинжилж, засах шалтгаан болж байна. Энэ нь маш тохиромжтой - сэдвийн нэрээр бид асуудал ямар үе шатанд үүссэнийг шууд ойлгодог бөгөөд энэ нь түүний үндсэн шалтгааныг хайх ажлыг ихээхэн хурдасгадаг.
Хамгийн сүүлд бид мессежийн шалтгааныг арилгах (жишээ нь, гадаад системийн ажиллагааг сэргээх) болон мэдээжийн хэрэг дүн шинжилгээ хийхэд тохирох согогийг тогтоосны дараа бидний дэмжлэгийг ашиглан мессежийг дахин илгээх боломжийг олгодог интерфейсийг хэрэгжүүлсэн. Эндээс бидний бие даасан сэдвүүд хэрэг болно: урт боловсруулалтын гинжийг дахин эхлүүлэхгүйн тулд та хүссэн алхамаас дахин эхлүүлж болно.
Платформын ажиллагаа
Энэхүү платформ нь аль хэдийн бүтээмжтэй ажиллаж байгаа бөгөөд бид өдөр бүр хүргэлт, тээвэрлэлт хийж, шинэ түгээлтийн төв, дэлгүүрүүдийг холбодог. Туршилтын хүрээнд уг систем нь “Тамхи”, “Гутал” бүтээгдэхүүний бүлгүүдтэй хамтран ажилладаг.
Манай баг бүхэлдээ туршилт явуулахад оролцож, гарч ирж буй асуудлуудад дүн шинжилгээ хийж, бүртгэлийг сайжруулахаас эхлээд процессыг өөрчлөх хүртэл бүтээгдэхүүнээ сайжруулах саналуудыг гаргадаг.
Бидний алдааг давтахгүйн тулд туршилтын явцад илэрсэн бүх тохиолдлыг автоматжуулсан туршилтанд тусгасан болно. Олон тооны автотест, нэгж тестүүд байгаа нь регрессийн тест хийж, засварыг хэдхэн цагийн дотор шууд утгаар нь суулгах боломжийг олгодог.
Одоо бид мөрийн хөтөлбөрөө үргэлжлүүлэн хөгжүүлж, сайжруулж, шинэ сорилтуудтай байнга тулгарч байна. Хэрэв та сонирхож байгаа бол бид дараах нийтлэлүүдэд өөрсдийн шийдлүүдийн талаар ярих болно.
Эх сурвалж: www.habr.com