Katika nakala hii, nitazungumza juu ya jinsi mradi ninaofanya kazi ulibadilishwa kutoka kwa monolith kubwa hadi seti ya huduma ndogo.
Mradi ulianza historia yake muda mrefu sana, mwanzoni mwa 2000. Matoleo ya kwanza yaliandikwa katika Visual Basic 6. Baada ya muda, ikawa wazi kuwa maendeleo katika lugha hii itakuwa vigumu kusaidia katika siku zijazo, tangu IDE. na lugha yenyewe ina maendeleo duni. Mwishoni mwa miaka ya 2000, iliamuliwa kubadili C # ya kuahidi zaidi. Toleo jipya liliandikwa kwa sambamba na marekebisho ya zamani, hatua kwa hatua kanuni zaidi na zaidi iliandikwa katika NET. Backend katika C # hapo awali ililenga usanifu wa huduma, lakini wakati wa maendeleo, maktaba ya kawaida yenye mantiki yalitumiwa, na huduma zilizinduliwa katika mchakato mmoja. Matokeo yake yalikuwa maombi ambayo tuliita "monolith ya huduma."
Moja ya faida chache za mchanganyiko huu ilikuwa uwezo wa huduma kupiga simu kupitia API ya nje. Kulikuwa na mahitaji ya wazi ya mpito kwa huduma sahihi zaidi, na katika siku zijazo, usanifu wa huduma ndogo.
Tulianza kazi yetu ya mtengano karibu 2015. Bado hatujafikia hali nzuri - bado kuna sehemu za mradi mkubwa ambazo haziwezi kuitwa monoliths, lakini hazionekani kama huduma ndogo. Walakini, maendeleo ni muhimu.
Nitazungumza juu yake katika makala.
yaliyomo
Usanifu na matatizo ya ufumbuzi uliopo
Hapo awali, usanifu ulionekana kama hii: UI ni programu tofauti, sehemu ya monolithic imeandikwa katika Visual Basic 6, programu ya NET ni seti ya huduma zinazohusiana zinazofanya kazi na hifadhidata kubwa.
Hasara za ufumbuzi uliopita
Hatua moja ya kushindwa
Tulikuwa na nukta moja ya kushindwa: programu ya .NET ilifanya kazi katika mchakato mmoja. Ikiwa moduli yoyote ilishindwa, programu nzima ilishindwa na ilibidi iwashwe upya. Kwa kuwa tunabadilisha idadi kubwa ya michakato kwa watumiaji tofauti, kwa sababu ya kutofaulu kwa mmoja wao, kila mtu hakuweza kufanya kazi kwa muda. Na katika kesi ya kosa la programu, hata chelezo haikusaidia.
Foleni ya maboresho
Drawback hii ni badala ya shirika. Programu yetu ina wateja wengi, na wote wanataka kuiboresha haraka iwezekanavyo. Hapo awali, haikuwezekana kufanya hivyo kwa sambamba, na wateja wote walisimama kwenye mstari. Utaratibu huu ulikuwa mbaya kwa biashara kwa sababu walipaswa kuthibitisha kwamba kazi yao ilikuwa ya thamani. Na timu ya maendeleo ilitumia muda kupanga foleni hii. Hii ilichukua muda mwingi na juhudi, na bidhaa hatimaye haikuweza kubadilika haraka kama wangependa.
Matumizi duni ya rasilimali
Wakati wa kupangisha huduma katika mchakato mmoja, kila mara tulinakili kabisa usanidi kutoka kwa seva hadi seva. Tulitaka kuweka huduma zenye mizigo mingi zaidi kando ili tusipoteze rasilimali na kupata udhibiti rahisi zaidi wa mpango wetu wa kusambaza.
Vigumu kutekeleza teknolojia za kisasa
Tatizo linalojulikana kwa watengenezaji wote: kuna tamaa ya kuanzisha teknolojia za kisasa katika mradi huo, lakini hakuna fursa. Kwa suluhisho kubwa la monolithic, sasisho lolote la maktaba ya sasa, bila kutaja mpito kwa mpya, hugeuka kuwa kazi isiyo ya kawaida. Inachukua muda mrefu kuthibitisha kwa kiongozi wa timu kwamba hii italeta mafao zaidi kuliko mishipa iliyopotea.
Ugumu wa kutoa mabadiliko
Hili ndilo lilikuwa tatizo kubwa zaidi - tulikuwa tukitoa matoleo kila baada ya miezi miwili.
Kila toleo liligeuka kuwa janga la kweli kwa benki, licha ya majaribio na juhudi za watengenezaji. Biashara ilielewa kuwa mwanzoni mwa wiki baadhi ya utendaji wake hautafanya kazi. Na watengenezaji walielewa kuwa wiki ya matukio makubwa yanangojea.
Kila mtu alikuwa na hamu ya kubadilisha hali hiyo.
Matarajio kutoka kwa huduma ndogo
Suala la vipengele wakati tayari. Utoaji wa vipengele wakati tayari kwa kuoza ufumbuzi na kutenganisha taratibu tofauti.
Timu za bidhaa ndogo. Hii ni muhimu kwa sababu timu kubwa inayofanya kazi kwenye monolith ya zamani ilikuwa ngumu kusimamia. Timu kama hiyo ililazimishwa kufanya kazi kulingana na mchakato mkali, lakini walitaka ubunifu zaidi na uhuru. Ni timu ndogo tu zinaweza kumudu hii.
Kutengwa kwa huduma katika michakato tofauti. Kwa hakika, ningependa kuitenganisha kwenye vyombo, lakini idadi kubwa ya huduma zilizoandikwa katika Mfumo wa .NET zinaendeshwa chini ya WindowsHuduma zinazotegemea .NET Core sasa zinaonekana, lakini bado kuna chache kati yao.
Unyumbufu wa upelekaji. Tungependa kuchanganya huduma jinsi tunavyohitaji, na si jinsi kanuni inavyolazimisha.
Matumizi ya teknolojia mpya. Hii ni ya kuvutia kwa programu yoyote.
Matatizo ya mpito
Bila shaka, ikiwa ilikuwa rahisi kuvunja monolith katika microservices, hakutakuwa na haja ya kuzungumza juu yake kwenye mikutano na kuandika makala. Kuna mitego mingi katika mchakato huu; nitaelezea kuu ambazo zilituzuia.
Shida ya kwanza kawaida kwa monoliths nyingi: mshikamano wa mantiki ya biashara. Tunapoandika monolith, tunataka kutumia tena madarasa yetu ili tusiandike msimbo usio wa lazima. Na wakati wa kuhamia kwa huduma ndogo, hii inakuwa shida: nambari zote zimeunganishwa sana, na ni ngumu kutenganisha huduma.
Wakati wa kuanza kwa kazi, hazina ilikuwa na miradi zaidi ya 500 na mistari zaidi ya elfu 700 ya nambari. Huu ni uamuzi mkubwa kabisa na tatizo la pili. Haikuwezekana kuichukua tu na kuigawanya katika huduma ndogo.
Tatizo la tatu - ukosefu wa miundombinu muhimu. Kwa kweli, tulikuwa tunanakili msimbo wa chanzo kwa seva.
Jinsi ya kuhama kutoka monolith hadi microservices
Utoaji wa Huduma Ndogo
Kwanza, tulijiamulia mara moja kwamba mgawanyo wa huduma ndogo ni mchakato unaorudiwa. Tulihitajika kila wakati kukuza shida za biashara sambamba. Jinsi tutakavyotekeleza hili kitaalam tayari ni tatizo letu. Kwa hivyo, tulijiandaa kwa mchakato wa kurudia. Haitafanya kazi kwa njia nyingine yoyote ikiwa una programu kubwa na haiko tayari kuandikwa upya.
Je, ni njia gani tunazotumia kutenga huduma ndogo?
Njia ya kwanza - Sogeza moduli zilizopo kama huduma. Katika suala hili, tulikuwa na bahati: tayari kulikuwa na huduma zilizosajiliwa ambazo zilifanya kazi kwa kutumia itifaki ya WCF. Waligawanywa katika makusanyiko tofauti. Tuliziweka kando, na kuongeza kizindua kidogo kwa kila jengo. Iliandikwa kwa kutumia maktaba nzuri ya Topshelf, ambayo hukuruhusu kuendesha programu kama huduma na kama koni. Hii ni rahisi kwa utatuzi kwani hakuna miradi ya ziada inahitajika katika suluhisho.
Huduma ziliunganishwa kulingana na mantiki ya biashara, kwa vile walitumia makusanyiko ya kawaida na walifanya kazi na database ya kawaida. Hawakuweza kuitwa microservices katika fomu yao safi. Hata hivyo, tunaweza kutoa huduma hizi kando, katika michakato tofauti. Hii pekee ilifanya iwezekanavyo kupunguza ushawishi wao kwa kila mmoja, kupunguza tatizo na maendeleo sambamba na hatua moja ya kushindwa.
Kukusanyika na mwenyeji ni safu moja tu ya nambari katika darasa la Programu. Tulificha kazi na Topshelf katika darasa la msaidizi.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
Njia ya pili ya kugawa huduma ndogo ni: kuziunda ili kutatua matatizo mapya. Ikiwa wakati huo huo monolith haikua, hii tayari ni bora, ambayo ina maana kwamba tunasonga katika mwelekeo sahihi. Ili kutatua matatizo mapya, tulijaribu kuunda huduma tofauti. Ikiwa kulikuwa na fursa kama hiyo, basi tuliunda huduma zaidi za "kanoni" ambazo zinasimamia kabisa mfano wao wa data, hifadhidata tofauti.
Sisi, kama wengi, tulianza na huduma za uthibitishaji na uidhinishaji. Wao ni kamili kwa hili. Wao ni huru, kama sheria, wana mfano tofauti wa data. Wao wenyewe hawaingiliani na monolith, tu inageuka kwao kutatua matatizo fulani. Kutumia huduma hizi, unaweza kuanza mpito kwa usanifu mpya, kurekebisha miundombinu juu yao, jaribu baadhi ya mbinu zinazohusiana na maktaba ya mtandao, nk. Hatuna timu zozote katika shirika letu ambazo hazikuweza kuunda huduma ya uthibitishaji.
Njia ya tatu ya kutenga microservicesYule tunayotumia ni maalum kidogo kwetu. Huku ni kuondolewa kwa mantiki ya biashara kutoka kwa safu ya UI. Utumizi wetu mkuu wa UI ni eneo-kazi; ni, kama mazingira ya nyuma, imeandikwa katika C#. Wasanidi programu walifanya makosa mara kwa mara na kuhamisha sehemu za mantiki hadi kwenye Kiolesura ambacho kingepaswa kuwepo katika upande wa nyuma na kutumika tena.
Ukiangalia mfano halisi kutoka kwa msimbo wa sehemu ya UI, unaweza kuona kwamba sehemu kubwa ya suluhisho hili ina mantiki halisi ya biashara ambayo ni muhimu katika michakato mingine, sio tu kwa kuunda fomu ya UI.
Mantiki halisi ya UI iko tu katika mistari michache iliyopita. Tuliihamisha hadi kwenye seva ili iweze kutumika tena, hivyo basi kupunguza UI na kupata usanifu sahihi.
Njia ya nne na muhimu zaidi ya kutenganisha microservices, ambayo inafanya uwezekano wa kupunguza monolith, ni kuondolewa kwa huduma zilizopo na usindikaji. Tunapochukua moduli zilizopo kama zilivyo, matokeo huwa si ya kupendeza kwa wasanidi kila wakati, na mchakato wa biashara unaweza kuwa umepitwa na wakati tangu utendakazi kuundwa. Kwa kurekebisha upya, tunaweza kusaidia mchakato mpya wa biashara kwa sababu mahitaji ya biashara yanabadilika kila mara. Tunaweza kuboresha msimbo wa chanzo, kuondoa kasoro zinazojulikana, na kuunda muundo bora wa data. Kuna faida nyingi zinazopatikana.
Kutenganisha huduma kutoka kwa usindikaji kunahusishwa kwa njia isiyoweza kutenganishwa na dhana ya muktadha wenye mipaka. Hili ni wazo kutoka kwa Usanifu wa Kikoa. Inamaanisha sehemu ya muundo wa kikoa ambamo masharti yote ya lugha moja yamefafanuliwa kipekee. Hebu tuangalie muktadha wa bima na bili kama mfano. Tuna maombi ya monolithic, na tunahitaji kufanya kazi na akaunti katika bima. Tunatarajia msanidi programu kupata darasa lililopo la Akaunti katika mkusanyiko mwingine, akirejelee kutoka kwa darasa la Bima, na tutakuwa na msimbo wa kufanya kazi. Kanuni ya DRY itaheshimiwa, kazi itafanyika kwa kasi kwa kutumia kanuni zilizopo.
Matokeo yake, zinageuka kuwa mazingira ya akaunti na bima yanaunganishwa. Mahitaji mapya yanapoibuka, muunganisho huu utaingilia maendeleo, na kuongeza ugumu wa mantiki ya biashara tayari. Ili kutatua tatizo hili, unahitaji kupata mipaka kati ya mazingira katika kanuni na kuondoa ukiukwaji wao. Kwa mfano, katika muktadha wa bima, inawezekana kabisa kwamba nambari ya akaunti ya Benki Kuu yenye tarakimu 20 na tarehe ambayo akaunti ilifunguliwa itatosha.
Ili kutenganisha miktadha hii iliyowekewa mipaka kutoka kwa kila mmoja na kuanza mchakato wa kutenganisha huduma ndogo kutoka kwa suluhisho la monolithic, tulitumia mbinu kama vile kuunda API za nje ndani ya programu. Ikiwa tungejua kuwa moduli fulani inapaswa kuwa huduma ndogo, iliyorekebishwa kwa njia fulani ndani ya mchakato, basi mara moja tulipiga simu kwa mantiki ambayo ni ya muktadha mwingine mdogo kupitia simu za nje. Kwa mfano, kupitia REST au WCF.
Tuliamua kwa uthabiti kwamba hatutaepuka msimbo ambao ungehitaji miamala iliyosambazwa. Kwa upande wetu, iligeuka kuwa rahisi sana kufuata sheria hii. Bado hatujakutana na hali ambapo shughuli kali zilizosambazwa zinahitajika - uthabiti wa mwisho kati ya moduli unatosha kabisa.
Hebu tuangalie mfano maalum. Tuna wazo la orchestrator - bomba ambalo huchakata huluki ya "programu". Anaunda mteja, akaunti na kadi ya benki kwa zamu. Ikiwa mteja na akaunti zimeundwa kwa ufanisi, lakini uundaji wa kadi unashindwa, programu haihamishi kwenye hali ya "imefanikiwa" na inabaki katika hali ya "kadi haijaundwa". Katika siku zijazo, shughuli za chinichini zitaichukua na kuimaliza. Mfumo umekuwa katika hali ya kutofautiana kwa muda, lakini kwa ujumla tumeridhika na hili.
Ikiwa hali itatokea wakati inahitajika kuhifadhi sehemu ya data mara kwa mara, kuna uwezekano mkubwa kwamba tutaenda kwa ujumuishaji wa huduma ili kuichakata katika mchakato mmoja.
Wacha tuangalie mfano wa kugawa huduma ndogo. Unawezaje kuileta kwa uzalishaji kwa usalama kiasi? Katika mfano huu, tuna sehemu tofauti ya mfumo - moduli ya huduma ya malipo, moja ya sehemu za kanuni ambazo tungependa kufanya microservice.
Awali ya yote, tunaunda microservice kwa kuandika upya msimbo. Tunaboresha baadhi ya vipengele ambavyo hatukufurahishwa navyo. Tunatekeleza mahitaji mapya ya biashara kutoka kwa mteja. Tunaongeza Lango la API kwa muunganisho kati ya UI na mazingira ya nyuma, ambayo yatatoa usambazaji wa simu.
Ifuatayo, tunaachilia usanidi huu katika operesheni, lakini katika hali ya majaribio. Watumiaji wetu wengi bado wanafanya kazi na michakato ya zamani ya biashara. Kwa watumiaji wapya, tunatengeneza toleo jipya la programu ya monolithic ambayo haina mchakato huu tena. Kimsingi, tuna mchanganyiko wa monolith na huduma ndogo inayofanya kazi kama majaribio.
Kwa majaribio yaliyofaulu, tunaelewa kuwa usanidi mpya unaweza kufanya kazi, tunaweza kuondoa monolith ya zamani kutoka kwa mlinganyo na kuacha usanidi mpya badala ya suluhisho la zamani.
Kwa jumla, tunatumia karibu njia zote zilizopo za kugawanya msimbo wa chanzo wa monolith. Zote huturuhusu kupunguza ukubwa wa sehemu za programu na kuzitafsiri hadi maktaba mpya, na kutengeneza msimbo bora wa chanzo.
Kufanya kazi na hifadhidata
Database inaweza kugawanywa mbaya zaidi kuliko msimbo wa chanzo, kwa kuwa haina tu schema ya sasa, lakini pia data ya kihistoria iliyokusanywa.
Hifadhidata yetu, kama wengine wengi, ilikuwa na shida nyingine muhimu - saizi yake kubwa. Hifadhidata hii iliundwa kulingana na mantiki tata ya biashara ya monolith, na uhusiano uliokusanywa kati ya majedwali ya miktadha mbalimbali iliyo na mipaka.
Kwa upande wetu, juu ya shida zote (database kubwa, viunganisho vingi, wakati mwingine mipaka isiyo wazi kati ya meza), shida ilitokea ambayo hutokea katika miradi mingi mikubwa: matumizi ya template ya database iliyoshirikiwa. Data ilichukuliwa kutoka kwa majedwali kupitia mwonekano, kupitia urudufishaji, na kusafirishwa kwa mifumo mingine ambapo urudufishaji huu ulihitajika. Kwa hivyo, hatukuweza kusogeza majedwali kwenye schema tofauti kwa sababu yalitumika kikamilifu.
Mgawanyiko huo huo katika miktadha midogo katika msimbo hutusaidia katika utengano. Kawaida hutupatia wazo zuri la jinsi tunavyogawanya data katika kiwango cha hifadhidata. Tunaelewa ni majedwali gani ni ya muktadha mmoja uliowekwa na ambayo ni ya mwingine.
Tulitumia njia mbili za kimataifa za kugawa hifadhidata: kugawanya jedwali zilizopo na kugawanya kwa usindikaji.
Kugawanya majedwali yaliyopo ni njia nzuri ya kutumia ikiwa muundo wa data ni mzuri, unakidhi mahitaji ya biashara, na kila mtu anaifurahia. Katika kesi hii, tunaweza kutenganisha meza zilizopo kwenye schema tofauti.
Idara yenye usindikaji inahitajika wakati mtindo wa biashara umebadilika sana, na meza hazituridhishi tena.
Kugawanya meza zilizopo. Tunahitaji kuamua ni nini tutatenganisha. Bila ujuzi huu, hakuna kitu kitakachofanya kazi, na hapa mgawanyiko wa mazingira ya mipaka katika kanuni itatusaidia. Kama sheria, ikiwa unaweza kuelewa mipaka ya muktadha katika nambari ya chanzo, inakuwa wazi ni majedwali gani yanapaswa kujumuishwa kwenye orodha ya idara.
Wacha tufikirie kuwa tunayo suluhisho ambalo moduli mbili za monolith zinaingiliana na hifadhidata moja. Tunahitaji kuhakikisha kuwa moduli moja tu inaingiliana na sehemu ya meza zilizotengwa, na nyingine huanza kuingiliana nayo kupitia API. Kuanza, inatosha kwamba kurekodi tu kunafanywa kupitia API. Hii ni hali ya lazima kwa sisi kuzungumza juu ya uhuru wa microservices. Viunganisho vya kusoma vinaweza kubaki mradi hakuna shida kubwa.
Hatua inayofuata ni kwamba tunaweza kutenganisha sehemu ya msimbo ambayo inafanya kazi na meza zilizotengwa, na au bila usindikaji, kwenye huduma ndogo tofauti na kuiendesha kwa mchakato tofauti, chombo. Hii itakuwa huduma tofauti na unganisho kwenye hifadhidata ya monolith na meza hizo ambazo hazihusiani nayo moja kwa moja. Monolith bado inaingiliana kwa kusoma na sehemu inayoweza kutolewa.
Baadaye tutaondoa uunganisho huu, yaani, kusoma data kutoka kwa programu ya monolithic kutoka kwa meza zilizotengwa pia itahamishiwa kwenye API.
Ifuatayo, tutachagua kutoka kwa hifadhidata ya jumla meza ambazo huduma mpya tu inafanya kazi. Tunaweza kuhamisha majedwali kwenye schema tofauti au hata kwenye hifadhidata tofauti ya kimwili. Bado kuna muunganisho wa kusoma kati ya huduma ndogo na hifadhidata ya monolith, lakini hakuna kitu cha kuwa na wasiwasi juu, katika usanidi huu inaweza kuishi kwa muda mrefu sana.
Hatua ya mwisho ni kuondoa kabisa miunganisho yote. Katika kesi hii, tunaweza kuhitaji kuhamisha data kutoka kwa hifadhidata kuu. Wakati mwingine tunataka kutumia tena baadhi ya data au saraka zilizonakiliwa kutoka kwa mifumo ya nje katika hifadhidata kadhaa. Hii hutokea kwetu mara kwa mara.
Idara ya usindikaji. Njia hii ni sawa na ya kwanza, tu kwa mpangilio wa nyuma. Mara moja tunatenga hifadhidata mpya na huduma ndogo ndogo inayoingiliana na monolith kupitia API. Lakini wakati huo huo, kuna seti ya meza za hifadhidata ambazo tunataka kufuta katika siku zijazo. Hatuhitaji tena; tuliibadilisha kwa mtindo mpya.
Ili mpango huu ufanye kazi, huenda tukahitaji kipindi cha mpito.
Kisha kuna njia mbili zinazowezekana.
Kwanza: tunanakili data zote katika hifadhidata mpya na za zamani. Katika hali hii, tuna upungufu wa data na matatizo ya ulandanishaji yanaweza kutokea. Lakini tunaweza kuchukua wateja wawili tofauti. Moja itafanya kazi na toleo jipya, lingine na la zamani.
Pili: tunagawanya data kulingana na baadhi ya vigezo vya biashara. Kwa mfano, tulikuwa na bidhaa 5 kwenye mfumo ambazo zilihifadhiwa kwenye hifadhidata ya zamani. Tunaweka ya sita ndani ya kazi mpya ya biashara katika hifadhidata mpya. Lakini tutahitaji Lango la API ambalo litasawazisha data hii na kuonyesha mteja wapi na nini cha kupata kutoka.
Njia zote mbili zinafanya kazi, chagua kulingana na hali hiyo.
Baada ya kuwa na uhakika kwamba kila kitu kinafanya kazi, sehemu ya monolith inayofanya kazi na miundo ya zamani ya hifadhidata inaweza kuzimwa.
Hatua ya mwisho ni kuondoa miundo ya data ya zamani.
Kwa muhtasari, tunaweza kusema kwamba tuna shida na hifadhidata: ni ngumu kufanya kazi nayo ikilinganishwa na nambari ya chanzo, ni ngumu zaidi kushiriki, lakini inaweza na inapaswa kufanywa. Tumepata baadhi ya njia zinazoturuhusu kufanya hivi kwa usalama kabisa, lakini bado ni rahisi kufanya makosa na data kuliko kutumia msimbo wa chanzo.
Kufanya kazi na msimbo wa chanzo
Hivi ndivyo mchoro wa msimbo wa chanzo ulionekana tulipoanza kuchambua mradi wa monolithic.
Inaweza kugawanywa katika tabaka tatu. Hii ni safu ya moduli zilizozinduliwa, programu-jalizi, huduma na shughuli za kibinafsi. Kwa kweli, haya yalikuwa pointi za kuingia ndani ya suluhisho la monolithic. Zote zilifungwa vizuri na safu ya Pamoja. Ilikuwa na mantiki ya biashara ambayo huduma zilishiriki na miunganisho mingi. Kila huduma na programu-jalizi zilitumia hadi makusanyiko 10 au zaidi ya kawaida, kulingana na saizi yao na dhamiri ya watengenezaji.
Tulikuwa na bahati ya kuwa na maktaba ya miundombinu ambayo inaweza kutumika tofauti.
Wakati mwingine hali ilitokea wakati baadhi ya vitu vya kawaida havikuwa vya safu hii, lakini vilikuwa maktaba ya miundombinu. Hili lilitatuliwa kwa kubadilisha jina.
Wasiwasi mkubwa zaidi ulikuwa muktadha wa mipaka. Ilifanyika kwamba mazingira 3-4 yalichanganywa katika mkutano mmoja wa Kawaida na kutumika kila mmoja ndani ya kazi sawa za biashara. Ilikuwa ni lazima kuelewa ni wapi hii inaweza kugawanywa na kwa mipaka gani, na nini cha kufanya baadaye na kuchora mgawanyiko huu katika mkusanyiko wa msimbo wa chanzo.
Tumeunda sheria kadhaa za mchakato wa kugawanya msimbo.
kwanza: Hatukutaka tena kushiriki mantiki ya biashara kati ya huduma, shughuli na programu-jalizi. Tulitaka kufanya mantiki ya biashara kuwa huru ndani ya huduma ndogo ndogo. Huduma ndogo, kwa upande mwingine, hufikiriwa kama huduma ambazo zipo kwa kujitegemea kabisa. Ninaamini kuwa mbinu hii ni ya kupoteza kiasi, na ni vigumu kufikia, kwa sababu, kwa mfano, huduma katika C # kwa hali yoyote itaunganishwa na maktaba ya kawaida. Mfumo wetu umeandikwa kwa C#; bado hatujatumia teknolojia zingine. Kwa hiyo, tuliamua kwamba tunaweza kumudu kutumia makusanyiko ya kawaida ya kiufundi. Jambo kuu ni kwamba hawana vipande vya mantiki ya biashara. Ikiwa una karatasi ya urahisi juu ya ORM unayotumia, basi kunakili kutoka huduma hadi huduma ni ghali sana.
Timu yetu ni shabiki wa muundo unaoendeshwa na kikoa, kwa hivyo usanifu wa vitunguu ulitufaa sana. Msingi wa huduma zetu sio safu ya ufikiaji wa data, lakini mkusanyiko wenye mantiki ya kikoa, ambayo ina mantiki ya biashara pekee na haina miunganisho na miundombinu. Wakati huo huo, tunaweza kujitegemea kurekebisha mkusanyiko wa kikoa ili kutatua matatizo yanayohusiana na mifumo.
Katika hatua hii tulikutana na shida yetu ya kwanza kubwa. Huduma ilibidi irejelee mkusanyiko wa kikoa kimoja, tulitaka kufanya mantiki kuwa huru, na kanuni ya KAVU ilituzuia sana hapa. Waendelezaji walitaka kutumia tena madarasa kutoka kwa makusanyiko ya jirani ili kuepuka kurudia, na kwa sababu hiyo, vikoa vilianza kuunganishwa pamoja tena. Tulichambua matokeo na tukaamua kuwa labda shida pia iko katika eneo la kifaa cha kuhifadhi nambari ya chanzo. Tulikuwa na hazina kubwa iliyo na msimbo wote wa chanzo. Suluhisho la mradi mzima lilikuwa gumu sana kukusanyika kwenye mashine ya ndani. Kwa hivyo, suluhisho ndogo tofauti ziliundwa kwa sehemu za mradi, na hakuna mtu aliyekataza kuongeza mkusanyiko wa kawaida au kikoa kwao na kuzitumia tena. Zana pekee ambayo haikuturuhusu kufanya hivi ilikuwa ukaguzi wa msimbo. Lakini wakati mwingine pia ilishindwa.
Kisha tukaanza kuhamia kwa mfano na hifadhi tofauti. Mantiki ya biashara haitokani tena na huduma hadi huduma, vikoa vimekuwa huru. Miktadha yenye mipaka inaungwa mkono kwa uwazi zaidi. Je, tunatumiaje tena maktaba za miundombinu? Tuliwatenganisha kwenye hifadhi tofauti, kisha tukawaweka kwenye vifurushi vya Nuget, ambavyo tunaweka kwenye Artifactory. Kwa mabadiliko yoyote, mkusanyiko na uchapishaji hutokea moja kwa moja.
Huduma zetu zilianza kurejelea vifurushi vya miundombinu ya ndani kwa njia sawa na za nje. Tunapakua maktaba za nje kutoka Nuget. Kufanya kazi na Artifactory, ambapo tuliweka vifurushi hivi, tulitumia wasimamizi wawili wa mfuko. Katika hazina ndogo pia tulitumia Nuget. Katika hazina zilizo na huduma nyingi, tulitumia Paket, ambayo hutoa uthabiti wa toleo zaidi kati ya moduli.
Kwa hivyo, kwa kufanya kazi kwenye msimbo wa chanzo, kubadilisha kidogo usanifu na kutenganisha hazina, tunafanya huduma zetu kuwa huru zaidi.
Matatizo ya miundombinu
Hasara nyingi za kuhamia huduma ndogo ni zinazohusiana na miundombinu. Utahitaji kupelekwa kiotomatiki, utahitaji maktaba mpya ili kuendesha miundombinu.
Ufungaji wa mwongozo katika mazingira
Hapo awali, tuliweka suluhisho la mazingira kwa mikono. Ili kuharakisha mchakato huu, tuliunda bomba la CI/CD. Tulichagua mchakato endelevu wa uwasilishaji kwa sababu utumaji unaoendelea bado haukubaliki kwetu kutoka kwa mtazamo wa michakato ya biashara. Kwa hiyo, kutuma kwa uendeshaji unafanywa kwa kutumia kifungo, na kwa kupima - moja kwa moja.
Tunatumia Atlassian, Bitbucket kwa uhifadhi wa msimbo wa chanzo na mianzi kwa ujenzi. Tunapenda kuandika maandishi ya ujenzi katika Keki kwa sababu ni sawa na C #. Vifurushi vilivyotengenezwa tayari huja kwa Artifactory, na Ansible hufika kiotomatiki kwa seva za majaribio, baada ya hapo zinaweza kujaribiwa mara moja.
Ukataji miti tofauti
Wakati mmoja, mojawapo ya mawazo ya monolith ilikuwa kutoa magogo ya pamoja. Pia tulihitaji kuelewa nini cha kufanya na kumbukumbu za kibinafsi zilizo kwenye diski. Kumbukumbu zetu zimeandikwa kwa faili za maandishi. Tuliamua kutumia stack ya kawaida ya ELK. Hatukuandika kwa ELK moja kwa moja kupitia watoa huduma, lakini tuliamua kwamba tutakamilisha kumbukumbu za maandishi na kuandika kitambulisho cha ufuatiliaji ndani yao kama kitambulisho, na kuongeza jina la huduma, ili kumbukumbu hizi ziweze kuchanganuliwa baadaye.
Kwa kutumia Filebeat tunaweza kukusanya kumbukumbu zetu kutoka seva, kisha zibadilishe, tumia Kibana kujenga hoja katika kiolesura cha mtumiaji, na uone jinsi simu ilivyoelekezwa kati ya huduma. Vitambulisho vya ufuatiliaji vinasaidia sana kwa hili.
Huduma zinazohusiana na majaribio na utatuzi
Hapo awali, hatukuelewa kikamilifu jinsi ya kutatua huduma zinazotengenezwa. Kila kitu kilikuwa rahisi na monolith; tuliendesha kwenye mashine ya ndani. Mara ya kwanza walijaribu kufanya hivyo na microservices, lakini wakati mwingine ili kuzindua kikamilifu microservice moja unahitaji kuzindua wengine kadhaa, na hii ni mbaya. Tuligundua kuwa tunahitaji kuhamia kwa modeli ambapo tunaacha kwenye mashine ya karibu tu huduma au huduma ambazo tunataka kutatua. Huduma zilizosalia hutumiwa kutoka kwa seva zinazolingana na usanidi na prod. Baada ya kurekebisha, wakati wa kupima, kwa kila kazi, huduma zilizobadilishwa tu hutolewa kwa seva ya mtihani. Kwa hivyo, suluhisho linajaribiwa kwa namna ambayo itaonekana katika uzalishaji katika siku zijazo.
Kuna seva zinazoendesha matoleo ya uzalishaji wa huduma pekee. Seva hizi zinahitajika katika kesi ya matukio, kuangalia utoaji kabla ya kupelekwa na kwa mafunzo ya ndani.
Tumeongeza mchakato wa majaribio ya kiotomatiki kwa kutumia maktaba maarufu ya Specflow. Majaribio huendeshwa kiotomatiki kwa kutumia NUnit mara tu baada ya kutumwa kutoka kwa Ansible. Ikiwa chanjo ya kazi ni moja kwa moja, basi hakuna haja ya kupima mwongozo. Ingawa wakati mwingine majaribio ya ziada ya mwongozo bado yanahitajika. Tunatumia lebo katika Jira ili kubaini ni majaribio gani ya kufanya kwa suala mahususi.
Kwa kuongezea, hitaji la upimaji wa mzigo limeongezeka; hapo awali ilifanywa tu katika hali nadra. Tunatumia JMeter kufanya majaribio, InfluxDB kuyahifadhi, na Grafana kuunda mchakato wa grafu.
Tumefanikiwa nini?
Kwanza, tuliondoa dhana ya "kutolewa". Matoleo ya kutisha ya miezi miwili yamepita wakati kola hii ilitumwa katika mazingira ya uzalishaji, na kutatiza michakato ya biashara kwa muda. Sasa tunasambaza huduma kwa wastani kila baada ya siku 1,5, tukiziweka katika vikundi kwa sababu zinaanza kufanya kazi baada ya kuidhinishwa.
Hakuna kushindwa mbaya katika mfumo wetu. Ikiwa tutatoa huduma ndogo na mdudu, basi utendakazi unaohusishwa nayo utavunjwa, na utendakazi mwingine wote hautaathirika. Hii inaboresha sana uzoefu wa mtumiaji.
Tunaweza kudhibiti muundo wa uwekaji. Unaweza kuchagua vikundi vya huduma tofauti na suluhisho lingine, ikiwa ni lazima.
Aidha, tumepunguza tatizo kwa kiasi kikubwa kwa foleni kubwa ya maboresho. Sasa tuna timu tofauti za bidhaa zinazofanya kazi na baadhi ya huduma kwa kujitegemea. Mchakato wa Scrum tayari unafaa hapa. Timu mahususi inaweza kuwa na Mmiliki tofauti wa Bidhaa ambaye huikabidhi majukumu.
Muhtasari
- Microservices zinafaa kwa ajili ya kuoza mifumo tata. Katika mchakato huo, tunaanza kuelewa ni nini katika mfumo wetu, ni mazingira gani yenye ukomo, ambapo mipaka yao iko. Hii hukuruhusu kusambaza kwa usahihi maboresho kati ya moduli na kuzuia kuchanganyikiwa kwa nambari.
- Microservices hutoa faida za shirika. Mara nyingi huzungumzwa tu kama usanifu, lakini usanifu wowote unahitajika kutatua mahitaji ya biashara, na sio peke yake. Kwa hiyo, tunaweza kusema kwamba huduma ndogo zinafaa kwa ajili ya kutatua matatizo katika timu ndogo, kutokana na kwamba Scrum ni maarufu sana sasa.
- Kutengana ni mchakato unaorudiwa. Huwezi kuchukua programu na kuigawanya tu katika huduma ndogo. Bidhaa inayotokana haiwezekani kufanya kazi. Wakati wa kuweka wakfu huduma ndogo, ni vyema kuandika upya urithi uliopo, yaani, kuugeuza kuwa msimbo tunaopenda na kukidhi vyema mahitaji ya biashara katika masuala ya utendakazi na kasi.
Tahadhari ndogo: Gharama za kuhamia microservices ni kubwa sana. Ilichukua muda mrefu kutatua tatizo la miundombinu pekee. Kwa hivyo ikiwa una programu ndogo ambayo haihitaji kuongeza kiwango mahususi, isipokuwa kama una idadi kubwa ya wateja wanaoshindania umakini na wakati wa timu yako, basi huduma ndogo zinaweza zisiwe kile unachohitaji leo. Ni ghali kabisa. Ikiwa unapoanza mchakato na microservices, basi gharama zitakuwa za juu zaidi kuliko ukianza mradi huo huo na maendeleo ya monolith.
PS Hadithi ya kihemko zaidi (na kana kwamba kwako kibinafsi) - kulingana na .
Hili hapa ni toleo kamili la ripoti.
Chanzo: mapenzi.com
