Infrastruktur teknologi M.Video-Eldorado Group saat ini lebih dari sekadar rangkaian mesin kasir raksasa di lebih dari 1000 toko di seluruh negeri. Di balik terpal, kami memiliki platform online yang menyediakan interaksi pelanggan, pembelajaran mesin, algoritme penelusuran cerdas, bot obrolan, sistem rekomendasi, otomatisasi proses bisnis utama, dan aliran dokumen elektronik. Di bawah potongan, ada cerita rinci tentang apa yang mendorong kami untuk memecah monolit menjadi layanan mikro.
Legenda kuno yang dalam
Agar semua ini berfungsi seperti jarum jam, kita perlu mengikuti perkembangan teknologi dan segera menanggapi permintaan bisnis. Sayangnya, fungsionalitas dasar dari sistem ERP global masih jauh dari kemampuan untuk merespon dengan cepat kebutuhan pelanggan internal yang muncul. Pada 2016, ini menjadi salah satu argumen yang mendukung transisi kami ke arsitektur layanan mikro.
Perusahaan dihadapkan pada tugas yang agak sulit, untuk menerapkan logika bisnis terpadu bekerja dengan berbagai mekanik promosi dalam proses menempatkan pesanan oleh pelanggan di semua saluran penjualan dan titik kontak (pada saat itu: situs web, aplikasi seluler, meja kas) dan terminal di toko dan operator di pusat panggilan).
Pada saat yang sama, dalam lanskap TI, kami memiliki sistem monolitik besar seperti platform E-commerce Oracle ATG, SAP CRM, dan lainnya. Pengulangan logika di masing-masing atau implementasi di satu dan penggunaan kembali di fungsi lain yang diperlukan, menurut perhitungan kami, menghasilkan waktu bertahun-tahun dan puluhan juta investasi.
Oleh karena itu, kami mengumpulkan tim kecil pengembang dan orang-orang yang secara teknis kompeten yang siap membantu kami saat itu, dan memikirkan tentang bagaimana kami dapat membuat layanan terpisah untuk kebutuhan kami. Dalam proses elaborasi, kami menyadari bahwa sebenarnya kami membutuhkan bukan hanya satu, tetapi tiga atau empat alat kerja. Inilah bagaimana kita sampai pada konsep arsitektur layanan mikro untuk pertama kalinya.
Kami memutuskan untuk membuat kode di Java, karena kami memiliki pengalaman yang diperlukan dalam hal ini. Kami memilih Spring versi 3.2. Hasilnya, kami mendapatkan sejenis mikromonolit terdistribusi dalam tiga atau empat layanan, yang saling berhubungan erat satu sama lain. Terlepas dari kenyataan bahwa mereka dikembangkan secara mandiri, hanya semua orang yang bisa bekerja sama.
Namun, ini adalah lompatan besar dalam mengembangkan teknologinya sendiri. Kami beralih dari Java 6 ke Java 8, mulai menguasai Spring 3, dengan mulus beralih ke Spring 4. Tentu saja, itu adalah uji coba tertentu.
Kami telah berhasil mengurangi jangka waktu implementasi proyek dari "bulan untuk pengembangan" yang tidak jelas, setelah menerapkan logika bisnis lintas saluran yang diperlukan dalam hampir dua bulan.
Evolusi teknologi
Pada 2017-18, kami memulai pemfaktoran ulang global mikromonolit. Konsep pengembangan layanan mikro disukai oleh spesialis IT dan bisnis. Alur tugas kerja mulai berkembang. Selain itu, kami terus mengisolasi blok fungsional yang dibutuhkan oleh konsumen yang berbeda dari lanskap TI perusahaan dan menerjemahkannya ke dalam rel layanan mikro.
Kami mencoba mengikuti waktu dan melompat ke Jawa 9, tetapi tidak berhasil. Sayangnya, kami tidak mendapatkan manfaat nyata dari latihan ini, jadi kami tetap menggunakan Java 8. Ada
semakin banyak layanan, mereka harus dikelola secara terpusat dan bekerja dengannya distandarisasi. Di sinilah kami mencoba penampung untuk pertama kalinya. Kontainer Docker kemudian besar dan berat, masing-masing beberapa ratus megabyte.
Nanti, kami harus menyelesaikan masalah dengan menyeimbangkan lalu lintas dan memuat layanan. Kami memilih Konsul untuk klien eksternal dan Eureka untuk klien internal sebagai solusi. Kami mencoba berbagai alat komunikasi antar-layanan gRPC, RMI. Kami hidup seperti ini selama hampir satu tahun, dan tampaknya bagi kami bahwa kami telah belajar cara berhasil membuat layanan mikro dan membangun arsitektur layanan mikro.
Kencangkan sabuk pengaman Anda, kami tenggelam!
Pada tahun 2019, jumlah layanan mikro kami telah meningkat secara signifikan, melebihi angka 100+. Kami menerapkan solusi baru untuk komunikasi antar-layanan, jika memungkinkan, mencoba menerapkan pendekatan berbasis peristiwa.
Sementara itu, masalah orkestrasi dan manajemen ketergantungan menjadi semakin akut. Namun perubahan terbesar yang sudah menyentuh kami di awal tahun 2019 terkait dengan perubahan kebijakan perusahaan terkait penggunaan Java.
Kami memiliki pilihan tentang apa yang harus dilakukan selanjutnya: tetap bersama Oracle dan membayar mereka banyak uang, berinvestasi dalam open jdk kami sendiri, atau mencoba menemukan beberapa alternatif nyata.
Kami memilih opsi ketiga dan bersama dengan BellSoft, yang merupakan salah satu dari lima pemimpin dunia yang terlibat dalam pengembangan proyek OpenJDK, setelah serangkaian pertemuan dan diskusi, kami membentuk rencana untuk transisi dan uji coba versi baru Java , dan menggabungkan ini dengan transisi langsung ke Java 11. Prosesnya sulit, tetapi pada semua pengujian, kami tidak merasakan masalah yang serius dan tidak dapat dipecahkan.
Langkah selanjutnya bagi kami adalah penerapan manajemen kontainer untuk Kubernetes. Berkat ini, untuk beberapa waktu kami merasa semuanya baik-baik saja dan kami telah mencapai kesuksesan yang serius. Namun kemudian muncul masalah infrastruktur berikutnya. Dia sama sekali tidak bisa mengatasi peningkatan beban yang konstan.
Kami benar-benar tidak punya waktu untuk mengukur. Kebutuhan akan transformasi teknis utama berikutnya menjadi jelas. Jadi kami mulai melihat ke arah teknologi cloud dan berusaha untuk mencobanya sendiri.
Bangkitlah di atas awan
Awal tahun 2020 menjanjikan kami langkah besar dalam pengembangan teknologi internal, pemahaman, dan peningkatan arsitektur layanan mikro kami. Di depan ada langkah besar menuju awan. Sayangnya, rencana tersebut harus diperbaiki, seperti yang mereka katakan, tepat selama permainan berlangsung.
Karena pandemi COVID-19, alih-alih bermigrasi secara bertahap dan mengeksplorasi kemungkinan layanan cloud, kami meminta seluruh perusahaan untuk mencari alat baru guna memenuhi kebutuhan pelanggan kami yang terus berubah karena pandemi. Kami benar-benar membuat layanan mikro berikutnya, secara bersamaan memperkenalkan teknologi baru dan masih beralih ke infrastruktur cloud.
Bagi kami, ukuran container menjadi penting karena dua alasan sederhana: ini adalah uang untuk daya komputasi cloud yang dikonsumsi dan waktu yang dihabiskan oleh pengembang, dan oleh karena itu, seluruh perusahaan, untuk mengangkat container, menyinkronkan dan mengonfigurasinya, menjalankan autotests, dan seterusnya. Dan di sini kami benar-benar merasakan keuntungan dan kegunaan container kompak kami dengan runtime JDK Liberica.
Terlepas dari tingginya pandemi, dalam beberapa bulan kami telah menerapkan dan berhasil meluncurkan dua lusin layanan mikro ke dalam operasi produktif, yang seluruhnya didasarkan pada infrastruktur cloud.
Pada akhir tahun 2020, kami fokus pada hal-hal proses: kami menginvestasikan banyak waktu dan tenaga dalam membangun pendekatan produk, dalam mengembangkan layanan mikro, dalam pemilihan dan pembentukan tim terpisah dengan metrik dan KPI mereka sendiri di berbagai area unit bisnis. .
Memotong monolit menjadi layanan mikro menggunakan contoh layanan penghitungan pesanan
Agar tidak menguji kesabaran Anda, saya ingin menunjukkan contoh spesifik dan logika bekerja dengan infrastruktur layanan mikro. Mari kita ambil kalkulasi pesanan tipikal dalam lingkungan TI standar.
Kami menghadapi berbagai macam tantangan. Data master kami berada jauh di dalam sistem di back office. Setiap sistem TI adalah monolit klasik: database, server aplikasi. Integrasi sistem master dengan peserta lain dalam lanskap TI dilakukan sebagai "point-to-point", yaitu, setiap sistem TI mengintegrasikan dirinya sendiri, dengan caranya sendiri dan setiap saat.
Integrasi tersebut terutama terdiri dari dua jenis: replikasi di tingkat database, transfer file. Logika perhitungan diulangi di setiap sistem TI secara terpisah, yaitu dalam bahasa pengembangan yang berbeda, bahkan tidak ada cara untuk menggunakan kembali kode tim tetangga.
Sangat mahal dan hampir tidak mungkin untuk menyinkronkan logika kalkulasi secara bersamaan di semua sistem, karena peta jalan yang berbeda dan biaya sumber daya dari berbagai sistem TI.
Selain itu, ketika menangani keluhan pelanggan, sangat sulit bagi kami untuk menentukan mengapa harga yang benar atau satu atau beberapa diskon lainnya tidak diberikan.
Apa yang telah kita lakukan? Kami menganalisis dan menentukan konteks yang diperlukan untuk perhitungan yang benar dari nilai pesanan. Selanjutnya, kami memilih domain bisnis dan membaginya secara internal menjadi layanan mikro terpisah. Jadi, misalnya, kami menyoroti data barang yang harus diperhitungkan dalam proses penghitungan biaya pesanan.
Kami telah menerapkan layanan untuk mengimpor data dari sistem master secara online menggunakan antrian (Kafka). Di atas data tersebut, kami telah mengimplementasikan layanan mikro atom yang beroperasi dengan kategori produk dan atributnya (produk-atribut-layanan, produk-kategori-layanan). Kami melakukan hal yang sama dengan domain dalam konteks Harga dan Promosi.
Secara terpisah, kami memindahkan logika dan prosedur untuk menghitung harga pesanan ke dalam mesin penghitungan pesanan yang terpisah, menerapkan logika terpadu tunggal untuk menghitung harga dan biaya, menggunakan dana diskon dan kartu promosi.
Kami juga telah menerapkan REST API standar untuk semua klien yang menerapkan logika penyelesaian pesanan. Untuk komunikasi antar-layanan, kami memilih protokol gRPC dengan deskripsi tentang protobuf3.
Hasilnya, layanan mikro standar saat ini terlihat seperti ini: ini adalah aplikasi boot musim semi, yang dikumpulkan dalam container buruh pelabuhan menggunakan GitLab CI dan diterapkan di cluster Kubernetes.
Apa intinya?
Dalam perjalanan evolusi teknis kami, pertama, kami telah merevisi pendekatan terhadap proses pengembangan layanan itu sendiri dan membentuk tim. Kami berfokus pada pendekatan produk, merekrut tim berdasarkan prinsip otonomi maksimum.
Pada saat yang sama, agar tim sesuai dengan domain dan area bisnis tertentu dan, dengan demikian, dapat, bersama dengan kepala fungsi bisnis, berpartisipasi dalam pengembangan area bisnis tertentu.
Dalam hal pengembangan teknis, kami memilih konektivitas asynchronous dengan menggunakan Kafka, termasuk aliran Kafka, sebagai salah satu alat komunikasi antar layanan. Hal ini memungkinkan tim menjadi mandiri secara praktis dari yang lain. Kami juga secara aktif menggunakan dan mempraktikkan praktik pengembangan reaktif, misalnya, proyek reaktor. Kami masih sangat ingin mencoba proyek Loom.
Untuk mempercepat pengembangan, kami berfokus pada pengembangan beberapa faktor teknis dan organisasi yang memungkinkan kami memengaruhi waktu secara signifikan.
Aspek teknologi adalah transisi ke teknologi cloud, yang memastikan kecepatan otomatisasi proses CI \ CD yang optimal. Kecepatan dan durasi regresi penuh dan penerapan layanan mikro tertentu sangat penting di sini.
Misalnya, hari ini proses penuh (dengan semua jenis pengujian unit, kontrak, integrasi) CI \ CD Pipeline untuk aplikasi bisnis produktif yang berfungsi ─ dan ini adalah sekitar 12-15 layanan mikro yang saling berhubungan) adalah sekitar 31 menit, yaitu 7-8 menit kurang dari indikator awal 2020.
Jadi, kami menghabiskan waktu sekitar 17-18% lebih sedikit untuk menunggu hasilnya. Penghematan ini memungkinkan kami untuk menangani tugas belanjaan lainnya. Hal ini sebagian besar disebabkan oleh fakta bahwa kami menggunakan wadah ringkas berdasarkan Alpine Linux, yang semakin cepat dan ringan setiap jam.
Kami menjadi lebih efisien dalam hal pengembangan layanan mikro secara umum. Dan ini memiliki efek positif pada pengalaman pengguna pelanggan kami. Kecepatan adalah salah satu metrik utama dari produk online kami (situs web dan aplikasi seluler) saat ini, dan Liberica JDK juga memungkinkan kami untuk mencapai keuntungan ini, yang dalam hal kinerja kami ubah menjadi pengalaman positif bagi pelanggan kami.
Selain itu, pendekatan yang tepat untuk pengembangan layanan mikro memungkinkan kami mempercepat waktu peluncuran produk ke pasar secara signifikan. Kami mempelajari cara menghadirkan layanan individu ke dalam produksi, menggunakan berbagai strategi untuk penerapan A \ B, pengalengan, dan lainnya sesuai kebutuhan. Ini memungkinkan untuk menerima umpan balik dengan cepat tentang pekerjaan layanan mikro.
Dalam dua bulan kami mengembangkan dan menerapkan beberapa layanan baru dalam pengalaman berbelanja. Kami berbicara tentang apa yang disebut pengiriman barang cepat dalam waktu 2 jam (kami menggunakan berbagai taksi dan agregator pengiriman) dan penerbitan pesanan kami di tempat-tempat yang paling tidak terduga (di toko Pyaterochka atau kantor Pos Rusia, bahkan di tempat parkir yang luas). pusat bisnis).
Berkat layanan mikro kami, beberapa klien M.Video-Eldorado Group memiliki kesempatan untuk naik taksi dengan membawa barang-barang mereka langsung dari toko.
Rencana kreatif
Rencana kami untuk tahun 2021 mencakup pengembangan aktif infrastruktur cloud dan transisi sepenuhnya ke konsep Infrastruktur sebagai kode ("Infrastruktur sebagai kode").
Kami berencana untuk memberikan perhatian besar dalam membangun solusi transparan untuk kontrol dan interaksi layanan mikro dalam bentuk solusi Service Mesh berdasarkan Istio dan Admiral. Kami memiliki banyak pekerjaan di depan kami untuk mengubah dan meningkatkan seluruh tumpukan Observabilitas, memantau pelacakan permintaan dan pencatatan pesan.
Kami juga berencana untuk mencoba menggunakan teknologi tanpa server, termasuk keinginan untuk mencobanya di java. Selain itu, sejauh ini ada gagasan yang jauh tetapi tampaknya tidak realistis untuk membangun infrastruktur dan ekosistem multi-Cloud.
Jika Anda tertarik untuk menyentuh tumpukan teknologi kami dengan tangan Anda, jangan ragu, ada cukup pekerjaan untuk semua orang. Pendaftaran relawan dilakukan 24/7: di sini . Anda dipersilakan .
Manfaat, peretasan hidup, pengalaman pribadi
Dmitry Chuiko , Arsitek Kinerja Senior BellSoft, tentang rahasia wadah Docker kecil untuk layanan mikro Java:
─ . , . Docker-. , : , .
Linux , . JDK. , , .
1.
CentOS CentOS slim. ? Debian. Alpine musl. BellSoft Alpine Linux, — Linux. Liberica JDK 11.0.10 + 11.0.10 Linux.
Liberica EA 3–6 14,7 % Alpine musl java.base. 7,6 %. Docker-, JRE java.base. Liberica JRE EA — 16 %.
Liberica Lite . , , — . - Java SE JVM, Standart, JIT- (C1, C2, Graal JIT Compiler), (Serial, Parallel, CMS, G1, Shenandoah, ZGC) serviceability, .
2. JDK
— jdeps JLINK. . Java (JDeps). - Java, . . JAR, , . JDeps JDK, Java-. , , .
jdeps , java.base. jlink. , BellSoft Docker- java.base. DockerHub, .
docker run –rm bellsoft/liberica – openjdk -demos- asciiduke.
CLI-like java.base. Liberica JDK Lite Alpine Linux musl 40,4 .
.
Enjoy!