Habari, Habr! Ninawasilisha kwa mawazo yako tafsiri ya mwandishi wa makala hiyo .
Wakati ambapo ulimwengu wa TEHAMA unaelekea hatua kwa hatua kuelekea huduma ndogo ndogo na zana kama vile Kubernetes, ni tatizo moja tu ambalo linaonekana zaidi na zaidi. Tatizo hili - matoleo ya microservice. Bado, jumuiya ya IT inaamini kuwa hali ya sasa ni bora zaidi kuliko kizazi cha awali cha teknolojia. Walakini, toleo la huduma ndogo ni shida ngumu sana. Uthibitisho mmoja wa hii unaweza kuwa nakala kama .
Ikiwa bado hauelewi shida kwa kusoma maandishi haya, wacha nikuelezee. Wacha tuseme bidhaa yako ina huduma ndogo 10. Sasa hebu tufikirie kuwa toleo 1 jipya limetolewa kwa kila moja ya huduma hizi ndogo. Toleo 1 pekee - natumai sote tunaweza kukubaliana kuwa huu ni ukweli mdogo na usio na maana. Sasa, hata hivyo, acheni tuangalie tena bidhaa zetu. Kwa toleo moja tu jipya la kila kijenzi, sasa tuna vibali 2^10 - au 1024 vya jinsi bidhaa zetu zinavyoweza kutungwa.
Ikiwa bado kuna kutokuelewana, wacha nichambue hesabu. Kwa hivyo tuna huduma ndogo 10, kila moja ikipokea sasisho moja. Hiyo ni, tunapata matoleo 2 yanayowezekana kwa kila huduma ndogo (ya zamani au mpya). Sasa, kwa kila sehemu ya bidhaa, tunaweza kutumia mojawapo ya matoleo haya mawili. Kihesabu, ni sawa na ikiwa tulikuwa na nambari ya binary ya tarakimu 10. Kwa mfano, hebu tuseme kwamba 1 ni toleo jipya, na 0 ni toleo la zamani - basi ruhusa moja inayowezekana inaweza kuonyeshwa kama 1001000000 - ambapo vipengele vya 1 na 4 vinasasishwa, na vingine vyote havijasasishwa. Kutoka kwa hisabati tunajua kwamba nambari ya binary yenye tarakimu 10 inaweza kuwa na thamani 2^10 au 1024. Hiyo ni, tumethibitisha ukubwa wa nambari tunayoshughulikia.
Wacha tuendelee mawazo yetu zaidi - nini kitatokea ikiwa tutakuwa na huduma ndogo 100 na kila moja ina matoleo 10 yanayowezekana? Hali nzima inakuwa mbaya kabisa - sasa tuna vibali 10^ 100 - ambayo ni idadi kubwa. Walakini, ninapendelea kuweka hali hii lebo kwa njia hii, kwa sababu sasa hatujifichi tena nyuma ya maneno kama "kubernetes", lakini tunakabiliwa na shida kama ilivyo.
Kwa nini ninavutiwa sana na tatizo hili? Kwa sehemu kwa sababu, baada ya kufanya kazi hapo awali katika ulimwengu wa NLP na AI, tulijadili shida ya mlipuko wa pamoja karibu miaka 5-6 iliyopita. Badala ya matoleo tu tulikuwa na maneno ya kibinafsi, na badala ya bidhaa tulikuwa na sentensi na aya. Na ingawa shida za NLP na AI bado hazijatatuliwa, ni lazima ikubalike kwamba maendeleo makubwa yamepatikana katika miaka michache iliyopita. (kwa maoni yangu, maendeleo yanaweza kupatikanaΠΎIngekuwa bora ikiwa watu katika tasnia watazingatia kidogo kujifunza kwa mashine na zaidi kidogo kwa mbinu zingine - lakini hii tayari iko nje ya mada).
Hebu turejee kwenye ulimwengu wa DevOps na huduma ndogo ndogo. Tunakabiliwa na shida kubwa, tukijifanya kama tembo katika Kunstkamera - kwa sababu kile ninachosikia mara nyingi ni "chukua tu kubernetes na usukani, na kila kitu kitakuwa sawa!" Lakini hapana, kila kitu hakitakuwa sawa ikiwa kila kitu kitaachwa kama kilivyo. Aidha, ufumbuzi wa uchambuzi wa tatizo hili hauonekani kukubalika kutokana na utata wake. Kama ilivyo katika NLP, tunapaswa kwanza kukabiliana na tatizo hili kwa kupunguza wigo wa utafutaji-katika kesi hii, kwa kuondoa vibali vilivyopitwa na wakati.
Moja ya mambo ambayo yanaweza kusaidia ni kitu nilichoandika mwaka jana . Pia ni muhimu kutambua kwamba mchakato wa CI/CD ulioundwa vizuri husaidia sana katika kupunguza tofauti. Hata hivyo, hali ya sasa ya CI/CD haitoshi kutatua tatizo la vibali bila zana za ziada za vipengele vya uhasibu na ufuatiliaji.
Tunachohitaji ni mfumo wa majaribio katika hatua ya ujumuishaji, ambapo tunaweza kuamua sababu ya hatari kwa kila sehemu, na pia kuwa na mchakato wa kiotomatiki wa kusasisha vipengele mbalimbali na kupima bila uingiliaji wa operator - ili kuona ni nini kinachofanya kazi na kisichofanya kazi.
Mfumo kama huo wa majaribio unaweza kuonekana kama hii:
- Wasanidi programu huandika majaribio (hii ni hatua muhimu - kwa sababu vinginevyo hatuna kigezo cha tathmini - ni kama kuweka lebo data katika kujifunza kwa mashine).
- Kila sehemu (mradi) hupokea mfumo wake wa CI - mchakato huu sasa umeandaliwa vizuri, na suala la kuunda mfumo wa CI kwa sehemu moja limetatuliwa kwa kiasi kikubwa.
- "Mfumo mzuri wa kuunganisha" hukusanya matokeo ya mifumo mbalimbali ya CI na kukusanya miradi ya vipengele kwenye bidhaa ya mwisho, huendesha majaribio na hatimaye huhesabu njia fupi zaidi ya kupata utendaji wa bidhaa unaohitajika kulingana na vipengele vilivyopo na vipengele vya hatari. Ikiwa sasisho haliwezekani, mfumo huu hujulisha wasanidi programu kuhusu vipengele vilivyopo na ni nani kati yao anayesababisha hitilafu. Kwa mara nyingine tena, mfumo wa majaribio ni wa umuhimu mkubwa hapa - kwa kuwa mfumo wa ujumuishaji hutumia majaribio kama kigezo cha tathmini.
- Mfumo wa CD, ambao hupokea data kutoka kwa Mfumo wa Ujumuishaji wa Smart na kufanya sasisho moja kwa moja. Hatua hii inamaliza mzunguko.
Kwa muhtasari, kwangu moja ya shida kubwa sasa ni ukosefu wa "Smart Integration System" ambayo inaweza kuunganisha vipengele mbalimbali kwenye bidhaa na hivyo kukuwezesha kufuatilia jinsi bidhaa kwa ujumla inavyounganishwa. Nitapendezwa na mawazo ya jamii juu ya hili (mharibifu - kwa sasa ninafanya kazi kwenye mradi , ambayo inaweza kuwa mfumo mzuri wa ujumuishaji).
Jambo la mwisho ninalotaka kutaja ni kwamba, kwangu, monolith haikubaliki kwa mradi wowote wa ukubwa wa kati. Kwa mimi, majaribio ya kuharakisha muda wa utekelezaji na ubora wa maendeleo kwa kurudi kwenye monolith husababisha mashaka makubwa. Kwanza, monolith ina shida sawa ya kusimamia vipengele - kati ya maktaba mbalimbali ambayo inajumuisha, hata hivyo, yote haya hayaonekani sana na yanajidhihirisha hasa katika wakati unaotumiwa na watengenezaji. Matokeo ya tatizo la monolith ni kutowezekana kwa kweli kwa kufanya mabadiliko kwenye msimbo - na kasi ya maendeleo ya polepole sana.
Huduma ndogo huboresha hali hiyo, lakini basi usanifu wa microservice unakabiliwa na tatizo la mlipuko wa combinatorial katika hatua ya ushirikiano. Ndiyo, kwa ujumla, tumehamisha tatizo sawa kutoka hatua ya maendeleo hadi hatua ya ushirikiano. Walakini, kwa maoni yangu, mbinu ya huduma ndogo bado husababisha matokeo bora, na timu zinapata matokeo haraka (labda haswa kwa sababu ya kupunguzwa kwa saizi ya kitengo cha ukuzaji - au ukubwa wa kundi) Walakini, kuhama kutoka kwa monolith hadi huduma ndogo bado haijaboresha mchakato wa kutosha - mlipuko wa pamoja wa matoleo ya huduma ndogo ni shida kubwa, na tuna uwezo mkubwa wa kuboresha hali tunaposuluhisha.
Chanzo: mapenzi.com