Halo, Habr! Kuring nampilkeun ka perhatian Anjeun tarjamahan panulis artikel .
Dina waktos dunya IT laun-laun nuju kana jasa mikro sareng alat sapertos Kubernetes, ngan ukur hiji masalah anu janten langkung nyata. Masalah ieu- versi microservice. Masih, komunitas IT percaya yén kaayaan ayeuna langkung saé tibatan generasi saméméhna tina téhnologi. Sanajan kitu, versioning microservices masalah pisan kompléks. Hiji bukti ieu tiasa artikel kawas .
Upami anjeun masih teu ngartos masalahna ku maca téks ieu, hayu atuh ngajelaskeun. Anggap produk anjeun diwangun ku 10 microservices. Ayeuna hayu urang nganggap yén 1 versi anyar dileupaskeun pikeun tiap microservices ieu. Ngan 1 versi - Abdi ngarepkeun urang sadayana tiasa satuju yén ieu mangrupikeun kanyataan anu teu pati penting sareng teu penting. Ayeuna, kumaha oge, hayu urang tingali deui produk urang. Kalayan ngan hiji versi anyar unggal komponén, urang ayeuna gaduh 2^10 - atanapi 1024 permutasi kumaha produk urang tiasa diwangun.
Mun aya kénéh salah paham, hayu atuh ngarecah math. Janten urang gaduh 10 microservices, masing-masing nampi hiji pembaruan. Hartina, urang meunang 2 versi mungkin pikeun tiap microservice (boh heubeul atawa anyar). Ayeuna, pikeun tiap komponén produk, urang tiasa nganggo salah sahiji dua vérsi ieu. Sacara matematis, éta sami sareng upami urang ngagaduhan angka binér 10 digit. Contona, hayu urang nyebutkeun yén 1 nyaéta versi anyar, sarta 0 nyaéta versi heubeul - lajeng hiji mungkin permutation bisa dilambangkeun salaku 1001000000 - dimana 1st jeung 4 komponén diropéa, sarta sakabeh séjén henteu. Tina matematika urang terang yén angka binér 10-angka tiasa gaduh 2^10 atanapi 1024 nilai. Nyaéta, kami parantos mastikeun skala jumlah anu kami urus.
Hayu urang teraskeun penalaran urang salajengna - naon anu bakal kajadian upami urang gaduh 100 microservices sareng masing-masing gaduh 10 versi anu mungkin? Sakabeh kaayaan janten rada teu pikaresepeun - urang ayeuna gaduh 10^100 permutations - nu jumlah badag. Najan kitu, kuring leuwih resep mun labél kaayaan ieu ku cara kieu, sabab ayeuna urang geus euweuh nyumput tukangeun kecap kawas "kubernetes", tapi rada nyanghareupan masalah sakumaha anu kasebut.
Naha kuring jadi fascinated ku masalah ieu? Sabagean kusabab, saatos damel di dunya NLP sareng AI, urang bahas masalah ledakan kombinatorial ngeunaan 5-6 taun ka pengker. Ngan tinimbang versi urang tadi kecap individu, jeung tinimbang produk urang tadi kalimat jeung paragraf. Sareng sanaos masalah NLP sareng AI tetep umumna teu kaungkab, kedah diaku yén kamajuan anu signifikan parantos dilakukeun dina sababaraha taun katukang. (Dina pamanggih kuring, kamajuan tiasa dilakukeunоÉta langkung saé upami jalma-jalma di industri kirang nengetan kana pembelajaran mesin sareng sakedik deui kana téknik sanés - tapi ieu parantos kaluar tina topik).
Hayu urang uih deui ka dunya DevOps sareng microservices. Kami disanghareupan ku masalah anu ageung, nyamar salaku gajah di Kunstkamera - sabab anu sering kuring kadéngé nyaéta "ngan ukur nyandak kubernetes sareng helm, sareng sadayana bakal beres!" Tapi henteu, sadayana moal kunanaon upami sadayana diantep. Leuwih ti éta, hiji solusi analitik pikeun masalah ieu sigana teu bisa ditarima alatan pajeulitna na. Sapertos dina NLP, urang kedah ngadeukeutan masalah ieu ku cara ngahususkeun wengkuan pamilarian-dina hal ieu, ku ngaleungitkeun permutations luntur.
Salah sahiji hal anu tiasa ngabantosan nyaéta anu kuring nyerat taun ka tukang . Éta ogé penting pikeun dicatet yén prosés CI/CD anu dirancang kalayan saé ngabantosan ngirangan variasi. Sanajan kitu, kaayaan kiwari urusan kalawan CI / CD teu cukup alus pikeun ngajawab masalah permutations tanpa parabot tambahan pikeun akuntansi jeung tracking komponén.
Anu urang peryogikeun nyaéta sistem ékspérimén dina tahap integrasi, dimana urang tiasa nangtoskeun faktor résiko pikeun unggal komponén, sareng ogé gaduh prosés otomatis pikeun ngapdet sababaraha komponén sareng uji tanpa campur tangan operator - pikeun ningali naon anu tiasa dianggo sareng naon anu henteu.
Sistem percobaan sapertos kieu tiasa sapertos kieu:
- Pamekar nyerat tés (ieu mangrupikeun tahap kritis - sabab upami teu aya kriteria evaluasi - éta sapertos panyiri data dina pembelajaran mesin).
- Masing-masing komponén (proyék) nampi sistem CI sorangan - prosés ieu ayeuna parantos dikembangkeun, sareng masalah nyiptakeun sistem CI pikeun komponén tunggal parantos direngsekeun.
- "Sistem integrasi pinter" ngumpulkeun hasil rupa sistem CI jeung assembles proyék komponén kana produk ahir, ngajalankeun nguji sarta tungtungna ngitung jalur shortest pikeun ménta fungsionalitas produk dipikahoyong dumasar kana komponén aya jeung faktor résiko. Upami apdet teu mungkin, sistem ieu ngawartosan pamekar ngeunaan komponén anu aya sareng anu mana anu nyababkeun kasalahan. Sakali deui, sistem tés penting pisan di dieu - sabab sistem integrasi ngagunakeun tés salaku kriteria évaluasi.
- Sistem CD, anu teras nampi data tina Sistem Integrasi Smart sareng ngalaksanakeun apdet sacara langsung. Tahap ieu mungkas siklus.
Pikeun nyimpulkeun, pikeun kuring salah sahiji masalah pangbadagna ayeuna nyaéta kurangna sapertos "Smart Integration System" nu bakal numbu rupa komponén kana produk sahingga ngidinan Anjeun pikeun ngalacak kumaha produk sakabéhna nunda babarengan. Kuring bakal kabetot dina pamikiran masarakat ngeunaan ieu (spoiler - Kuring ayeuna nuju damel dina proyék , anu tiasa janten sistem integrasi pinter sapertos kitu).
Hiji hal anu terakhir anu kuring hoyong disebatkeun nyaéta, pikeun kuring, monolith henteu tiasa ditampi pikeun proyék naon waé anu ukuranana sedeng. Pikeun kuring, usaha pikeun nyepetkeun waktos palaksanaan sareng kualitas pangwangunan ku uih deui ka monolith nyababkeun skeptisisme anu hébat. Anu mimiti, monolith ngagaduhan masalah anu sami dina ngatur komponén - diantara rupa-rupa perpustakaan anu diwangun ku, kumaha ogé, sadayana ieu henteu katingali sareng diwujudkeun utamina dina waktos anu dihabiskeun ku pamekar. Konsékuansi tina masalah monolith nyaeta impossibility maya nyieun parobahan kode - sarta laju ngembangkeun pisan slow.
Microservices ningkatkeun kaayaan, tapi teras arsitéktur microservice nyanghareupan masalah ledakan combinatorial dina tahap integrasi. Leres, sacara umum, kami parantos ngalihkeun masalah anu sami tina tahap pamekaran ka tahap integrasi. Nanging, dina pamanggih kuring, pendekatan microservices masih ngakibatkeun hasil anu langkung saé, sareng tim ngahontal hasil langkung gancang (panginten utamina kusabab pangurangan ukuran unit pangembangan - atanapi ukuran bets). Nanging, pindah tina monolith ka microservices henteu acan ningkatkeun prosésna - ledakan gabungan tina versi microservice mangrupikeun masalah anu ageung, sareng kami ngagaduhan poténsial pikeun ningkatkeun kaayaan nalika urang ngabéréskeunana.
sumber: www.habr.com