Microservices - letupan gabungan versi

Hello, Habr! Saya sampaikan untuk perhatian anda terjemahan penulis artikel Microservices – Letupan Kombinatorial Versi.

Pada masa dunia IT secara beransur-ansur bergerak ke arah perkhidmatan mikro dan alatan seperti Kubernetes, hanya satu masalah yang semakin ketara. Masalah ini - letupan gabungan versi perkhidmatan mikro. Namun, komuniti IT percaya bahawa keadaan semasa adalah lebih baik daripada "Neraka pergantungan" teknologi generasi terdahulu. Walau bagaimanapun, perkhidmatan mikro versi adalah masalah yang sangat kompleks. Satu bukti ini boleh jadi artikel seperti "Kembalikan monolit saya".

Jika anda masih tidak memahami masalah dengan membaca teks ini, izinkan saya menerangkan. Katakan produk anda terdiri daripada 10 perkhidmatan mikro. Sekarang mari kita anggap bahawa 1 versi baharu dikeluarkan untuk setiap perkhidmatan mikro ini. Hanya 1 versi - Saya harap kita semua boleh bersetuju bahawa ini adalah fakta yang sangat remeh dan tidak penting. Sekarang, bagaimanapun, mari kita lihat sekali lagi pada produk kami. Dengan hanya satu versi baharu setiap komponen, kami kini mempunyai pilih atur 2^10 - atau 1024 tentang cara produk kami boleh digubah.

Jika masih ada salah faham, izinkan saya memecahkan matematik. Jadi kami mempunyai 10 perkhidmatan mikro, setiap satu menerima satu kemas kini. Iaitu, kami mendapat 2 versi yang mungkin untuk setiap perkhidmatan mikro (sama ada lama atau baharu). Kini, untuk setiap komponen produk, kita boleh menggunakan salah satu daripada dua versi ini. Secara matematik, ia adalah sama seperti jika kita mempunyai nombor binari 10 digit. Sebagai contoh, katakan bahawa 1 ialah versi baharu, dan 0 ialah versi lama - maka satu pilih atur yang mungkin boleh dilambangkan sebagai 1001000000 - di mana komponen pertama dan ke-1 dikemas kini, dan semua yang lain tidak. Daripada matematik kita tahu bahawa nombor perduaan 4 digit boleh mempunyai 10^2 atau 10 nilai. Maksudnya, kami telah mengesahkan skala nombor yang kami hadapi.

Mari kita teruskan lagi alasan kita - apakah yang akan berlaku jika kita mempunyai 100 perkhidmatan mikro dan setiap satu mempunyai 10 versi yang mungkin? Keseluruhan keadaan menjadi agak tidak menyenangkan - kita kini mempunyai 10^100 pilihatur - yang merupakan jumlah yang besar. Namun, saya lebih suka melabelkan situasi ini dengan cara ini, kerana kini kita tidak lagi berselindung di sebalik kata-kata seperti “kubernetes”, sebaliknya berhadapan dengan masalah yang ada.

Mengapa saya begitu terpesona dengan masalah ini? Sebahagiannya kerana, setelah bekerja di dunia NLP dan AI sebelum ini, kami banyak membincangkan masalah letupan gabungan kira-kira 5-6 tahun yang lalu. Hanya daripada versi kami mempunyai perkataan individu, dan bukannya produk kami mempunyai ayat dan perenggan. Dan walaupun masalah NLP dan AI sebahagian besarnya masih belum dapat diselesaikan, harus diakui bahawa kemajuan ketara telah dicapai sejak beberapa tahun kebelakangan ini. (pada pendapat saya, kemajuan boleh dibuatоAdalah lebih baik jika orang dalam industri kurang memberi perhatian kepada pembelajaran mesin dan lebih sedikit kepada teknik lain - tetapi ini sudah di luar topik).

Mari kembali ke dunia DevOps dan perkhidmatan mikro. Kami berhadapan dengan masalah besar, menyamar sebagai gajah di Kunstkamera - kerana apa yang sering saya dengar ialah "ambil sahaja kubernetes dan helm, dan semuanya akan baik-baik saja!" Tetapi tidak, semuanya tidak akan baik jika semuanya dibiarkan begitu sahaja. Selain itu, penyelesaian analitikal untuk masalah ini nampaknya tidak boleh diterima kerana kerumitannya. Seperti dalam NLP, kita harus terlebih dahulu mendekati masalah ini dengan mengecilkan skop carian—dalam kes ini, dengan menghapuskan pilih atur yang sudah lapuk.

