Sejak 2019, Rusia mempunyai undang-undang mengenai pelabelan mandatori. Undang-undang tidak terpakai untuk semua kumpulan barangan, dan tarikh mula berkuat kuasa pelabelan mandatori untuk kumpulan produk adalah berbeza. Tembakau, kasut dan ubat-ubatan akan menjadi yang pertama tertakluk kepada pelabelan wajib; produk lain akan ditambahkan kemudian, contohnya, minyak wangi, tekstil dan susu. Inovasi perundangan ini mendorong pembangunan penyelesaian IT baharu yang memungkinkan untuk menjejaki keseluruhan rantaian hayat produk daripada pengeluaran kepada pembelian oleh pengguna akhir, kepada semua peserta dalam proses: kedua-dua negeri itu sendiri dan semua organisasi yang menjual barangan dengan pelabelan wajib.
Dalam X5, sistem yang akan menjejaki barangan berlabel dan bertukar data dengan negeri dan pembekal dipanggil "Marcus". Mari beritahu anda mengikut urutan bagaimana dan siapa yang membangunkannya, apakah susunan teknologinya, dan mengapa kami mempunyai sesuatu yang boleh dibanggakan.
Beban Tinggi Sebenar
"Marcus" menyelesaikan banyak masalah, yang utama ialah interaksi integrasi antara sistem maklumat X5 dan sistem maklumat negeri untuk produk berlabel (MP GIS) untuk menjejaki pergerakan produk berlabel. Platform ini juga menyimpan semua kod pelabelan yang diterima oleh kami dan keseluruhan sejarah pergerakan kod ini merentas objek, dan membantu menghapuskan penggredan semula produk berlabel. Menggunakan contoh produk tembakau, yang termasuk dalam kumpulan pertama barangan berlabel, hanya satu lori rokok yang mengandungi kira-kira 600 pek, yang setiap satunya mempunyai kod uniknya sendiri. Dan tugas sistem kami adalah untuk menjejak dan mengesahkan kesahihan pergerakan setiap pek tersebut antara gudang dan kedai, dan akhirnya mengesahkan kebolehterimaan jualan mereka kepada pembeli akhir. Dan kami merekodkan kira-kira 000 transaksi tunai setiap jam, dan kami juga perlu merekodkan cara setiap pek tersebut masuk ke dalam kedai. Oleh itu, dengan mengambil kira semua pergerakan antara objek, kami menjangkakan berpuluh bilion rekod setiap tahun.
Pasukan M
Walaupun fakta bahawa Marcus dianggap sebagai projek dalam X5, ia sedang dilaksanakan menggunakan pendekatan produk. Pasukan ini bekerja mengikut Scrum. Projek ini bermula pada musim panas lalu, tetapi keputusan pertama hanya datang pada bulan Oktober - pasukan kami sendiri telah dipasang sepenuhnya, seni bina sistem telah dibangunkan dan peralatan telah dibeli. Kini pasukan itu mempunyai 16 orang, enam daripadanya terlibat dalam pembangunan bahagian belakang dan bahagian hadapan, tiga daripadanya terlibat dalam analisis sistem. Enam orang lagi terlibat dalam manual, memuatkan, ujian automatik dan penyelenggaraan produk. Selain itu, kami mempunyai pakar SRE.
Bukan sahaja pembangun menulis kod dalam pasukan kami; hampir semua lelaki tahu cara memprogram dan menulis ujian auto, memuatkan skrip dan skrip automasi. Kami memberi perhatian khusus kepada perkara ini, kerana walaupun sokongan produk memerlukan tahap automasi yang tinggi. Kami sentiasa cuba menasihati dan membantu rakan sekerja yang tidak pernah memprogramkan sebelum ini, dan memberi mereka beberapa tugasan kecil untuk diusahakan.
Disebabkan oleh wabak coronavirus, kami memindahkan seluruh pasukan ke kerja jauh; ketersediaan semua alatan untuk pengurusan pembangunan, aliran kerja terbina dalam Jira dan GitLab membolehkan anda melepasi peringkat ini dengan mudah. Bulan-bulan yang dibelanjakan dari jauh menunjukkan bahawa produktiviti pasukan tidak terjejas akibatnya; bagi ramai, keselesaan di tempat kerja meningkat, satu-satunya perkara yang hilang ialah komunikasi secara langsung.
Mesyuarat pasukan jauh
Mesyuarat semasa kerja jauh
Timbunan teknologi penyelesaian
Repositori standard dan alat CI/CD untuk X5 ialah GitLab. Kami menggunakannya untuk penyimpanan kod, ujian berterusan dan penggunaan untuk menguji dan pelayan pengeluaran. Kami juga menggunakan amalan semakan kod, apabila sekurang-kurangnya 2 rakan sekerja perlu meluluskan perubahan yang dibuat oleh pembangun kepada kod. Penganalisis kod statik SonarQube dan JaCoCo membantu kami memastikan kod kami bersih dan memastikan tahap liputan ujian unit yang diperlukan. Semua perubahan pada kod mesti melalui semakan ini. Semua skrip ujian yang dijalankan secara manual kemudiannya diautomatikkan.
Untuk kejayaan pelaksanaan proses perniagaan oleh "Marcus", kami perlu menyelesaikan beberapa masalah teknologi, kira-kira setiap satu mengikut urutan.
Tugasan 1. Keperluan untuk skala mendatar sistem
Untuk menyelesaikan masalah ini, kami memilih pendekatan perkhidmatan mikro kepada seni bina. Pada masa yang sama, adalah sangat penting untuk memahami bidang tanggungjawab perkhidmatan. Kami cuba membahagikannya kepada operasi perniagaan, dengan mengambil kira spesifik proses. Sebagai contoh, penerimaan di gudang bukanlah operasi yang sangat kerap, tetapi sangat besar, di mana ia perlu untuk mendapatkan maklumat dengan cepat daripada pengawal selia negeri tentang unit barang yang diterima, yang jumlahnya dalam satu penghantaran mencapai 600000 , semak kebolehterimaan menerima produk ini ke dalam gudang dan kembalikan semua maklumat yang diperlukan untuk sistem automasi gudang. Tetapi penghantaran dari gudang mempunyai keamatan yang lebih besar, tetapi pada masa yang sama beroperasi dengan jumlah data yang kecil.
Kami melaksanakan semua perkhidmatan secara tanpa kewarganegaraan dan juga cuba membahagikan operasi dalaman kepada langkah-langkah, menggunakan apa yang kami panggil topik kendiri Kafka. Ini adalah apabila perkhidmatan mikro menghantar mesej kepada dirinya sendiri, yang membolehkan anda mengimbangi beban pada operasi yang lebih intensif sumber dan memudahkan penyelenggaraan produk, tetapi lebih lanjut mengenainya kemudian.
Kami memutuskan untuk memisahkan modul untuk interaksi dengan sistem luaran kepada perkhidmatan yang berasingan. Ini memungkinkan untuk menyelesaikan masalah API sistem luaran yang kerap berubah, dengan hampir tiada kesan ke atas perkhidmatan dengan fungsi perniagaan.
Semua perkhidmatan mikro digunakan dalam kluster OpenShift, yang menyelesaikan kedua-dua masalah penskalaan setiap perkhidmatan mikro dan membenarkan kami untuk tidak menggunakan alat Penemuan Perkhidmatan pihak ketiga.
Tugas 2. Keperluan untuk mengekalkan beban yang tinggi dan pertukaran data yang sangat intensif antara perkhidmatan platform: Semasa fasa pelancaran projek sahaja, kira-kira 600 operasi sesaat dilakukan. Kami menjangkakan nilai ini meningkat kepada 5000 ops/saat apabila kedai runcit menyambung ke platform kami.
Masalah ini telah diselesaikan dengan menggunakan kluster Kafka dan hampir sepenuhnya meninggalkan interaksi segerak antara perkhidmatan mikro platform. Ini memerlukan analisis yang sangat teliti terhadap keperluan sistem, kerana tidak semua operasi boleh menjadi tak segerak. Pada masa yang sama, kami bukan sahaja menghantar acara melalui broker, tetapi juga menghantar semua maklumat perniagaan yang diperlukan dalam mesej. Oleh itu, saiz mesej boleh mencapai beberapa ratus kilobait. Had saiz mesej dalam Kafka memerlukan kami meramalkan saiz mesej dengan tepat, dan jika perlu, kami membahagikannya, tetapi pembahagiannya adalah logik, berkaitan dengan operasi perniagaan.
Sebagai contoh, kita membahagikan barang yang tiba di dalam kereta ke dalam kotak. Untuk operasi segerak, perkhidmatan mikro yang berasingan diperuntukkan dan ujian beban menyeluruh dijalankan. Menggunakan Kafka memberikan kami satu lagi cabaran - menguji operasi perkhidmatan kami dengan mengambil kira penyepaduan Kafka menjadikan semua ujian unit kami tidak segerak. Kami menyelesaikan masalah ini dengan menulis kaedah utiliti kami sendiri menggunakan Embedded Kafka Broker. Ini tidak menghapuskan keperluan untuk menulis ujian unit untuk kaedah individu, tetapi kami lebih suka menguji kes kompleks menggunakan Kafka.
Banyak perhatian telah diberikan kepada pengesanan log supaya TraceId mereka tidak akan hilang apabila pengecualian berlaku semasa pengendalian perkhidmatan atau semasa bekerja dengan kumpulan Kafka. Dan jika tiada isu khas dengan yang pertama, maka dalam kes kedua kami terpaksa log semua TraceId yang disertakan dengan kumpulan dan pilih satu untuk meneruskan pengesanan. Kemudian, apabila mencari mengikut TraceId asal, pengguna akan dengan mudah mengetahui dengan mana pengesanan diteruskan.
Tugasan 3. Keperluan untuk menyimpan sejumlah besar data: Lebih daripada 1 bilion label setahun untuk tembakau sahaja datang ke X5. Mereka memerlukan akses yang berterusan dan cepat. Secara keseluruhan, sistem mesti memproses kira-kira 10 bilion rekod sejarah pergerakan barangan berlabel ini.
Untuk menyelesaikan masalah ketiga, pangkalan data NoSQL MongoDB telah dipilih. Kami telah membina serpihan 5 nod dan setiap nod mempunyai Set Replika 3 pelayan. Ini membolehkan anda menskalakan sistem secara mendatar, menambah pelayan baharu pada kluster, dan memastikan toleransi kesalahannya. Di sini kami menghadapi masalah lain - memastikan transaksi dalam kelompok mongo, dengan mengambil kira penggunaan perkhidmatan mikro boleh skala mendatar. Sebagai contoh, salah satu tugas sistem kami adalah untuk mengenal pasti percubaan untuk menjual semula produk dengan kod pelabelan yang sama. Di sini, tindanan muncul dengan imbasan yang salah atau operasi yang salah oleh juruwang. Kami mendapati bahawa pendua tersebut boleh berlaku dalam satu kelompok Kafka sedang diproses dan dalam dua kelompok sedang diproses secara selari. Oleh itu, menyemak pendua dengan menanyakan pangkalan data tidak memberikan apa-apa. Untuk setiap perkhidmatan mikro, kami menyelesaikan masalah secara berasingan berdasarkan logik perniagaan perkhidmatan ini. Contohnya, untuk semakan, kami menambah cek di dalam kelompok dan pemprosesan berasingan untuk kemunculan pendua semasa memasukkan.
Untuk memastikan bahawa kerja pengguna dengan sejarah operasi tidak dalam apa-apa cara menjejaskan perkara yang paling penting - fungsi proses perniagaan kami, kami telah memisahkan semua data sejarah ke dalam perkhidmatan yang berasingan dengan pangkalan data yang berasingan, yang juga menerima maklumat melalui Kafka . Dengan cara ini, pengguna bekerja dengan perkhidmatan terpencil tanpa menjejaskan perkhidmatan yang memproses data untuk operasi yang sedang berjalan.
Tugasan 4: Pemprosesan semula baris gilir dan pemantauan:
Dalam sistem teragih, masalah dan ralat tidak dapat dielakkan timbul dalam ketersediaan pangkalan data, baris gilir, dan sumber data luaran. Dalam kes Marcus, punca ralat tersebut ialah penyepaduan dengan sistem luaran. Adalah perlu untuk mencari penyelesaian yang membenarkan permintaan berulang untuk respons yang salah dengan beberapa tamat masa yang ditentukan, tetapi pada masa yang sama tidak berhenti memproses permintaan yang berjaya dalam baris gilir utama. Untuk tujuan ini, konsep yang dipanggil "cuba semula berdasarkan topik" telah dipilih. Untuk setiap topik utama, satu atau lebih topik cuba semula dibuat yang menghantar mesej yang salah dan pada masa yang sama kelewatan dalam memproses mesej daripada topik utama dihapuskan. Skim interaksi -
Untuk melaksanakan skim sedemikian, kami memerlukan perkara berikut: untuk menyepadukan penyelesaian ini dengan Spring dan mengelakkan pertindihan kod. Semasa melayari web, kami menemui penyelesaian yang serupa berdasarkan Spring BeanPostProccessor, tetapi ia kelihatan tidak semestinya menyusahkan kami. Pasukan kami telah membuat penyelesaian yang lebih mudah yang membolehkan kami menyepadukan ke dalam kitaran Spring untuk mencipta pengguna dan menambah Cuba Semula Pengguna. Kami menawarkan prototaip penyelesaian kami kepada pasukan Spring, anda boleh melihatnya . Bilangan Pengguna Cuba Semula dan bilangan percubaan untuk setiap pengguna dikonfigurasikan melalui parameter, bergantung pada keperluan proses perniagaan dan untuk semuanya berfungsi, yang tinggal hanyalah menambah anotasi org.springframework.kafka.annotation.KafkaListener , yang biasa kepada semua pembangun Spring.
Jika mesej tidak dapat diproses selepas semua percubaan cuba semula, ia pergi ke DLT (topik surat mati) menggunakan Spring DeadLetterPublishingRecoverer. Atas permintaan sokongan, kami mengembangkan fungsi ini dan mencipta perkhidmatan berasingan yang membolehkan anda melihat mesej yang disertakan dalam DLT, stackTrace, traceId dan maklumat berguna lain mengenainya. Selain itu, pemantauan dan makluman telah ditambahkan pada semua topik DLT, dan kini, sebenarnya, kemunculan mesej dalam topik DLT adalah sebab untuk menganalisis dan membetulkan kecacatan. Ini sangat mudah - dengan nama topik, kami segera memahami pada tahap mana proses masalah itu timbul, yang dengan ketara mempercepatkan pencarian puncanya.
Terbaru, kami telah melaksanakan antara muka yang membolehkan kami menghantar semula mesej menggunakan sokongan kami selepas menghapuskan puncanya (contohnya, memulihkan kefungsian sistem luaran) dan, sudah tentu, mewujudkan kecacatan yang sepadan untuk analisis. Di sinilah topik diri kita berguna: untuk tidak memulakan semula rantaian pemprosesan yang panjang, anda boleh memulakannya semula dari langkah yang diingini.
Operasi Platform
Platform ini sudah beroperasi secara produktif, setiap hari kami menjalankan penghantaran dan penghantaran, menghubungkan pusat pengedaran dan kedai baharu. Sebagai sebahagian daripada perintis, sistem ini berfungsi dengan kumpulan produk "Tembakau" dan "Kasut".
Seluruh pasukan kami mengambil bahagian dalam menjalankan perintis, menganalisis masalah yang timbul dan membuat cadangan untuk menambah baik produk kami, daripada menambah baik log kepada proses yang berubah.
Untuk tidak mengulangi kesilapan kami, semua kes yang ditemui semasa perintis ditunjukkan dalam ujian automatik. Kehadiran sejumlah besar autotest dan ujian unit membolehkan anda menjalankan ujian regresi dan memasang hotfix secara literal dalam masa beberapa jam.
Kini kami terus membangun dan menambah baik platform kami, dan sentiasa menghadapi cabaran baharu. Jika anda berminat, kami akan membincangkan penyelesaian kami dalam artikel berikut.
Sumber: www.habr.com