Salaam wote! Tuna habari njema, OTUS inazindua kozi hiyo tena mnamo Juni , kuhusiana na ambayo kwa jadi tunashiriki nyenzo muhimu na wewe.
Ikiwa umekutana na jambo hili lote la huduma ndogo bila muktadha wowote, utasamehewa kwa kufikiria kuwa ni jambo la kushangaza kidogo. Kugawanya programu katika vipande vilivyounganishwa na mtandao kunamaanisha kuongeza hali changamano za kustahimili hitilafu kwenye mfumo unaosambazwa.
Ingawa mbinu hii inahusisha kuigawanya katika huduma nyingi huru, lengo la mwisho ni zaidi ya kuwa na huduma hizo kuendeshwa kwenye mashine tofauti. Tunazungumza hapa juu ya mwingiliano na ulimwengu wa nje, ambao pia unasambazwa katika asili yake. Sio kwa maana ya kiufundi, lakini kwa maana ya mfumo ikolojia ambao una watu wengi, timu, programu, na kila moja ya sehemu hizi inahitaji kufanya kazi yake.
Makampuni, kwa mfano, ni mkusanyiko wa mifumo iliyosambazwa ambayo kwa pamoja inachangia kufikiwa kwa lengo fulani. Tumepuuza ukweli huu kwa miongo kadhaa, tukijaribu kufikia kuunganishwa kwa faili za FTPing au kutumia zana za ujumuishaji wa biashara huku tukizingatia malengo yetu pekee. Lakini pamoja na ujio wa huduma, kila kitu kilibadilika. Huduma zimetusaidia kutazama zaidi ya upeo wa macho na kuona ulimwengu wa programu zinazotegemeana zinazofanya kazi pamoja. Hata hivyo, ili kufanya kazi kwa mafanikio, ni muhimu kutambua na kubuni ulimwengu mbili tofauti kimsingi: ulimwengu wa nje, ambapo tunaishi katika mfumo wa ikolojia wa huduma nyingine nyingi, na ulimwengu wetu wa kibinafsi, wa ndani, ambapo tunatawala peke yake.
Dunia hii iliyosambazwa ni tofauti na ile tuliyokulia na tumeizoea. Kanuni za kujenga usanifu wa jadi wa monolithic hazisimama kwa upinzani. Kwa hivyo kupata mifumo hii sawa ni zaidi ya kuunda mchoro mzuri wa ubao mweupe au uthibitisho mzuri wa dhana. Jambo kuu ni kuhakikisha kuwa mfumo kama huo unafanya kazi kwa mafanikio kwa muda mrefu. Kwa bahati nzuri, huduma zimekuwepo kwa muda mrefu, ingawa zinaonekana tofauti. bado zinafaa, hata zimekolezwa na Docker, Kubernetes na ndevu za hipster zilizoharibika kidogo.
Kwa hivyo leo tutaangalia jinsi sheria zimebadilika, kwa nini tunahitaji kufikiria upya jinsi tunavyoshughulikia huduma na data wanazopitishana, na kwa nini tutahitaji zana tofauti kabisa kuifanya.
Encapsulation haitakuwa rafiki yako kila wakati
Microservices zinaweza kufanya kazi kwa kujitegemea. Ni mali hii ambayo inawapa thamani kubwa zaidi. Mali hiyo hiyo inaruhusu huduma kuongeza na kukua. Sio sana kwa maana ya kuongeza mamilioni ya watumiaji au petabytes za data (ingawa hizo zinaweza kusaidia huko pia), lakini kwa maana ya kuongeza idadi ya watu kadri timu na mashirika yanavyokua kila wakati.
Hata hivyo, uhuru ni upanga wenye makali kuwili. Hiyo ni, huduma yenyewe inaweza kukimbia kwa urahisi na kwa kawaida. Lakini ikiwa chaguo la kukokotoa litatekelezwa ndani ya huduma inayohitaji kutumia huduma nyingine, basi tutalazimika kufanya mabadiliko kwa huduma zote mbili karibu kwa wakati mmoja. Katika monolith hii ni rahisi kufanya, wewe tu kufanya mabadiliko na kutuma kwa kutolewa, lakini katika kesi ya kusawazisha huduma za kujitegemea kutakuwa na matatizo zaidi. Uratibu kati ya timu na mizunguko ya kutolewa huharibu wepesi.
Kama sehemu ya mbinu ya kawaida, wanajaribu tu kuzuia mabadiliko ya kukasirisha ya mwisho hadi mwisho, kugawanya kwa uwazi utendaji kati ya huduma. Huduma ya kuingia mara moja inaweza kuwa mfano mzuri hapa. Ina jukumu lililofafanuliwa wazi ambalo huitofautisha na huduma zingine. Utengano huu wa wazi unamaanisha kuwa katika ulimwengu wa mahitaji yanayobadilika haraka kwa huduma zinazoizunguka, huduma ya kuingia mara moja haiwezi kubadilika. Inapatikana ndani ya muktadha mdogo kabisa.
Shida ni kwamba katika ulimwengu wa kweli, huduma za biashara haziwezi kudumisha utengano safi sawa wa majukumu kila wakati. Kwa mfano, huduma sawa za biashara hufanya kazi kwa kiwango kikubwa na data inayotoka kwa huduma zingine zinazofanana. Ikiwa unajihusisha na uuzaji wa rejareja mtandaoni, basi mtiririko wa mpangilio wa usindikaji, orodha ya bidhaa au maelezo ya mtumiaji yatakuwa hitaji la huduma zako nyingi. Kila moja ya huduma itahitaji ufikiaji wa data hii ili kufanya kazi.
Huduma nyingi za biashara hushiriki mtiririko sawa wa data, kwa hivyo kazi yao inaunganishwa kila wakati.
Kwa hivyo tunafika kwenye jambo muhimu linalofaa kuzungumzia. Ingawa huduma hufanya kazi vizuri kwa vipengele vya miundombinu ambavyo hufanya kazi kwa pekee, huduma nyingi za biashara huishia kuunganishwa kwa karibu zaidi.
Dichotomy ya data
Mbinu zinazolenga huduma zinaweza kuwa tayari zipo, lakini bado hazina ufahamu wa jinsi ya kushiriki kiasi kikubwa cha data kati ya huduma.
Shida kuu ni kwamba data na huduma hazitenganishwi. Kwa upande mmoja, encapsulation inatuhimiza kuficha data ili huduma ziweze kutenganishwa kutoka kwa kila mmoja na kuwezesha ukuaji wao na mabadiliko zaidi. Kwa upande mwingine, tunahitaji kuwa na uwezo wa kugawanya na kushinda data iliyoshirikiwa kwa uhuru, kama data nyingine yoyote. Jambo ni kuwa na uwezo wa kuanza kufanya kazi mara moja, kwa uhuru kama katika mfumo mwingine wowote wa habari.
Walakini, mifumo ya habari haina uhusiano kidogo na ujumuishaji. Kwa kweli, ni kinyume kabisa. Hifadhidata hufanya kila linalowezekana ili kutoa ufikiaji wa data wanayohifadhi. Wanakuja na kiolesura chenye nguvu cha kutangaza ambacho hukuruhusu kurekebisha data unavyohitaji. Utendaji kama huu ni muhimu katika hatua ya awali ya utafiti, lakini si kwa ajili ya kudhibiti ugumu unaokua wa huduma inayoendelea kubadilika.
Na hapa kuna mtanziko. Utata. Dichotomia. Baada ya yote, mifumo ya habari ni kuhusu kutoa data, na huduma ni kuhusu kujificha.
Nguvu hizi mbili ni za msingi. Wanashikilia sehemu kubwa ya kazi yetu, wakipigania kila mara kwa ubora katika mifumo tunayounda.
Mifumo ya huduma inapokua na kubadilika, tunaona matokeo ya utengano wa data kwa njia nyingi. Kiolesura cha huduma kitakua, na kutoa utendakazi unaoongezeka kila mara na kuanza kuonekana kama hifadhidata ya kifahari ya nyumbani, au tutachanganyikiwa na kutekeleza baadhi ya njia ya kupata au kuhamisha kwa wingi seti nzima za data kutoka huduma hadi huduma.
Kwa upande wake, kuunda kitu ambacho kinaonekana kama hifadhidata ya kupendeza ya nyumbani itasababisha shida nyingi. Hatutaingia kwa undani kuhusu kwa nini ni hatari hifadhidata iliyoshirikiwa, hebu tuseme kwamba inawakilisha uhandisi na uendeshaji wa gharama kubwa kwa kampuni inayojaribu kuitumia.
Mbaya zaidi ni kwamba idadi ya data inakuza shida za mipaka ya huduma. Kadiri data iliyoshirikiwa inavyokuwa ndani ya huduma, ndivyo kiolesura kitakavyokuwa chagumu zaidi na ndivyo itakavyokuwa vigumu kuchanganya seti za data zinazotoka kwa huduma tofauti.
Mbinu mbadala ya kutoa na kuhamisha seti nzima za data pia ina matatizo yake. Njia ya kawaida ya swali hili inaonekana kama kurejesha na kuhifadhi hifadhidata nzima, na kisha kuihifadhi ndani ya kila huduma inayotumia.
Shida ni kwamba huduma tofauti hutafsiri data wanazotumia tofauti. Data hii iko karibu kila wakati. Zinabadilishwa na kusindika ndani ya nchi. Haraka sana huacha kuwa na kitu chochote kinachofanana na data kwenye chanzo.
Kadiri nakala zinavyoweza kubadilika, ndivyo data itatofautiana kwa wakati.
Ili kufanya mambo kuwa mbaya zaidi, data kama hiyo ni ngumu kusahihisha kwa kurudi nyuma ( Hapa ndipo inaweza kuja kuwaokoa). Kwa hakika, baadhi ya matatizo ya teknolojia yasiyoweza kutatulika ambayo biashara hukabiliana nayo hutokana na data tofauti ambayo huongezeka kutoka kwa programu hadi matumizi.
Ili kupata suluhisho la tatizo hili, tunahitaji kufikiria tofauti kuhusu data iliyoshirikiwa. Lazima viwe vitu vya daraja la kwanza katika usanifu tunaojenga. huita data hiyo "nje", na hii ni kipengele muhimu sana. Tunahitaji maelezo ili tusionyeshe utendaji kazi wa ndani wa huduma, lakini tunahitaji kurahisisha huduma kufikia data iliyoshirikiwa ili ziweze kufanya kazi zao kwa usahihi.
Shida ni kwamba hakuna njia inayofaa leo, kwani miingiliano ya huduma, au ujumbe, au Hifadhidata iliyoshirikiwa haitoi suluhisho nzuri la kufanya kazi na data ya nje. Miingiliano ya huduma haifai kwa ubadilishanaji wa data kwa kiwango chochote. Utumaji ujumbe huhamisha data lakini haihifadhi historia yake, kwa hivyo data inaharibika baada ya muda. Hifadhidata Zilizoshirikiwa huzingatia sana nukta moja, jambo ambalo linarudisha nyuma maendeleo. Bila shaka tunakwama katika mzunguko wa kushindwa kwa data:
Mzunguko wa kushindwa kwa data
Mitiririko: mbinu iliyogatuliwa kwa data na huduma
Kwa kweli, tunahitaji kubadilisha jinsi huduma zinavyofanya kazi na data iliyoshirikiwa. Katika hatua hii, mbinu yoyote inakabiliwa na dichotomy iliyotajwa hapo juu, kwani hakuna vumbi la kichawi ambalo linaweza kunyunyiziwa juu yake ili kutoweka. Walakini, tunaweza kufikiria tena shida na kufikia maelewano.
Maelewano haya yanahusisha kiwango fulani cha centralization. Tunaweza kutumia utaratibu wa kumbukumbu uliosambazwa kwa sababu hutoa mitiririko inayotegemeka na inayoweza kusambazwa. Sasa tunataka huduma ziweze kujiunga na kutumia nyuzi hizi zinazoshirikiwa, lakini tunataka kuepuka Huduma changamani za Mungu ambazo huchakata. Kwa hiyo, chaguo bora ni kujenga usindikaji wa mkondo katika kila huduma ya watumiaji. Kwa njia hii, huduma zitaweza kuchanganya seti za data kutoka vyanzo tofauti na kufanya kazi nazo jinsi zinavyohitaji.
Njia moja ya kufikia mbinu hii ni kutumia jukwaa la utiririshaji. Kuna chaguo nyingi, lakini leo tutaangalia Kafka, kwa kuwa matumizi ya Usindikaji wa Mtiririko wa Jimbo hutuwezesha kutatua kwa ufanisi tatizo lililowasilishwa.
Kutumia utaratibu wa kukata miti uliosambazwa huturuhusu kufuata njia iliyokanyagwa vizuri na kutumia ujumbe kufanya kazi nao . Mbinu hii inachukuliwa kutoa kuongeza na kugawanya bora kuliko utaratibu wa kujibu ombi kwa sababu inatoa udhibiti wa mtiririko kwa mpokeaji badala ya mtumaji. Hata hivyo, kwa kila kitu katika maisha haya unapaswa kulipa, na hapa unahitaji broker. Lakini kwa mifumo mikubwa, ubadilishanaji ni wa thamani yake (ambayo inaweza kuwa sivyo kwa programu yako ya wastani ya wavuti).
Ikiwa wakala anawajibika kwa uwekaji kumbukumbu uliosambazwa badala ya mfumo wa kawaida wa utumaji ujumbe, unaweza kuchukua faida ya vipengele vya ziada. Usafirishaji unaweza kuongezeka kwa mstari karibu na mfumo wa faili uliosambazwa. Data inaweza kuhifadhiwa kwenye kumbukumbu kwa muda mrefu sana, kwa hivyo tunapata sio kubadilishana ujumbe tu, bali pia uhifadhi wa habari. Hifadhi kubwa bila hofu ya hali inayoweza kubadilishwa inayoshirikiwa.
Kisha unaweza kutumia usindikaji wa hali ya juu wa utiririshaji ili kuongeza zana za kutangaza hifadhidata kwa huduma zinazotumia. Hili ni wazo muhimu sana. Ingawa data imehifadhiwa katika mitiririko iliyoshirikiwa ambayo huduma zote zinaweza kufikia, ujumlisho na usindikaji ambao huduma hufanya ni ya faragha. Wanajikuta wametengwa ndani ya muktadha mdogo kabisa.
Ondoa dichotomia ya data kwa kutenganisha mtiririko wa hali isiyobadilika. Kisha ongeza utendakazi huu kwa kila huduma kwa kutumia Uchakataji wa Utiririshaji Mahiri.
Kwa hivyo, ikiwa huduma yako inahitaji kufanya kazi na maagizo, orodha ya bidhaa, ghala, itakuwa na ufikiaji kamili: tu utaamua ni data gani ya kuchanganya, wapi kusindika na jinsi inapaswa kubadilika kwa wakati. Licha ya ukweli kwamba data inashirikiwa, kazi nayo imegawanywa kabisa. Inazalishwa ndani ya kila huduma, katika ulimwengu ambapo kila kitu kinakwenda kulingana na sheria zako.
Shiriki data bila kuhatarisha uadilifu wake. Weka kipengele cha kukokotoa, si chanzo, katika kila huduma inayohitaji.
Inatokea kwamba data inahitaji kuhamishwa kwa wingi. Wakati mwingine huduma huhitaji hifadhidata ya eneo la ndani katika injini ya hifadhidata iliyochaguliwa. Ujanja ni kwamba unaweza kuhakikisha kwamba, ikiwa ni lazima, nakala inaweza kurejeshwa kutoka kwa chanzo kwa kupata utaratibu wa kukata magogo uliosambazwa. Viunganishi huko Kafka hufanya kazi nzuri ya hii.
Kwa hivyo, njia iliyojadiliwa leo ina faida kadhaa:
- Data hutumiwa kwa namna ya mito ya kawaida, ambayo inaweza kuhifadhiwa kwenye kumbukumbu kwa muda mrefu, na utaratibu wa kufanya kazi na data ya kawaida ni ngumu katika kila mazingira ya mtu binafsi, ambayo inaruhusu huduma kufanya kazi kwa urahisi na kwa haraka. Kwa njia hii, dichotomy ya data inaweza kusawazishwa.
- Data inayotoka kwa huduma tofauti inaweza kuunganishwa kwa urahisi katika seti. Hii hurahisisha mwingiliano na data iliyoshirikiwa na kuondoa hitaji la kudumisha hifadhidata za ndani kwenye hifadhidata.
- Uchakataji wa Mtiririko wa Serikali huhifadhi data pekee, na chanzo cha ukweli hubaki kuwa kumbukumbu za jumla, kwa hivyo tatizo la uharibifu wa data kwa wakati sio kubwa sana.
- Msingi wao, huduma zinaendeshwa na data, kumaanisha kuwa licha ya idadi ya data inayoongezeka kila mara, huduma bado zinaweza kujibu kwa haraka matukio ya biashara.
- Masuala ya scalability huanguka kwa wakala, sio huduma. Hii inapunguza kwa kiasi kikubwa ugumu wa huduma za uandishi, kwani hakuna haja ya kufikiria juu ya scalability.
- Kuongeza huduma mpya hauhitaji kubadilisha za zamani, hivyo kuunganisha huduma mpya inakuwa rahisi.
Kama unavyoona, hii ni zaidi ya REST tu. Tumepokea seti ya zana zinazokuruhusu kufanya kazi na data iliyoshirikiwa kwa njia ya ugatuzi.
Sio vipengele vyote vilivyofunikwa katika makala ya leo. Bado tunahitaji kujua jinsi ya kusawazisha kati ya dhana ya jibu la ombi na dhana inayoendeshwa na tukio. Lakini tutashughulikia hili wakati ujao. Kuna mada ambazo unahitaji kufahamu vyema zaidi, kwa mfano, kwa nini Uchakataji wa Mitiririko Makuu ni mzuri sana. Tutazungumza juu ya hili katika makala ya tatu. Na kuna miundo mingine yenye nguvu ambayo tunaweza kuchukua faida ikiwa tutaifuata, kwa mfano, . Ni kibadilishaji mchezo kwa mifumo ya biashara iliyosambazwa kwa sababu hutoa dhamana ya shughuli kwa kwa fomu inayoweza kuongezeka. Hili litazungumziwa katika makala ya nne. Hatimaye, tutahitaji kupitia maelezo ya utekelezaji wa kanuni hizi.
Lakini kwa sasa, kumbuka tu hili: dichotomy ya data ni nguvu tunayokabiliana nayo wakati wa kujenga huduma za biashara. Na tunapaswa kukumbuka hili. Ujanja ni kugeuza kila kitu kichwani mwake na kuanza kutibu data iliyoshirikiwa kama vitu vya daraja la kwanza. Uchakataji wa Utiririshaji Madhubuti hutoa maelewano ya kipekee kwa hili. Inaepuka "Vijenzi vya Mungu" ambavyo vinarudisha nyuma maendeleo. Zaidi ya hayo, inahakikisha wepesi, uimara na uthabiti wa mabomba ya utiririshaji data na kuyaongeza kwa kila huduma. Kwa hiyo, tunaweza kuzingatia mkondo wa jumla wa ufahamu ambao huduma yoyote inaweza kuunganisha na kufanya kazi na data yake. Hii inafanya huduma kuwa scalable zaidi, kubadilishana na uhuru. Kwa hivyo hawataonekana vizuri tu kwenye ubao mweupe na vipimo vya nadharia, lakini pia watafanya kazi na kufuka kwa miongo kadhaa.
Chanzo: mapenzi.com