Salah satu perkara yang mungkin membantu ialah sesuatu yang saya tulis tahun lepas tentang keperluan untuk mengekalkan perbezaan minimum antara versi yang disiarkan untuk pelanggan. Ia juga penting untuk ambil perhatian bahawa proses CI/CD yang direka dengan baik sangat membantu dalam mengurangkan variasi. Walau bagaimanapun, keadaan semasa dengan CI/CD tidak cukup baik untuk menyelesaikan masalah pilih atur tanpa alat tambahan untuk komponen perakaunan dan pengesanan.

Apa yang kita perlukan ialah sistem percubaan pada peringkat integrasi, di mana kita boleh menentukan faktor risiko bagi setiap komponen, dan juga mempunyai proses automatik untuk mengemas kini pelbagai komponen dan ujian tanpa campur tangan pengendali - untuk melihat apa yang berkesan dan apa yang tidak.

Sistem eksperimen sedemikian boleh kelihatan seperti ini:

1. Pembangun menulis ujian (ini adalah peringkat kritikal - kerana jika tidak, kami tidak mempunyai kriteria penilaian - ia seperti melabelkan data dalam pembelajaran mesin).
2. Setiap komponen (projek) menerima sistem CI sendiri - proses ini kini telah dibangunkan dengan baik, dan isu mewujudkan sistem CI untuk satu komponen telah banyak diselesaikan
3. "Sistem integrasi pintar" mengumpul hasil pelbagai sistem CI dan memasang projek komponen ke dalam produk akhir, menjalankan ujian dan akhirnya mengira laluan terpendek untuk mendapatkan kefungsian produk yang diingini berdasarkan komponen sedia ada dan faktor risiko. Jika kemas kini tidak dapat dilakukan, sistem ini memberitahu pembangun tentang komponen sedia ada dan yang mana antaranya menyebabkan ralat. Sekali lagi, sistem ujian adalah sangat penting di sini - kerana sistem penyepaduan menggunakan ujian sebagai kriteria penilaian.
4. Sistem CD, yang kemudiannya menerima data daripada Sistem Integrasi Pintar dan melakukan kemas kini secara langsung. Peringkat ini menamatkan kitaran.

Untuk meringkaskan, bagi saya salah satu masalah terbesar sekarang ialah kekurangan "Sistem Integrasi Pintar" yang akan menghubungkan pelbagai komponen ke dalam produk dan dengan itu membolehkan anda menjejaki bagaimana produk secara keseluruhannya disatukan. Saya akan berminat dengan pemikiran komuniti mengenai perkara ini (spoiler - saya sedang mengusahakan projek Reliza, yang boleh menjadi sistem integrasi pintar).

Satu perkara terakhir yang saya ingin nyatakan ialah, pada saya, monolit tidak boleh diterima untuk mana-mana projek walaupun saiz sederhana. Bagi saya, percubaan untuk mempercepatkan masa pelaksanaan dan kualiti pembangunan dengan kembali kepada monolit menyebabkan keraguan yang besar. Pertama, monolit mempunyai masalah yang sama dalam mengurus komponen - di antara pelbagai perpustakaan yang terdiri daripadanya, bagaimanapun, semua ini tidak begitu ketara dan memanifestasikan dirinya terutamanya dalam masa yang dihabiskan oleh pemaju. Akibat daripada masalah monolit adalah kemustahilan maya untuk membuat perubahan pada kod - dan kelajuan pembangunan yang sangat perlahan.

Perkhidmatan mikro memperbaiki keadaan, tetapi kemudian seni bina perkhidmatan mikro menghadapi masalah letupan gabungan pada peringkat penyepaduan. Ya, secara umum, kami telah memindahkan masalah yang sama dari peringkat pembangunan ke peringkat integrasi. Walau bagaimanapun, pada pendapat saya, pendekatan perkhidmatan mikro masih membawa kepada hasil yang lebih baik, dan pasukan mencapai keputusan dengan lebih cepat (mungkin terutamanya disebabkan oleh pengurangan dalam saiz unit pembangunan - atau saiz kumpulan). Walau bagaimanapun, beralih daripada monolit kepada perkhidmatan mikro masih belum cukup meningkatkan proses - letupan gabungan versi perkhidmatan mikro adalah masalah besar, dan kami mempunyai banyak potensi untuk memperbaiki keadaan semasa kami menyelesaikannya.

Sumber: www.habr.com