Umetumia miezi kuunda upya monolith yako kuwa huduma ndogo, na hatimaye kila mtu amekusanyika ili kugeuza swichi. Unaenda kwenye ukurasa wa kwanza wa wavuti ... na hakuna kinachotokea. Unapakia tena - na tena hakuna kitu kizuri, tovuti ni polepole sana kwamba haijibu kwa dakika kadhaa. Nini kimetokea?
Katika mazungumzo yake, Jimmy Bogard atafanya "post-mortem" juu ya maafa ya huduma ndogo ya maisha halisi. Ataonyesha matatizo ya uundaji, ukuzaji, na uzalishaji aliyogundua, na jinsi timu yake ilivyobadilisha polepole monolith mpya iliyosambazwa kuwa picha ya mwisho ya utimamu. Ingawa haiwezekani kuzuia kabisa makosa ya muundo, unaweza angalau kutambua matatizo mapema katika mchakato wa kubuni ili kuhakikisha kuwa bidhaa ya mwisho inakuwa mfumo wa kuaminika unaosambazwa.
Halo watu wote, mimi ni Jimmy na leo mtasikia jinsi unavyoweza kuepuka majanga makubwa wakati wa kujenga huduma ndogo. Hii ni hadithi ya kampuni niliyofanyia kazi kwa takriban mwaka mmoja na nusu ili kusaidia kuzuia meli yao kugongana na jiwe la barafu. Ili kusimulia hadithi hii ipasavyo, itabidi turudi nyuma na kuzungumzia mahali ambapo kampuni hii ilianzia na jinsi miundombinu yake ya TEHAMA ilivyokua kwa wakati. Ili kulinda majina ya wasio na hatia katika janga hili, nimebadilisha jina la kampuni hii kuwa Bell Computers. Slaidi inayofuata inaonyesha jinsi miundombinu ya IT ya kampuni kama hizo ilionekana katikati ya miaka ya 90. Huu ni usanifu wa kawaida wa seva kubwa ya HP Tandem Mainframe inayostahimili hitilafu kwa uendeshaji wa duka la vifaa vya kompyuta.
Walihitaji kuunda mfumo wa kudhibiti maagizo yote, mauzo, mapato, katalogi za bidhaa, na msingi wa wateja, kwa hivyo walichagua suluhisho la kawaida la mfumo mkuu wakati huo. Mfumo huu mkubwa ulikuwa na kila taarifa kidogo kuhusu kampuni, kila kitu kinachowezekana, na kila shughuli ilifanywa kupitia mfumo mkuu huu. Waliweka mayai yao yote kwenye kikapu kimoja na walidhani hiyo ni kawaida. Kitu pekee ambacho hakijajumuishwa hapa ni katalogi za agizo la barua na kuagiza kwa simu.
Baada ya muda, mfumo huo ukawa mkubwa na mkubwa, na kiasi kikubwa cha takataka kilikusanywa ndani yake. Pia, COBOL sio lugha inayoelezea zaidi ulimwenguni, kwa hivyo mfumo uliishia kuwa kipande kikubwa cha takataka. Kufikia 2000, waliona kuwa kampuni nyingi zilikuwa na tovuti ambazo kupitia hizo ziliendesha biashara zao zote, na wakaamua kuunda tovuti yao ya kwanza ya kibiashara ya dot-com.
Muundo wa awali ulionekana mzuri sana na ulijumuisha tovuti ya kiwango cha juu ya bell.com na idadi ya vikoa vidogo vya programu mahususi: catalog.bell.com, accounts.bell.com, orders.bell.com, search search.bell. com. Kila kikoa kilitumia mfumo wa ASP.Net 1.0 na hifadhidata zake, na zote zilizungumza na mfumo wa nyuma. Walakini, maagizo yote yaliendelea kushughulikiwa na kutekelezwa ndani ya mfumo mkuu mmoja, ambapo takataka zote zilibaki, lakini sehemu ya mbele ilikuwa tovuti tofauti zilizo na programu za kibinafsi na hifadhidata tofauti.
Kwa hivyo muundo wa mfumo ulionekana kwa utaratibu na wenye mantiki, lakini mfumo halisi ulikuwa kama inavyoonyeshwa kwenye slaidi inayofuata.
Vipengele vyote vilielekeza simu kwa kila mmoja, API zilizofikiwa, dll zilizopachikwa za watu wengine, na kadhalika. Mara nyingi ilitokea kwamba mifumo ya udhibiti wa toleo ingenyakua msimbo wa mtu mwingine, kuisukuma ndani ya mradi, na kisha kila kitu kitavunjika. MS SQL Server 2005 ilitumia dhana ya seva za kiunganishi, na ingawa sikuonyesha mishale kwenye slaidi, kila hifadhidata pia ilizungumza kwa kila mmoja, kwa sababu hakuna chochote kibaya na kujenga meza kulingana na data iliyopatikana kutoka kwa hifadhidata kadhaa.
Kwa kuwa sasa walikuwa na utengano kati ya maeneo tofauti ya kimantiki ya mfumo, hii ikawa matone ya uchafu yaliyosambazwa, na kipande kikubwa zaidi cha taka kikiwa bado kimesalia kwenye mandharinyuma ya mfumo mkuu.
Jambo la kufurahisha ni kwamba mfumo mkuu huu ulijengwa na washindani wa Bell Computers na bado ulidumishwa na washauri wao wa kiufundi. Kwa kushawishika na utendaji usioridhisha wa maombi yake, kampuni iliamua kuwaondoa na kuunda upya mfumo.
Programu iliyopo imekuwa katika uzalishaji kwa miaka 15, ambayo ni rekodi ya programu zinazotegemea ASP.Net. Huduma ilikubali maagizo kutoka kote ulimwenguni, na mapato ya kila mwaka kutoka kwa programu hii moja yalifikia dola bilioni. Sehemu kubwa ya faida ilitolewa na tovuti ya bell.com. Siku ya Ijumaa Nyeusi, idadi ya maagizo yaliyowekwa kupitia tovuti ilifikia milioni kadhaa. Hata hivyo, usanifu uliopo haukuruhusu maendeleo yoyote, kwa kuwa uunganisho mkali wa vipengele vya mfumo haukuruhusu mabadiliko yoyote kufanywa kwa huduma.
Shida kubwa zaidi ilikuwa kutokuwa na uwezo wa kuweka agizo kutoka nchi moja, kulipia kwa nchi nyingine na kutuma kwa tatu, licha ya ukweli kwamba mpango kama huo wa biashara ni wa kawaida sana katika kampuni za kimataifa. Tovuti iliyopo haikuruhusu kitu kama hiki, kwa hivyo ilibidi wakubali na kuweka maagizo haya kupitia simu. Hii ilisababisha kampuni kuzidi kufikiria juu ya kubadilisha usanifu, haswa juu ya kubadili huduma ndogo.
Walifanya jambo la busara kwa kuangalia kampuni zingine kuona jinsi walivyotatua shida kama hiyo. Mojawapo ya suluhisho hizi ilikuwa usanifu wa huduma ya Netflix, ambayo ina huduma ndogo zilizounganishwa kupitia API na hifadhidata ya nje.
Usimamizi wa Kompyuta za Bell uliamua kujenga usanifu kama huo, kwa kuzingatia kanuni fulani za msingi. Kwanza, waliondoa kurudiwa kwa data kwa kutumia mbinu ya hifadhidata iliyoshirikiwa. Hakuna data iliyotumwa; kinyume chake, kila mtu aliyehitaji ilibidi aende kwa chanzo kikuu. Hii ilifuatiwa na kutengwa na uhuru - kila huduma ilikuwa huru ya wengine. Waliamua kutumia API ya Wavuti kwa kila kitu kabisa - ikiwa ungetaka kupata data au kufanya mabadiliko kwenye mfumo mwingine, yote yalifanywa kupitia API ya Wavuti. Jambo kuu la mwisho lilikuwa mfumo mkuu mpya unaoitwa "Bell on Bell" kinyume na mfumo mkuu wa "Bell" kulingana na maunzi ya washindani.
Kwa hiyo, kwa muda wa miezi 18, walijenga mfumo karibu na kanuni hizi za msingi na kuuleta kabla ya uzalishaji. Kurudi kazini baada ya wikendi, watengenezaji walikusanyika na kuwasha seva zote ambazo mfumo mpya uliunganishwa. Miezi 18 ya kazi, mamia ya watengenezaji, vifaa vya kisasa vya Bell - na hakuna matokeo mazuri! Hii imekatisha tamaa watu wengi kwa sababu wameendesha mfumo huu kwenye kompyuta zao za mkononi mara nyingi na kila kitu kilikuwa sawa.
Walikuwa smart kutupa fedha zao zote katika kutatua tatizo hili. Waliweka rafu za kisasa zaidi za seva na swichi, walitumia nyuzi za macho za gigabit, vifaa vya seva vyenye nguvu zaidi na kiasi cha wazimu cha RAM, waliunganisha yote, wakaisanidi - na tena, hakuna chochote! Kisha wakaanza kushuku kuwa sababu inaweza kuwa ya muda, kwa hivyo waliingia kwenye mipangilio yote ya wavuti, mipangilio yote ya API na kusasisha usanidi wote wa kuisha kwa viwango vya juu, ili wote wangeweza kufanya ni kukaa na kungojea kitu kifanyike. kwa tovuti. Walingoja na kungoja na kungoja kwa dakika 9 na nusu hadi tovuti ilipopakia.
Baada ya hapo, ikawajia kwamba hali ya sasa inahitaji uchambuzi wa kina, na wakatualika. Jambo la kwanza tulilogundua ni kwamba wakati wa miezi 18 ya maendeleo, hakuna hata "ndogo" moja halisi iliundwa - kila kitu kilikuwa kikubwa zaidi. Baada ya hayo, tulianza kuandika uchunguzi wa maiti, unaojulikana pia kama "regretrospective", au "sad retrospective", pia inajulikana kama "dhoruba ya lawama", sawa na "dhoruba ya ubongo", ili kuelewa sababu ya maafa.
Tulikuwa na dalili kadhaa, mojawapo ikiwa ni ujazo kamili wa trafiki wakati wa simu ya API. Unapotumia usanifu wa huduma ya monolithic, unaweza kuelewa mara moja ni nini kilienda vibaya kwa sababu una ufuatiliaji wa stack moja ambayo inaripoti kila kitu ambacho kingeweza kusababisha kushindwa. Katika kesi ambapo rundo la huduma hupata API sawa wakati huo huo, hakuna njia ya kufuatilia ufuatiliaji isipokuwa kutumia zana za ziada za ufuatiliaji wa mtandao kama WireShark, shukrani ambayo unaweza kuchunguza ombi moja na kujua nini kilifanyika wakati wa utekelezaji wake. Kwa hivyo tulichukua ukurasa mmoja wa wavuti na tukatumia karibu wiki 2 kuweka vipande vya fumbo pamoja, tukipiga simu kwa aina mbalimbali na kuchanganua kile ambacho kila kimoja kilisababisha.
Tazama picha hii. Inaonyesha kuwa ombi moja la nje huihimiza huduma kupiga simu nyingi za ndani zinazorudi. Inabadilika kuwa kila simu ya ndani hufanya humle za ziada ili kuweza kuhudumia ombi hili kwa kujitegemea, kwa sababu haiwezi kugeuka popote pengine ili kupata taarifa muhimu. Picha hii inaonekana kama mtiririko usio na maana wa simu, kwani ombi la nje huita huduma za ziada, ambazo huita huduma zingine za ziada, na kadhalika, karibu ad infinitum.
Rangi ya kijani kwenye mchoro huu inaonyesha nusu duara ambayo huduma huitana - huduma A huduma ya simu B, huduma B huita huduma C, na inaita huduma A tena. Ombi moja liliunda simu elfu za API za mtandao, na kwa kuwa mfumo haukuwa na uvumilivu wa hitilafu na ulinzi wa kitanzi, ombi hilo lingeshindwa ikiwa hata moja ya simu hizi za API itashindwa.
Tulifanya hesabu. Kila simu ya API ilikuwa na SLA ya si zaidi ya 150 ms na 99,9%. Ombi moja lilisababisha simu 200 tofauti, na katika hali bora zaidi, ukurasa unaweza kuonyeshwa kwa 200 x 150 ms = 30 sekunde. Kwa kawaida, hii haikuwa nzuri. Kwa kuzidisha muda wa nyongeza wa 99,9% na 200, tulipata upatikanaji wa 0%. Inabadilika kuwa usanifu huu ulihukumiwa kushindwa tangu mwanzo.
Tuliwauliza watengenezaji jinsi walivyoshindwa kutambua tatizo hili baada ya miezi 18 ya kazi? Ilibadilika kuwa walihesabu tu SLA kwa nambari waliyoendesha, lakini ikiwa huduma yao iliita huduma nyingine, hawakuhesabu wakati huo katika SLA yao. Kila kitu kilichozinduliwa ndani ya mchakato mmoja kilizingatia thamani ya 150 ms, lakini upatikanaji wa michakato mingine ya huduma iliongeza ucheleweshaji wa jumla mara nyingi zaidi. Somo la kwanza lililopatikana lilikuwa: "Je, unadhibiti SLA yako, au SLA inakudhibiti?" Kwa upande wetu, ilikuwa ya mwisho.
Jambo lililofuata tulilogundua ni kwamba walijua kuhusu dhana ya imani potofu za kompyuta iliyosambazwa, iliyotungwa na Peter Deitch na James Gosling, lakini walipuuza sehemu yake ya kwanza. Inasema kwamba kauli "mtandao ni wa kutegemewa," "kukawia sifuri," na "upitishaji usio na kikomo" ni maoni potofu. Dhana nyingine potofu ni pamoja na kauli "mtandao uko salama," "topolojia haibadiliki," "kila mara kuna msimamizi mmoja," "gharama ya uhamishaji data ni sifuri," na "mtandao ni sawa."
Walifanya makosa kwa sababu walijaribu huduma zao kwenye mashine za ndani na hawakuwahi kushikamana na huduma za nje. Wakati wa kukuza ndani na kutumia kache ya ndani, hawakuwahi kukutana na mihogo ya mtandao. Katika miezi yote 18 ya maendeleo, hawakuwahi kujiuliza hata mara moja nini kinaweza kutokea ikiwa huduma za nje zingeathiriwa.
Ikiwa unatazama mipaka ya huduma kwenye picha ya awali, unaweza kuona kwamba wote si sahihi. Kuna vyanzo vingi vinavyoshauri jinsi ya kufafanua mipaka ya huduma, na wengi hufanya vibaya, kama Microsoft kwenye slaidi inayofuata.
Picha hii ni kutoka kwa blogi ya MS kwenye mada "Jinsi ya kuunda huduma ndogo". Hii inaonyesha programu rahisi ya wavuti, kizuizi cha mantiki ya biashara, na hifadhidata. Ombi linakuja moja kwa moja, labda kuna seva moja ya wavuti, seva moja ya biashara na moja ya hifadhidata. Ikiwa unaongeza trafiki, picha itabadilika kidogo.
Inakuja kusawazisha mzigo ili kusambaza trafiki kati ya seva mbili za wavuti, akiba iliyo kati ya huduma ya wavuti na mantiki ya biashara, na kashe nyingine kati ya mantiki ya biashara na hifadhidata. Huu ndio usanifu kamili wa Bell uliotumiwa kusawazisha upakiaji wake na programu ya uwekaji ya samawati/kijani katikati ya miaka ya 2000. Hadi wakati fulani kila kitu kilifanya kazi vizuri, kwani mpango huu ulikuwa na lengo la muundo wa monolithic.
Picha ifuatayo inaonyesha jinsi MS inapendekeza kuhama kutoka monolith hadi microservices - tu kugawanya kila moja ya huduma kuu katika huduma ndogo tofauti. Ilikuwa wakati wa utekelezaji wa mpango huu ambapo Bell alifanya makosa.
Waligawanya huduma zao zote katika viwango tofauti, ambayo kila moja ilikuwa na huduma nyingi za kibinafsi. Kwa mfano, huduma ya wavuti ilijumuisha huduma ndogo za utoaji na uthibitishaji wa maudhui, huduma ya mantiki ya biashara ilijumuisha huduma ndogo za usindikaji maagizo na maelezo ya akaunti, hifadhidata iligawanywa katika kundi la huduma ndogo zilizo na data maalum. Wavuti, mantiki ya biashara, na hifadhidata zote mbili zilikuwa huduma zisizo na uraia.
Hata hivyo, picha hii haikuwa sahihi kabisa kwa sababu haikupanga vitengo vyovyote vya biashara nje ya kundi la IT la kampuni. Mpango huu haukuzingatia uhusiano wowote na ulimwengu wa nje, kwa hiyo haikuwa wazi jinsi, kwa mfano, kupata uchambuzi wa biashara ya tatu. Ninakumbuka kuwa walikuwa na huduma kadhaa zilizobuniwa tu kukuza taaluma za wafanyikazi ambao walitaka kusimamia watu wengi iwezekanavyo ili kupata pesa zaidi kwa hiyo.
Waliamini kuwa kuhamia huduma ndogo ilikuwa rahisi kama kuchukua miundombinu yao ya ndani ya safu ya N-tier na kubandika Docker juu yake. Wacha tuangalie jinsi usanifu wa jadi wa N-tier unavyoonekana.
Inajumuisha viwango 4: kiwango cha kiolesura cha mtumiaji wa UI, kiwango cha mantiki ya biashara, kiwango cha ufikiaji wa data na hifadhidata. Kinachoendelea zaidi ni DDD (Muundo Unaoendeshwa na Kikoa), au usanifu unaolenga programu, ambapo viwango viwili vya kati ni vitu vya kikoa na hazina.
Nilijaribu kuangalia maeneo tofauti ya mabadiliko, maeneo tofauti ya uwajibikaji katika usanifu huu. Katika programu ya kawaida ya N-tier, maeneo tofauti ya mabadiliko yanaainishwa ambayo hupenya muundo wima kutoka juu hadi chini. Hizi ni Katalogi, mipangilio ya Config iliyofanywa kwenye kompyuta binafsi, na ukaguzi wa Checkout, ambao ulishughulikiwa na timu yangu.
Upekee wa mpango huu ni kwamba mipaka ya maeneo haya ya mabadiliko huathiri sio tu kiwango cha mantiki ya biashara, lakini pia kupanua kwenye hifadhidata.
Hebu tuangalie maana ya kuwa huduma. Kuna sifa 6 za ufafanuzi wa huduma - ni programu ambayo:
- iliyoundwa na kutumiwa na shirika maalum;
- anawajibika kwa maudhui, usindikaji na/au utoaji wa aina fulani ya taarifa ndani ya mfumo;
- inaweza kujengwa, kutumwa na kukimbia kwa kujitegemea ili kukidhi mahitaji maalum ya uendeshaji;
- huwasiliana na watumiaji na huduma zingine, kutoa habari kulingana na makubaliano au dhamana ya mikataba;
- inajilinda kutokana na upatikanaji usioidhinishwa, na taarifa zake kutokana na kupoteza;
- hushughulikia kushindwa kwa namna ambayo haiongoi uharibifu wa habari.
Mali hizi zote zinaweza kuonyeshwa kwa neno moja "uhuru". Huduma hufanya kazi kwa kujitegemea, kukidhi vikwazo fulani, na kufafanua mikataba kwa misingi ambayo watu wanaweza kupokea taarifa wanazohitaji. Sikutaja teknolojia maalum, matumizi ambayo yanajidhihirisha.
Sasa hebu tuangalie ufafanuzi wa microservices:
- microservice ni ndogo kwa ukubwa na imeundwa kutatua tatizo moja maalum;
- Huduma ndogo ni ya uhuru;
- Wakati wa kuunda usanifu wa microservice, mfano wa kupanga mji hutumiwa. Huu ndio ufafanuzi kutoka kwa kitabu cha Sam Newman, Building Microservices.
Ufafanuzi wa Muktadha Uliowekwa umechukuliwa kutoka kwa kitabu cha Eric Evans' Domain-Driven Design. Huu ni muundo wa msingi katika DDD, kituo cha usanifu wa usanifu ambacho hufanya kazi na miundo ya usanifu ya volumetric, ikigawanya katika Miktadha tofauti yenye Mipaka na kufafanua kwa uwazi mwingiliano kati yao.
Kwa ufupi, Muktadha Uliopakana unaashiria upeo ambao moduli fulani inaweza kutumika. Ndani ya muktadha huu kuna muundo uliounganishwa kimantiki ambao unaweza kuonekana, kwa mfano, katika kikoa chako cha biashara. Ikiwa unauliza "ni nani mteja" kwa wafanyakazi wanaohusika na maagizo, utapata ufafanuzi mmoja, ikiwa unauliza wale wanaohusika katika mauzo, utapata mwingine, na watendaji watakupa ufafanuzi wa tatu.
Kwa hivyo, Muktadha Uliopakana unasema kwamba ikiwa hatuwezi kutoa ufafanuzi wazi wa kile ambacho mtumiaji wa huduma zetu ni, hebu tufafanue mipaka ambayo tunaweza kuzungumza juu ya maana ya neno hili, na kisha kufafanua pointi za mpito kati ya ufafanuzi huu tofauti. Hiyo ni, ikiwa tunazungumzia juu ya mteja kutoka kwa mtazamo wa kuweka maagizo, hii ina maana hii na hiyo, na ikiwa kutoka kwa mtazamo wa mauzo, hii ina maana hii na hiyo.
Ufafanuzi unaofuata wa microservice ni encapsulation ya aina yoyote ya shughuli za ndani, kuzuia "kuvuja" kwa vipengele vya mchakato wa kazi katika mazingira. Inayofuata inakuja "ufafanuzi wa mikataba ya wazi ya mwingiliano wa nje, au mawasiliano ya nje," ambayo inawakilishwa na wazo la mikataba inayorudi kutoka kwa SLAs. Ufafanuzi wa mwisho ni mfano wa seli, au seli, ambayo ina maana ya ujumuishaji kamili wa seti ya shughuli ndani ya huduma ndogo na uwepo ndani yake wa vipokezi vya mawasiliano na ulimwengu wa nje.
Kwa hivyo tuliwaambia watu wa Bell Computers, "Hatuwezi kurekebisha machafuko yoyote ambayo umeunda kwa sababu huna pesa ya kuifanya, lakini tutarekebisha huduma moja tu kuifanya yote ifanyike. akili.β Katika hatua hii, nitaanza kwa kukuambia jinsi tulivyorekebisha huduma yetu pekee ili ijibu maombi haraka kuliko dakika 9 na nusu.
22:30 dakika
Itaendelea hivi punde...
Matangazo kidogo
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com