Sugeng rawuh, Habr! Aku ngaturake kanggo manungsa waé terjemahan penulis artikel .
Ing wektu nalika jagad IT saya maju menyang layanan mikro lan alat kaya Kubernetes, mung siji masalah sing saya tambah katon. Masalah iki - versi microservice. Isih, komunitas IT percaya yen kahanan saiki luwih apik tinimbang generasi sadurunge teknologi. Nanging, versi microservice minangka masalah sing rumit banget. Siji bukti iki bisa dadi artikel kaya .
Yen sampeyan isih ora ngerti masalah kanthi maca teks iki, aku bakal nerangake. Contone, produk sampeyan kalebu 10 layanan mikro. Saiki ayo nganggep yen 1 versi anyar dirilis kanggo saben layanan mikro kasebut. Mung 1 versi - Muga-muga kita kabeh bisa setuju yen iki minangka kasunyatan sing ora pati penting lan ora pati penting. Nanging, saiki ayo goleki maneh produk kita. Kanthi mung siji versi anyar saka saben komponen, kita saiki duwe 2^10 - utawa 1024 permutasi babagan carane produk kita bisa disusun.
Yen isih ana kesalahpahaman, sumangga kula mecahaken matematika. Dadi, kita duwe 10 layanan mikro, saben nampa siji nganyari. Yaiku, kita entuk 2 versi sing bisa ditindakake kanggo saben layanan mikro (lawas utawa anyar). Saiki, kanggo saben komponen produk, kita bisa nggunakake salah siji saka rong versi kasebut. Secara matematis, padha karo yen kita duwe nomer biner 10 digit. Contone, ayo ngomong yen 1 minangka versi anyar, lan 0 minangka versi lawas - banjur siji permutasi bisa dituduhake minangka 1001000000 - ing ngendi komponen 1 lan 4 dianyari, lan kabeh liyane ora. Saka matématika kita ngerti yèn angka biner 10 digit bisa duwé 2^10 utawa 1024 nilai. Yaiku, kita wis ngonfirmasi ukuran nomer sing kita tindakake.
Ayo nerusake pertimbangan kita - apa sing bakal kelakon yen kita duwe 100 microservices lan saben duwe 10 versi bisa? Kahanan kabeh dadi ora nyenengake - saiki kita duwe 10^100 permutasi - sing nomer akeh. Nanging, aku luwih seneng menehi label kahanan iki kanthi cara iki, amarga saiki kita ora ndhelikake tembung kaya "kubernetes", nanging ngadhepi masalah kaya saiki.
Yagene aku kepincut banget karo masalah iki? Sebagéyan amarga, sadurunge kerja ing jagad NLP lan AI, kita ngrembug masalah bledosan kombinasi udakara 5-6 taun kepungkur. Mung tinimbang versi kita duwe tembung individu, lan tinimbang produk kita duwe ukara lan paragraf. Lan sanajan masalah NLP lan AI tetep ora bisa dirampungake, kudu diakoni manawa kemajuan sing signifikan wis ditindakake sajrone sawetara taun kepungkur. (Miturut pendapatku, kemajuan bisa ditindakakeоIku bakal luwih apik yen wong ing industri mbayar sethitik kurang manungsa waé kanggo machine learning lan sethitik liyane kanggo Techniques liyane - nanging iki wis off-topik).
Ayo bali menyang jagad DevOps lan layanan mikro. Kita ngadhepi masalah gedhe, nyamar dadi gajah ing Kunstkamera - amarga sing asring dakrungu yaiku "mung njupuk kubernetes lan setir, lan kabeh bakal apik!" Nanging ora, kabeh ora bakal apik yen kabeh ditinggalake. Kajaba iku, solusi analitis kanggo masalah iki katon ora bisa ditampa amarga kerumitan. Kaya ing NLP, kita kudu nyedhaki masalah iki kanthi nyepetake ruang lingkup telusuran-ing kasus iki, kanthi ngilangi permutasi sing wis lawas.
Salah sawijining perkara sing bisa mbantu yaiku sing daktulis taun kepungkur . Sampeyan uga penting kanggo dicathet yen proses CI / CD sing dirancang kanthi apik mbantu nyuda variasi. Nanging, kahanan saiki karo CI / CD ora cukup apik kanggo ngatasi masalah permutasi tanpa alat tambahan kanggo komponen akuntansi lan nelusuri.
Apa sing kita butuhake yaiku sistem eksperimen ing tahap integrasi, ing ngendi kita bisa nemtokake faktor risiko kanggo saben komponen, lan uga duwe proses otomatis kanggo nganyari macem-macem komponen lan tes tanpa intervensi operator - kanggo ndeleng apa sing bisa digunakake lan ora.
Sistem eksperimen kasebut bisa katon kaya iki:
- Pangembang nulis tes (iki minangka tahap kritis - amarga yen ora, kita ora duwe kriteria evaluasi - kaya data label ing pembelajaran mesin).
- Saben komponen (proyek) nampa sistem CI dhewe - proses iki saiki wis dikembangake kanthi apik, lan masalah nggawe sistem CI kanggo komponen siji wis dirampungake.
- "Sistem integrasi cerdas" nglumpukake asil saka macem-macem sistem CI lan nglumpukake proyek komponen menyang produk pungkasan, mbukak testing lan pungkasanipun ngetung dalan paling cendhak kanggo entuk fungsi produk dikarepake adhedhasar komponen ana lan faktor risiko. Yen nganyari ora bisa ditindakake, sistem iki menehi kabar marang pangembang babagan komponen sing wis ana lan sapa wae sing nyebabake kesalahan. Sawise maneh, sistem tes penting banget ing kene - amarga sistem integrasi nggunakake tes minangka kriteria evaluasi.
- Sistem CD, sing banjur nampa data saka Sistem Integrasi Smart lan nindakake nganyari langsung. Tahap iki mungkasi siklus.
Kanggo ngringkes, kanggo kula, salah sawijining masalah paling gedhe saiki yaiku kekurangan "Sistem Integrasi Cerdas" sing bakal ngubungake macem-macem komponen menyang produk lan kanthi mangkono ngidini sampeyan nglacak carane produk kasebut digabungake. Aku bakal kasengsem karo pikirane masyarakat babagan iki (spoiler - aku lagi nggarap proyek , sing bisa dadi sistem integrasi sing cerdas).
Siji bab pungkasan aku arep kanggo sebutno iku, kanggo kula, monolith ora ditrima kanggo sembarang project malah ukuran medium. Kanggo kula, upaya kanggo nyepetake wektu implementasine lan kualitas pembangunan kanthi bali menyang monolit nyebabake skeptisisme gedhe. Kaping pisanan, monolith duwe masalah sing padha kanggo ngatur komponen - ing antarane macem-macem perpustakaan sing kalebu, nanging kabeh iki ora katon lan katon utamane ing wektu sing ditindakake dening pangembang. Konsekuensi saka masalah monolith yaiku impossibility virtual kanggo nggawe owah-owahan ing kode - lan kacepetan pembangunan arang banget alon.
Microservices nambah kahanan, nanging banjur arsitektur microservice ngadhepi masalah bledosan combinatorial ing tataran integrasi. Ya, umume, kita wis mindhah masalah sing padha saka tahap pangembangan menyang tahap integrasi. Nanging, mratelakake panemume, pendekatan microservices isih ndadékaké asil sing luwih apik, lan tim entuk asil luwih cepet (mbokmenawa utamane amarga nyuda ukuran unit pangembangan - utawa ukuran batch). Nanging, obah saka monolith kanggo microservices durung nambah proses cukup - bledosan combinatorial saka versi microservice masalah ageng, lan kita duwe akèh potensial kanggo nambah kahanan nalika kita ngatasi.
Source: www.habr.com