Sejak 2019, Rusia telah memiliki undang-undang tentang pelabelan wajib. Undang-undang ini tidak berlaku untuk semua kelompok barang, dan tanggal berlakunya pelabelan wajib untuk kelompok produk berbeda-beda. Tembakau, sepatu, dan obat-obatan akan menjadi produk pertama yang wajib diberi label; produk lain akan ditambahkan kemudian, misalnya parfum, tekstil, dan susu. Inovasi legislatif ini mendorong pengembangan solusi TI baru yang memungkinkan pelacakan seluruh rantai kehidupan suatu produk mulai dari produksi hingga pembelian oleh konsumen akhir, hingga semua peserta dalam proses: baik negara itu sendiri maupun semua organisasi yang menjual barang dengan pelabelan wajib.
Di X5, sistem yang akan melacak barang berlabel dan bertukar data dengan negara bagian dan pemasok disebut “Marcus”. Mari beri tahu Anda bagaimana dan siapa yang mengembangkannya, apa saja tumpukan teknologinya, dan mengapa kita memiliki sesuatu yang bisa dibanggakan.
Beban Tinggi Nyata
Marcus memecahkan banyak masalah, yang utama adalah interaksi integrasi antara sistem informasi X5 dan sistem informasi negara untuk produk berlabel (GIS MP) untuk melacak pergerakan produk berlabel. Platform ini juga menyimpan semua kode pelabelan yang kami terima dan seluruh riwayat pergerakan kode ini di seluruh objek, dan membantu menghilangkan penilaian ulang produk yang diberi label. Dengan menggunakan contoh produk tembakau yang termasuk dalam kelompok barang berlabel pertama, satu truk muatan rokok saja berisi sekitar 600 bungkus yang masing-masing memiliki kode uniknya sendiri. Dan tugas sistem kami adalah melacak dan memverifikasi legalitas pergerakan setiap paket antara gudang dan toko, dan pada akhirnya memverifikasi kelayakan penjualannya kepada pembeli akhir. Dan kami mencatat sekitar 000 transaksi tunai per jam, dan kami juga perlu mencatat bagaimana setiap paket tersebut masuk ke toko. Jadi, dengan mempertimbangkan semua pergerakan antar objek, kita memperkirakan puluhan miliar rekaman per tahun.
Tim M
Terlepas dari kenyataan bahwa Marcus dianggap sebagai proyek dalam X5, proyek ini dilaksanakan menggunakan pendekatan produk. Tim bekerja sesuai dengan Scrum. Proyek ini dimulai musim panas lalu, tetapi hasil pertama baru muncul pada bulan Oktober - tim kami telah sepenuhnya terbentuk, arsitektur sistem dikembangkan, dan peralatan dibeli. Kini tim tersebut beranggotakan 16 orang, enam di antaranya terlibat dalam pengembangan backend dan frontend, tiga di antaranya terlibat dalam analisis sistem. Enam orang lagi terlibat dalam pengujian manual, pemuatan, otomatis, dan pemeliharaan produk. Selain itu, kami memiliki spesialis SRE.
Tidak hanya pengembang yang menulis kode di tim kami; hampir semua orang tahu cara memprogram dan menulis tes otomatis, memuat skrip, dan skrip otomatisasi. Kami memberikan perhatian khusus pada hal ini, karena dukungan produk pun memerlukan otomatisasi tingkat tinggi. Kami selalu berusaha menasihati dan membantu rekan-rekan yang belum pernah memprogram sebelumnya, dan memberi mereka beberapa tugas kecil untuk dikerjakan.
Karena pandemi virus corona, kami memindahkan seluruh tim ke pekerjaan jarak jauh; ketersediaan semua alat untuk manajemen pengembangan, alur kerja yang dibangun di Jira dan GitLab memungkinkan kami melewati tahap ini dengan mudah. Bulan-bulan yang dihabiskan dari jarak jauh menunjukkan bahwa produktivitas tim tidak menurun; bagi banyak orang, kenyamanan di tempat kerja meningkat, satu-satunya hal yang hilang hanyalah komunikasi langsung.
Pertemuan tim jarak jauh
Rapat selama bekerja jarak jauh
Tumpukan teknologi solusinya
Repositori standar dan alat CI/CD untuk X5 adalah GitLab. Kami menggunakannya untuk penyimpanan kode, pengujian berkelanjutan, dan penerapan ke server pengujian dan produksi. Kami juga menggunakan praktik peninjauan kode, ketika setidaknya 2 rekan kerja harus menyetujui perubahan yang dilakukan oleh pengembang pada kode. Penganalisis kode statis SonarQube dan JaCoCo membantu kami menjaga kode tetap bersih dan memastikan tingkat cakupan pengujian unit yang diperlukan. Semua perubahan pada kode harus melalui pemeriksaan ini. Semua skrip pengujian yang dijalankan secara manual selanjutnya diotomatisasi.
Agar implementasi proses bisnis oleh “Marcus” berhasil, kami harus menyelesaikan sejumlah masalah teknologi, masing-masing secara berurutan.
Tugas 1. Perlunya skalabilitas horizontal sistem
Untuk mengatasi masalah ini, kami memilih pendekatan layanan mikro pada arsitektur. Pada saat yang sama, sangat penting untuk memahami bidang tanggung jawab layanan tersebut. Kami mencoba membaginya ke dalam operasi bisnis, dengan mempertimbangkan proses spesifiknya. Misalnya, penerimaan di gudang bukanlah operasi yang sangat sering, tetapi berskala sangat besar, di mana perlu untuk segera memperoleh informasi dari regulator negara tentang unit barang yang diterima, yang jumlahnya dalam satu pengiriman mencapai 600000. , periksa diterimanya penerimaan produk ini ke gudang dan kembalikan semua informasi yang diperlukan untuk sistem otomasi gudang. Namun pengiriman dari gudang memiliki intensitas yang jauh lebih besar, namun pada saat yang sama beroperasi dengan volume data yang kecil.
Kami menerapkan semua layanan tanpa kewarganegaraan dan bahkan mencoba membagi operasi internal menjadi beberapa langkah, menggunakan apa yang kami sebut topik mandiri Kafka. Ini adalah saat layanan mikro mengirimkan pesan ke dirinya sendiri, yang memungkinkan Anda menyeimbangkan beban pada operasi yang lebih intensif sumber daya dan menyederhanakan pemeliharaan produk, tetapi akan dibahas lebih lanjut nanti.
Kami memutuskan untuk memisahkan modul untuk interaksi dengan sistem eksternal ke dalam layanan terpisah. Hal ini memungkinkan pemecahan masalah API sistem eksternal yang sering berubah, tanpa berdampak pada layanan dengan fungsi bisnis.
Semua layanan mikro disebarkan dalam kluster OpenShift, yang memecahkan masalah penskalaan setiap layanan mikro dan memungkinkan kami untuk tidak menggunakan alat Service Discovery pihak ketiga.
Tugas 2. Kebutuhan untuk mempertahankan beban tinggi dan pertukaran data yang sangat intensif antar layanan platform: Selama fase peluncuran proyek saja, sekitar 600 operasi per detik dilakukan. Kami memperkirakan nilai ini akan meningkat menjadi 5000 operasi/dtk saat gerai ritel terhubung ke platform kami.
Masalah ini diselesaikan dengan menerapkan cluster Kafka dan hampir sepenuhnya mengabaikan interaksi sinkron antara layanan mikro platform. Hal ini memerlukan analisis yang sangat cermat terhadap persyaratan sistem, karena tidak semua operasi dapat dilakukan secara asinkron. Pada saat yang sama, kami tidak hanya mengirimkan peristiwa melalui broker, tetapi juga mengirimkan semua informasi bisnis yang diperlukan melalui pesan. Dengan demikian, ukuran pesan bisa mencapai beberapa ratus kilobyte. Batasan ukuran pesan di Kafka mengharuskan kami memprediksi ukuran pesan secara akurat, dan jika perlu, kami membaginya, namun pembagiannya logis, terkait dengan operasional bisnis.
Misalnya kita membagi barang yang datang dengan mobil ke dalam kotak-kotak. Untuk operasi sinkron, layanan mikro terpisah dialokasikan dan pengujian beban menyeluruh dilakukan. Penggunaan Kafka memberi kami tantangan lain - menguji pengoperasian layanan kami dengan mempertimbangkan integrasi Kafka membuat semua pengujian unit kami tidak sinkron. Kami memecahkan masalah ini dengan menulis metode utilitas kami sendiri menggunakan Broker Kafka Tertanam. Hal ini tidak menghilangkan kebutuhan untuk menulis pengujian unit untuk metode individual, namun kami lebih memilih untuk menguji kasus kompleks menggunakan Kafka.
Banyak perhatian diberikan pada log penelusuran sehingga TraceId-nya tidak hilang saat terjadi pengecualian selama pengoperasian layanan atau saat bekerja dengan batch Kafka. Dan jika tidak ada masalah khusus dengan yang pertama, maka dalam kasus kedua kami terpaksa mencatat semua TraceId yang disertakan dalam batch dan memilih satu untuk melanjutkan penelusuran. Kemudian, ketika mencari berdasarkan TraceId asli, pengguna akan dengan mudah mengetahui penelusuran yang dilanjutkan.
Tugas 3. Kebutuhan untuk menyimpan data dalam jumlah besar: Lebih dari 1 miliar label per tahun untuk tembakau saja hadir di X5. Mereka memerlukan akses yang konstan dan cepat. Secara total, sistem harus memproses sekitar 10 miliar catatan sejarah pergerakan barang berlabel tersebut.
Untuk mengatasi masalah ketiga, database NoSQL MongoDB dipilih. Kami telah membangun pecahan 5 node dan setiap node memiliki Kumpulan Replika yang terdiri dari 3 server. Hal ini memungkinkan Anda untuk menskalakan sistem secara horizontal, menambahkan server baru ke cluster, dan memastikan toleransi kesalahannya. Di sini kami menemui masalah lain - memastikan transaksionalitas di cluster mongo, dengan mempertimbangkan penggunaan layanan mikro yang dapat diskalakan secara horizontal. Misalnya, salah satu tugas sistem kami adalah mengidentifikasi upaya menjual kembali produk dengan kode pelabelan yang sama. Di sini, overlay muncul dengan pemindaian yang salah atau operasi yang salah oleh kasir. Kami menemukan bahwa duplikat tersebut dapat terjadi baik dalam satu batch Kafka yang sedang diproses, maupun dalam dua batch yang diproses secara paralel. Jadi, memeriksa duplikat dengan menanyakan database tidak menghasilkan apa-apa. Untuk setiap layanan mikro, kami memecahkan masalah secara terpisah berdasarkan logika bisnis layanan ini. Misalnya, untuk pemeriksaan, kami menambahkan pemeriksaan di dalam batch dan pemrosesan terpisah untuk tampilan duplikat saat memasukkan.
Untuk memastikan bahwa pekerjaan pengguna dengan riwayat operasi tidak mempengaruhi hal yang paling penting - fungsi proses bisnis kami, kami telah memisahkan semua data historis ke dalam layanan terpisah dengan database terpisah, yang juga menerima informasi melalui Kafka . Dengan cara ini, pengguna bekerja dengan layanan yang terisolasi tanpa memengaruhi layanan yang memproses data untuk operasi yang sedang berlangsung.
Tugas 4: Pemrosesan ulang dan pemantauan antrian:
Dalam sistem terdistribusi, masalah dan kesalahan pasti muncul pada ketersediaan database, antrian, dan sumber data eksternal. Dalam kasus Marcus, sumber kesalahan tersebut adalah integrasi dengan sistem eksternal. Penting untuk menemukan solusi yang memungkinkan permintaan berulang untuk respons yang salah dengan batas waktu tertentu, tetapi pada saat yang sama tidak menghentikan pemrosesan permintaan yang berhasil di antrian utama. Untuk tujuan ini, apa yang disebut konsep “percobaan ulang berdasarkan topik” dipilih. Untuk setiap topik utama, satu atau lebih topik percobaan ulang dibuat di mana pesan yang salah dikirim dan pada saat yang sama penundaan dalam pemrosesan pesan dari topik utama dihilangkan. Skema interaksi -
Untuk mengimplementasikan skema seperti itu, kami memerlukan hal berikut: mengintegrasikan solusi ini dengan Spring dan menghindari duplikasi kode. Saat menjelajahi web, kami menemukan solusi serupa berdasarkan Spring BeanPostProccessor, tetapi tampaknya tidak terlalu rumit bagi kami. Tim kami telah membuat solusi sederhana yang memungkinkan kami berintegrasi ke dalam siklus Musim Semi untuk menciptakan konsumen dan juga menambahkan Coba Lagi Konsumen. Kami menawarkan prototipe solusi kami kepada tim Spring, Anda dapat melihatnya . Jumlah Konsumen Coba Ulang dan jumlah upaya untuk setiap konsumen dikonfigurasikan melalui parameter, bergantung pada kebutuhan proses bisnis, dan agar semuanya berfungsi, yang tersisa hanyalah menambahkan anotasi org.springframework.kafka.annotation.KafkaListener , yang familiar bagi semua pengembang Spring.
Jika pesan tidak dapat diproses setelah semua upaya mencoba lagi, pesan akan masuk ke DLT (topik surat mati) menggunakan Spring DeadLetterPublishingRecoverer. Atas permintaan dukungan, kami memperluas fungsi ini dan membuat layanan terpisah yang memungkinkan Anda melihat pesan yang disertakan dalam DLT, stackTrace, traceId, dan informasi berguna lainnya tentang pesan tersebut. Selain itu, pemantauan dan peringatan telah ditambahkan ke semua topik DLT, dan sekarang, sebenarnya, kemunculan pesan di topik DLT menjadi alasan untuk menganalisis dan memperbaiki kerusakan. Ini sangat mudah - dengan nama topiknya, kita segera memahami pada langkah proses apa masalah itu muncul, yang secara signifikan mempercepat pencarian akar masalahnya.
Baru-baru ini, kami telah menerapkan antarmuka yang memungkinkan kami mengirim ulang pesan menggunakan dukungan kami setelah menghilangkan penyebabnya (misalnya, memulihkan fungsionalitas sistem eksternal) dan, tentu saja, menetapkan cacat yang sesuai untuk dianalisis. Di sinilah topik mandiri kami berguna: agar tidak memulai kembali rantai pemrosesan yang panjang, Anda dapat memulai ulang dari langkah yang diinginkan.
Pengoperasian Platform
Platform ini sudah beroperasi secara produktif, setiap hari kami melakukan pengiriman dan pengiriman, menghubungkan pusat distribusi dan toko baru. Sebagai bagian dari uji coba, sistem ini bekerja dengan kelompok produk “Tembakau” dan “Sepatu”.
Seluruh tim kami berpartisipasi dalam melakukan uji coba, menganalisis masalah yang muncul, dan memberikan saran untuk meningkatkan produk kami, mulai dari meningkatkan log hingga mengubah proses.
Agar tidak mengulangi kesalahan kami, semua kasus yang ditemukan selama uji coba tercermin dalam pengujian otomatis. Kehadiran sejumlah besar pengujian otomatis dan pengujian unit memungkinkan Anda melakukan pengujian regresi dan menginstal perbaikan terbaru hanya dalam beberapa jam.
Kini kami terus mengembangkan dan meningkatkan platform kami, dan terus menghadapi tantangan baru. Jika Anda tertarik, kami akan membicarakan solusi kami di artikel berikut.
Sumber: www.habr.com