Kwa namna fulani, kihistoria, sekta ya IT imegawanywa katika kambi mbili za masharti kwa sababu yoyote: wale ambao ni "kwa" na wale ambao ni "dhidi". Aidha, mada ya migogoro inaweza kuwa ya kiholela kabisa. Ni OS gani bora: Win au Linux? Kwenye simu mahiri ya Android au iOS? Je! unapaswa kuhifadhi kila kitu kwenye mawingu au kuiweka kwenye hifadhi baridi ya RAID na kuweka screws kwenye salama? Je, watu wa PHP wana haki ya kuitwa waandaaji programu? Mizozo hii, wakati fulani, huwa ipo kwa asili pekee na haina msingi wowote zaidi ya maslahi ya michezo.
Ilifanyika tu kwamba pamoja na ujio wa vyombo na vyakula hivi vyote vinavyopendwa na docker na k8s za masharti, mijadala "kwa" na "dhidi" ya matumizi ya uwezo mpya katika maeneo mbalimbali ya backend ilianza. (Hebu tuweke nafasi mapema kwamba ingawa Kubernetes mara nyingi ataonyeshwa kama mwimbaji katika mjadala huu, chaguo la zana hii sio muhimu sana. Badala yake, unaweza kubadilisha nyingine yoyote ambayo inaonekana kufaa zaidi na inayojulikana kwako. .)
Na, inaweza kuonekana, hii itakuwa mzozo rahisi kati ya pande mbili za sarafu moja. Haina maana na isiyo na huruma kama pambano la milele kati ya Win vs Linux, ambapo watu wa kutosha wanapatikana mahali fulani katikati. Lakini katika kesi ya uwekaji wa vyombo, sio kila kitu ni rahisi sana. Kawaida katika mabishano kama haya hakuna upande wa kulia, lakini katika kesi ya "tumia" au "kutotumia" vyombo kwa kuhifadhi hifadhidata, kila kitu kinageuka chini. Kwa sababu kwa maana fulani, wafuasi na wapinzani wa njia hii ni sawa.
Upande mkali
Hoja ya Upande wa Mwanga inaweza kuelezewa kwa ufupi katika kifungu kimoja: "Habari, 2k19 iko nje ya dirisha!" Inaonekana kama populism, kwa kweli, lakini ikiwa unachunguza hali hiyo kwa undani, ina faida zake. Hebu tuyatatue sasa.
Wacha tuseme una mradi mkubwa wa wavuti. Inaweza kuwa imejengwa awali kwa misingi ya mbinu ya microservice, au wakati fulani ilikuja kwa njia ya mageuzi - hii sio muhimu sana, kwa kweli. Ulitawanya mradi wetu katika huduma ndogo tofauti, ulianzisha okestration, kusawazisha upakiaji, na kuongeza. Na sasa, kwa dhamiri safi, unakunywa mojito kwenye chandarua wakati wa athari za habra badala ya kuinua seva zilizoanguka. Lakini katika vitendo vyote lazima uwe thabiti. Mara nyingi sana, ni programu tumizi yenyeweβmsimboβhuwekwa ndani. Je, tuna nini kingine zaidi ya kanuni?
Hiyo ni kweli, data. Kiini cha mradi wowote ni data yake: hii inaweza kuwa DBMS ya kawaida - MySQL, Postgre, MongoDB, au hifadhi inayotumika kutafuta (ElasticSearch), uhifadhi wa thamani ya akiba - kwa mfano, redis, nk. Kwa sasa hatupo. tutazungumza juu ya chaguzi potofu za utekelezaji hifadhidata inapoanguka kwa sababu ya maswali yaliyoandikwa vibaya, na badala yake tutazungumza juu ya kuhakikisha uvumilivu wa makosa ya hifadhidata hii chini ya mzigo wa mteja. Baada ya yote, tunapoweka ombi letu na kuiruhusu iongezeke kwa uhuru kushughulikia idadi yoyote ya maombi yanayoingia, hii huongeza mzigo kwenye hifadhidata.
Kwa hakika, chaneli ya kufikia hifadhidata na seva ambayo inaendeshwa huwa tundu la sindano katika mandhari yetu nzuri ya nyuma yenye vyombo. Wakati huo huo, nia kuu ya uboreshaji wa chombo ni uhamaji na unyumbufu wa muundo, ambayo huturuhusu kupanga usambazaji wa mizigo ya kilele katika miundombinu yote inayopatikana kwetu kwa ufanisi iwezekanavyo. Hiyo ni, ikiwa hatutaweka vyombo na kusambaza vipengele vyote vilivyopo vya mfumo kwenye nguzo, tunafanya makosa makubwa sana.
Ni busara zaidi kuunganisha sio tu programu yenyewe, lakini pia huduma zinazohusika na kuhifadhi data. Kwa kuunganisha na kupeleka seva za wavuti zinazofanya kazi kwa kujitegemea na kusambaza mzigo kati yao katika k8s, tayari tunatatua tatizo la ulandanishi wa data - maoni sawa kwenye machapisho, ikiwa tutachukua baadhi ya vyombo vya habari au jukwaa la blogu kama mfano. Kwa vyovyote vile, tuna uwakilishi wa ndani ya kundi, hata mtandaoni, wa hifadhidata kama Huduma ya Nje. Swali ni kwamba hifadhidata yenyewe bado haijaunganishwa - seva za wavuti zilizowekwa kwenye mchemraba huchukua habari kuhusu mabadiliko kutoka kwa hifadhidata yetu ya mapigano tuli, ambayo huzunguka kando.
Je, unahisi kunasa? Tunatumia k8s au Swarm kusambaza mzigo na kuepuka kuharibu seva kuu ya wavuti, lakini hatufanyi hivi kwa hifadhidata. Lakini ikiwa hifadhidata itaanguka, basi miundombinu yetu yote iliyounganishwa haina maana - kurasa tupu za wavuti zina faida gani zinazorudisha hitilafu ya ufikiaji wa hifadhidata?
Ndio maana inahitajika kuunganisha sio seva za wavuti tu, kama kawaida hufanyika, lakini pia miundombinu ya hifadhidata. Ni kwa njia hii tu tunaweza kuhakikisha muundo unaofanya kazi kikamilifu katika timu moja, lakini wakati huo huo huru kutoka kwa kila mmoja. Kwa kuongezea, hata ikiwa nusu ya sehemu yetu ya nyuma "itaanguka" chini ya mzigo, iliyobaki itabaki, na mfumo wa kusawazisha hifadhidata na kila mmoja ndani ya nguzo na uwezo wa kuongeza na kupeleka nguzo mpya zitasaidia kufikia haraka uwezo unaohitajika - ikiwa tu kulikuwa na rafu kwenye kituo cha data.
Kwa kuongezea, muundo wa hifadhidata uliosambazwa katika vikundi hukuruhusu kuchukua hifadhidata hii mahali inapohitajika; Ikiwa tunazungumza juu ya huduma ya kimataifa, basi sio mantiki kabisa kuzunguka nguzo ya wavuti mahali fulani katika eneo la San Francisco na wakati huo huo kutuma pakiti wakati wa kupata hifadhidata katika mkoa wa Moscow na nyuma.
Pia, uwekaji wa hifadhidata hukuruhusu kuunda vitu vyote vya mfumo kwa kiwango sawa cha kujiondoa. Ambayo, kwa upande wake, inafanya uwezekano wa kusimamia mfumo huu moja kwa moja kutoka kwa kanuni, na watengenezaji, bila ushirikishwaji wa wasimamizi. Watengenezaji walidhani kuwa DBMS tofauti ilihitajika kwa mradi mpya - rahisi! aliandika faili ya yaml, akaipakia kwenye nguzo na umemaliza.
Na bila shaka, uendeshaji wa ndani ni rahisi sana. Niambie, ni mara ngapi umefunga macho yako wakati mwanachama mpya wa timu alipoweka mikono yake kwenye hifadhidata ya mapigano kwa kazi? Ambayo, kwa kweli, ni moja tu una na ni inazunguka sasa hivi? Kwa kweli, sisi sote ni watu wazima hapa, na mahali pengine tuna nakala rudufu, na hata mbali zaidi - nyuma ya rafu iliyo na matango ya bibi na skis za zamani - nakala nyingine, labda hata kwenye uhifadhi baridi, kwa sababu ofisi yako tayari ilikuwa imewaka moto mara moja. Lakini sawa, kila utangulizi wa mwanachama mpya wa timu na upatikanaji wa miundombinu ya kupambana na, bila shaka, kwa hifadhidata ya mapigano ni ndoo ya validol kwa kila mtu karibu. Kweli, ni nani anayemjua, mtoto mpya, labda ana msalaba? Inatisha, utakubali.
Uwekaji vyombo na, kwa kweli, topolojia ya mwili iliyosambazwa ya hifadhidata ya mradi wako husaidia kuzuia nyakati kama hizi za uthibitishaji. Je, humwamini mgeni? SAWA! Wacha tumpe kikundi chake cha kufanya kazi nacho na kutenganisha hifadhidata kutoka kwa vikundi vingine - kusawazisha tu kwa kusukuma kwa mikono na kuzungusha funguo mbili (moja kwa kiongozi wa timu, nyingine kwa msimamizi). Na kila mtu anafurahi.
Na sasa ni wakati wa kubadilika kuwa wapinzani wa nguzo za hifadhidata.
Upande wa giza
Tukibishana kwa nini haifai kuweka hifadhidata na kuendelea kuiendesha kwenye seva moja kuu, hatutaegemea kwenye matamshi ya itikadi kali na kauli kama vile "babu waliendesha hifadhidata kwenye maunzi, na sisi pia tutafanya hivyo!" Badala yake, wacha tujaribu kuja na hali ambayo uwekaji wa vyombo unaweza kulipa gawio dhahiri.
Kukubaliana, miradi ambayo kwa kweli inahitaji msingi katika chombo inaweza kuhesabiwa kwa vidole vya mkono mmoja na si operator bora wa mashine ya kusaga. Kwa sehemu kubwa, hata utumiaji wa k8s au Docker Swarm yenyewe ni ya lazima - mara nyingi zana hizi hurejelewa kwa sababu ya msukumo wa jumla wa teknolojia na mitazamo ya "mwenye nguvu" katika mtu wa jinsia kusukuma kila kitu ndani. mawingu na vyombo. Naam, kwa sababu sasa ni mtindo na kila mtu anafanya hivyo.
Katika angalau nusu ya kesi, kutumia Kubernetis au Docker tu kwenye mradi ni muhimu. Suala ni kwamba sio timu zote au kampuni za upangaji zilizoajiriwa kudumisha miundombinu ya mteja zinafahamu hili. Ni mbaya zaidi wakati vyombo vinawekwa, kwa sababu inagharimu kiasi fulani cha sarafu kwa mteja.
Kwa ujumla, kuna maoni kwamba docker/mchemraba mafia ni upumbavu kuponda wateja ambao outsources masuala haya ya miundombinu. Baada ya yote, ili kufanya kazi na makundi, tunahitaji wahandisi ambao wana uwezo wa hili na kwa ujumla kuelewa usanifu wa ufumbuzi uliotekelezwa. Wakati fulani tayari tulielezea kesi yetu na uchapishaji wa Jamhuri - hapo tulifunza timu ya mteja kufanya kazi katika hali halisi ya Kubernetis, na kila mtu aliridhika. Na ilikuwa ya heshima. Mara nyingi, "watekelezaji" wa k8 huchukua mateka wa miundombinu ya mteja - kwa sababu sasa wanaelewa tu jinsi kila kitu kinavyofanya kazi hapo; hakuna wataalam kwa upande wa mteja.
Sasa fikiria kwamba kwa njia hii tunatoa sio tu sehemu ya seva ya wavuti, lakini pia matengenezo ya hifadhidata. Tulisema kwamba BD ni moyo, na kupoteza moyo ni mbaya kwa kiumbe chochote kilicho hai. Kwa kifupi, matarajio sio bora zaidi. Kwa hivyo, badala ya Hype Kubernetis, miradi mingi haipaswi kujisumbua tu na ushuru wa kawaida wa AWS, ambayo itasuluhisha shida zote na mzigo kwenye tovuti / mradi wao. Lakini AWS si ya mtindo tena, na maonyesho ya nje yana thamani zaidi ya pesa - kwa bahati mbaya, katika mazingira ya IT pia.
SAWA. Labda mradi kweli unahitaji nguzo, lakini ikiwa kila kitu kiko wazi na programu zisizo na uraia, basi tunawezaje kupanga muunganisho mzuri wa mtandao kwa hifadhidata iliyounganishwa?
Ikiwa tunazungumza juu ya suluhisho la uhandisi la imefumwa, ambalo ni mpito kwa k8s ni, basi maumivu yetu kuu ya kichwa ni replication ya data katika hifadhidata iliyounganishwa. Baadhi ya DBMS awali ni waaminifu kabisa kwa usambazaji wa data kati ya matukio yao binafsi. Wengine wengi hawakaribishwi sana. Na mara nyingi hoja kuu katika kuchagua DBMS kwa mradi wetu sio uwezo wa kuiga na gharama ndogo za rasilimali na uhandisi. Hasa ikiwa mradi haukupangwa hapo awali kama huduma ndogo, lakini ulibadilishwa tu katika mwelekeo huu.
Tunadhani hakuna haja ya kuzungumza juu ya kasi ya anatoa mtandao - ni polepole. Wale. Bado hatuna fursa halisi, ikiwa kitu kitatokea, kuanzisha upya mfano wa DBMS mahali fulani ambapo kuna zaidi, kwa mfano, nguvu ya processor au RAM ya bure. Tutaendesha haraka sana utendaji wa mfumo mdogo wa diski ulioboreshwa. Ipasavyo, DBMS lazima ipigwe misumari kwenye seti yake ya kibinafsi ya mashine zilizo karibu. Au ni muhimu kwa namna fulani kupoza ulandanishi wa data wa haraka wa kutosha kwa hifadhi zinazodhaniwa.
Kuendeleza mada ya mifumo ya faili halisi: Kiasi cha Docker, kwa bahati mbaya, sio shida. Kwa ujumla, katika suala kama uhifadhi wa data wa kuaminika wa muda mrefu, ningependa kufanya kazi na mipango rahisi zaidi ya kiufundi. Na kuongeza safu mpya ya uondoaji kutoka kwa FS ya kontena hadi FS ya mwenyeji mzazi ni hatari yenyewe. Lakini wakati utendakazi wa mfumo wa usaidizi wa uwekaji vyombo pia unakumbana na matatizo ya kusambaza data kati ya tabaka hizi, basi ni janga kwelikweli. Kwa sasa, matatizo mengi yanayojulikana kwa wanadamu wanaoendelea yanaonekana kuwa yametokomezwa. Lakini unaelewa, ngumu zaidi utaratibu, ni rahisi zaidi kuvunja.
Kwa kuzingatia "ujio" huu wote, ni faida zaidi na rahisi kuweka hifadhidata katika sehemu moja, na hata ikiwa unahitaji kuweka programu, iruhusu iendeshe yenyewe na kupitia lango la usambazaji pokea mawasiliano ya wakati mmoja na hifadhidata, ambayo itasomwa na kuandikwa mara moja tu na Katika sehemu moja. Mbinu hii inapunguza uwezekano wa makosa na utenganishaji kwa kiwango cha chini.
Tunaongoza kwa nini? Zaidi ya hayo, uwekaji wa hifadhidata unafaa pale ambapo kuna hitaji la kweli. Huwezi kuweka hifadhidata ya programu kamili na kuizungusha kana kwamba una huduma ndogo ndogo mbili - haifanyi kazi kwa njia hiyo. Na hii lazima ieleweke wazi.
Badala ya pato
Ikiwa unasubiri hitimisho wazi "kuboresha hifadhidata au la," basi tutakukatisha tamaa: haitakuwa hapa. Kwa sababu wakati wa kuunda ufumbuzi wowote wa miundombinu, mtu lazima aongozwe si kwa mtindo na maendeleo, lakini, kwanza kabisa, kwa akili ya kawaida.
Kuna miradi ambayo kanuni na zana zinazokuja na Kubernetis zinafaa kikamilifu, na katika miradi kama hiyo kuna amani angalau katika eneo la nyuma. Na kuna miradi ambayo haiitaji uwekaji wa vyombo, lakini miundombinu ya seva ya kawaida, kwa sababu kimsingi haiwezi kubadilika kwa mfano wa nguzo ya huduma ndogo, kwa sababu itaanguka.
Chanzo: mapenzi.com