Inaonekana kwamba uga wa utangazaji mtandaoni unapaswa kuwa wa hali ya juu wa kiteknolojia na wa kiotomatiki iwezekanavyo. Kwa kweli, kwa sababu makubwa na wataalam katika uwanja wao kama Yandex, Mail.Ru, Google na Facebook hufanya kazi huko. Lakini, kama ilivyotokea, hakuna kikomo kwa ukamilifu na daima kuna kitu cha kujiendesha.
Kikundi cha mawasiliano Mtandao wa Dentsu Aegis Urusi ndiye mdau mkubwa zaidi katika soko la utangazaji wa kidijitali na anawekeza kikamilifu katika teknolojia, akijaribu kuboresha na kuelekeza michakato yake ya biashara kiotomatiki. Moja ya matatizo ambayo hayajatatuliwa ya soko la utangazaji mtandaoni imekuwa kazi ya kukusanya takwimu za kampeni za utangazaji kutoka kwa majukwaa tofauti ya mtandao. Suluhisho la tatizo hili hatimaye lilisababisha kuundwa kwa bidhaa D1.Dijitali (soma kama DiVan), maendeleo ambayo tunataka kuzungumzia.
Kwa nini?
1. Wakati wa kuanza kwa mradi huo, hapakuwa na bidhaa moja iliyopangwa tayari kwenye soko ambayo ilitatua tatizo la otomatiki ukusanyaji wa takwimu kwenye kampeni za matangazo. Hii ina maana kwamba hakuna mtu isipokuwa sisi wenyewe atakayekidhi mahitaji yetu.
Huduma kama vile Improvado, Roistat, Supermetrics, SegmentStream hutoa ushirikiano na majukwaa, mitandao ya kijamii na Google Anaalitycs, na pia hurahisisha kuunda dashibodi za uchanganuzi kwa uchanganuzi rahisi na udhibiti wa kampeni za utangazaji. Kabla ya kuanza kutengeneza bidhaa zetu, tulijaribu kutumia baadhi ya mifumo hii kukusanya data kutoka kwa tovuti, lakini, kwa bahati mbaya, haikuweza kutatua matatizo yetu.
Tatizo kuu lilikuwa kwamba bidhaa zilizojaribiwa zilitegemea vyanzo vya data, kuonyesha takwimu za uwekaji kulingana na tovuti, na hazikutoa uwezo wa kujumlisha takwimu za kampeni za utangazaji. Mbinu hii haikuturuhusu kuona takwimu kutoka tovuti tofauti katika sehemu moja na kuchambua hali ya kampeni kwa ujumla wake.
Sababu nyingine ni kwamba katika hatua za awali bidhaa zililenga soko la Magharibi na hazikuunga mkono ushirikiano na maeneo ya Kirusi. Na kwa tovuti hizo ambazo ushirikiano ulitekelezwa, metrics zote muhimu hazikupakuliwa kila wakati kwa maelezo ya kutosha, na ushirikiano haukuwa rahisi kila wakati na uwazi, hasa wakati ilikuwa ni lazima kupata kitu ambacho si katika interface ya mfumo.
Kwa ujumla, tuliamua kutozoea bidhaa za wahusika wengine, lakini tulianza kukuza yetu ...
2. Soko la matangazo ya mtandaoni linakua mwaka hadi mwaka, na mwaka wa 2018, kwa mujibu wa bajeti za utangazaji, ilishinda soko kubwa la jadi la matangazo ya TV. Kwa hivyo kuna mizani.
3. Tofauti na soko la matangazo ya TV, ambapo uuzaji wa utangazaji wa biashara umetawaliwa, kuna wamiliki wengi binafsi wa hesabu ya matangazo ya ukubwa mbalimbali wanaofanya kazi kwenye mtandao na akaunti zao za matangazo. Kwa kuwa kampeni ya matangazo, kama sheria, inaendesha kwenye tovuti kadhaa mara moja, ili kuelewa hali ya kampeni ya matangazo, ni muhimu kukusanya ripoti kutoka kwa tovuti zote na kuzichanganya katika ripoti moja kubwa ambayo itaonyesha picha nzima. Hii inamaanisha kuwa kuna uwezekano wa uboreshaji.
4. Ilionekana kwetu kuwa wamiliki wa hesabu za utangazaji kwenye Mtandao tayari wana miundombinu ya kukusanya takwimu na kuzionyesha katika akaunti za matangazo, na wataweza kutoa API kwa data hii. Hii ina maana kwamba inawezekana kitaalam kuitekeleza. Wacha tuseme mara moja kwamba iligeuka kuwa sio rahisi sana.
Kwa ujumla, sharti zote za utekelezaji wa mradi huo zilikuwa dhahiri kwetu, na tulikimbia kuleta mradi uzima ...
Mpango mkuu
Kuanza, tuliunda maono ya mfumo bora:
- Kampeni za utangazaji kutoka kwa mfumo wa ushirika wa 1C zinapaswa kupakiwa kiotomatiki ndani yake na majina yao, vipindi, bajeti na uwekaji kwenye mifumo mbalimbali.
- Kwa kila uwekaji ndani ya kampeni ya utangazaji, takwimu zote zinazowezekana zinapaswa kupakuliwa kiotomatiki kutoka kwa tovuti ambazo uwekaji unafanyika, kama vile idadi ya maonyesho, mibofyo, maoni, n.k.
- Baadhi ya kampeni za utangazaji hufuatiliwa kwa kutumia ufuatiliaji wa wahusika wengine na ile inayoitwa mifumo ya utangazaji kama vile Adriver, Weborama, DCM, n.k. Pia kuna mita ya mtandao ya viwanda nchini Urusi - kampuni ya Mediascope. Kulingana na mpango wetu, data kutoka kwa ufuatiliaji wa kujitegemea na wa kiviwanda inapaswa pia kupakiwa kiotomatiki kwenye kampeni zinazolingana za utangazaji.
- Kampeni nyingi za utangazaji kwenye Mtandao zinalenga hatua fulani lengwa (kununua, kupiga simu, kujiandikisha kwa hifadhi ya majaribio, n.k.), ambazo hufuatiliwa kwa kutumia Google Analytics, na takwimu ambazo pia ni muhimu kwa kuelewa hali ya kampeni na. inapaswa kupakiwa kwenye chombo chetu.
Jambo la kwanza ni chungu
Kwa kuzingatia kujitolea kwetu kwa kanuni zinazonyumbulika za uundaji wa programu (agile, vitu vyote), tuliamua kwanza kuunda MVP na kisha kuelekea lengo lililokusudiwa mara kwa mara.
Tuliamua kuunda MVP kulingana na bidhaa zetu DANBo (Bodi ya Mtandao ya Dentsu Aegis), ambayo ni programu ya wavuti yenye maelezo ya jumla juu ya kampeni za utangazaji za wateja wetu.
Kwa MVP, mradi umerahisishwa iwezekanavyo katika suala la utekelezaji. Tumechagua orodha ndogo ya majukwaa ya kuunganishwa. Haya yalikuwa majukwaa makuu, kama vile Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, na mifumo kuu ya utangazaji Adriver na Weborama.
Ili kufikia takwimu kwenye tovuti kupitia API, tulitumia akaunti moja. Msimamizi wa kikundi cha mteja ambaye alitaka kutumia mkusanyiko otomatiki wa takwimu kwenye kampeni ya utangazaji alilazimika kwanza kukabidhi ufikiaji wa kampeni zinazohitajika za utangazaji kwenye tovuti kwenye akaunti ya jukwaa.
Ifuatayo ni mtumiaji wa mfumo DANBo ilibidi kupakia faili ya umbizo fulani kwenye mfumo wa Excel, ambao ulikuwa na taarifa zote kuhusu uwekaji (kampeni ya matangazo, jukwaa, muundo, muda wa uwekaji, viashiria vilivyopangwa, bajeti, n.k.) na vitambulisho vya kampeni zinazolingana za utangazaji kwenye tovuti na vihesabio katika mifumo ya utangazaji.
Ilionekana, kusema ukweli, ya kutisha:
Data iliyopakuliwa ilihifadhiwa kwenye hifadhidata, na kisha huduma tofauti zilikusanya vitambulishi vya kampeni kwenye tovuti kutoka kwao na kupakua takwimu juu yao.
Kwa kila tovuti, huduma tofauti ya windows iliandikwa, ambayo mara moja kwa siku iliingia chini ya akaunti moja ya huduma katika API ya tovuti na kupakuliwa takwimu za vitambulisho maalum vya kampeni. Kitu kimoja kilifanyika kwa mifumo ya kutangaza.
Data iliyopakuliwa ilionyeshwa kwenye kiolesura katika mfumo wa dashibodi ndogo maalum:
Bila kutarajia, MVP ilianza kufanya kazi na ikaanza kupakua takwimu za sasa za kampeni za utangazaji kwenye Mtandao. Tulitekeleza mfumo kwa wateja kadhaa, lakini tulipojaribu kuongeza kiwango, tulikumbana na matatizo makubwa:
- Shida kuu ilikuwa ugumu wa kuandaa data kwa upakiaji kwenye mfumo. Pia, data ya uwekaji ilibidi ibadilishwe hadi umbizo lililowekwa madhubuti kabla ya kupakia. Ilihitajika kujumuisha vitambulisho vya huluki kutoka tovuti tofauti kwenye faili ya upakuaji. Tunakabiliwa na ukweli kwamba ni vigumu sana kwa watumiaji wasio na ujuzi wa kiufundi kuelezea wapi kupata vitambulisho hivi kwenye tovuti na wapi kwenye faili wanahitaji kuingizwa. Kwa kuzingatia idadi ya wafanyikazi katika idara zinazoendesha kampeni kwenye tovuti na mauzo, hii ilisababisha msaada mkubwa kwa upande wetu, ambao hatukufurahishwa nao.
- Tatizo jingine lilikuwa kwamba si mifumo yote ya utangazaji ilikuwa na mbinu za kukabidhi ufikiaji wa kampeni za utangazaji kwa akaunti zingine. Lakini hata kama utaratibu wa utume ulipatikana, si watangazaji wote waliokuwa tayari kutoa ufikiaji wa kampeni zao kwa akaunti za watu wengine.
- Jambo muhimu lilikuwa ni hasira ambayo iliamsha kati ya watumiaji na ukweli kwamba viashiria vyote vilivyopangwa na maelezo ya uwekaji ambayo tayari wanaingia kwenye mfumo wetu wa uhasibu wa 1C, lazima waingie tena. DANBo.
Hii ilitupa wazo kwamba chanzo kikuu cha habari kuhusu uwekaji kinapaswa kuwa mfumo wetu wa 1C, ambamo data yote huingizwa kwa usahihi na kwa wakati (wazo hapa ni kwamba ankara hutolewa kulingana na data ya 1C, kwa hivyo uingizaji sahihi wa data kwenye 1C. ni kipaumbele kwa kila mtu KPI). Hivi ndivyo dhana mpya ya mfumo ilivyoibuka...
Dhana
Jambo la kwanza tuliamua kufanya ni kutenganisha mfumo wa kukusanya takwimu kwenye kampeni za utangazaji kwenye Mtandao kuwa bidhaa tofauti - D1.Dijitali.
Katika dhana mpya, tuliamua kupakia ndani D1.Dijitali taarifa juu ya kampeni za utangazaji na uwekaji ndani yake kutoka 1C, na kisha kutoa takwimu kutoka kwa tovuti na mifumo ya AdServing hadi kwenye nafasi hizi. Hii ilitakiwa kurahisisha maisha kwa watumiaji (na, kama kawaida, kuongeza kazi zaidi kwa watengenezaji) na kupunguza kiwango cha usaidizi.
Tatizo la kwanza tulilokumbana nalo lilikuwa la hali ya shirika na lilihusiana na ukweli kwamba hatukuweza kupata ufunguo au ishara ambayo kwayo tungeweza kulinganisha huluki kutoka mifumo tofauti na kampeni na uwekaji kutoka 1C. Ukweli ni kwamba mchakato katika kampuni yetu umeundwa kwa namna ambayo kampeni za matangazo zinaingizwa katika mifumo tofauti na watu tofauti (wapangaji wa vyombo vya habari, kununua, nk).
Ili kutatua tatizo hili, ilitubidi kuvumbua ufunguo wa kipekee wa heshi, DANBoID, ambao ungeunganisha huluki katika mifumo tofauti pamoja, na ambao unaweza kutambuliwa kwa urahisi na kipekee katika seti za data zilizopakuliwa. Kitambulisho hiki kinatolewa katika mfumo wa ndani wa 1C kwa kila uwekaji wa mtu binafsi na huhamishiwa kwenye kampeni, uwekaji na vihesabio kwenye tovuti zote na katika mifumo yote ya AdServing. Utekelezaji wa mazoea ya kuweka DANBoID katika nafasi zote ulichukua muda, lakini tuliweza kuifanya :)
Kisha tukagundua kuwa sio tovuti zote zilizo na API ya kukusanya takwimu kiotomatiki, na hata zile ambazo zina API, hairudishi data zote muhimu.
Katika hatua hii, tuliamua kupunguza kwa kiasi kikubwa orodha ya majukwaa ya kuunganishwa na kuzingatia majukwaa makuu ambayo yanahusika katika idadi kubwa ya kampeni za utangazaji. Orodha hii inajumuisha wachezaji wote wakubwa kwenye soko la utangazaji (Google, Yandex, Mail.ru), mitandao ya kijamii (VK, Facebook, Twitter), mifumo kuu ya AdServing na analytics (DCM, Adriver, Weborama, Google Analytics) na majukwaa mengine.
Tovuti nyingi tulizochagua zilikuwa na API inayotoa vipimo tulivyohitaji. Katika hali ambapo hapakuwa na API au haikuwa na data inayohitajika, tulitumia ripoti ambazo zilitumwa kila siku kwa barua pepe ya ofisi yetu ili kupakia data (katika baadhi ya mifumo inawezekana kusanidi ripoti kama hizo, katika mingine tulikubaliana juu ya maendeleo ya ripoti kama hizo kwa ajili yetu).
Wakati wa kuchambua data kutoka kwa tovuti tofauti, tuligundua kuwa uongozi wa vyombo haufanani katika mifumo tofauti. Kwa kuongeza, habari inahitaji kupakuliwa kwa undani tofauti kutoka kwa mifumo tofauti.
Ili kutatua tatizo hili, dhana ya SubDANBoID ilitengenezwa. Wazo la SubDANBoID ni rahisi sana, tunatia alama huluki kuu ya kampeni kwenye tovuti na DANBoID iliyotolewa, na tunapakia huluki zote zilizowekwa na vitambulisho vya kipekee vya tovuti na kuunda SubDANBoID kulingana na kanuni ya DANBoID + kitambulisho cha kiwango cha kwanza. huluki iliyoorodheshwa + kitambulisho cha huluki iliyofurushwa ya kiwango cha pili +... Mbinu hii ilituruhusu kuunganisha kampeni za utangazaji katika mifumo tofauti na kupakua takwimu za kina kuzihusu.
Pia tulilazimika kutatua tatizo la upatikanaji wa kampeni kwenye majukwaa tofauti. Kama tulivyoandika hapo juu, utaratibu wa kukabidhi ufikiaji wa kampeni kwa akaunti tofauti ya kiufundi hautumiki kila wakati. Kwa hivyo, tulilazimika kuunda muundo msingi wa uidhinishaji kiotomatiki kupitia OAuth kwa kutumia tokeni na mbinu za kusasisha tokeni hizi.
Baadaye katika makala tutajaribu kuelezea kwa undani zaidi usanifu wa suluhisho na maelezo ya kiufundi ya utekelezaji.
Usanifu wa suluhisho 1.0
Wakati wa kuanza utekelezaji wa bidhaa mpya, tulielewa kwamba mara moja tulihitaji kutoa uwezekano wa kuunganisha maeneo mapya, kwa hiyo tuliamua kufuata njia ya usanifu wa microservice.
Wakati wa kubuni usanifu, tulitenganisha viunganishi kwa mifumo yote ya nje - 1C, majukwaa ya utangazaji na mifumo ya utangazaji - katika huduma tofauti.
Wazo kuu ni kwamba viunganishi vyote vya tovuti vina API sawa na ni adapta zinazoleta API ya tovuti kwenye kiolesura kinachotufaa.
Katikati ya bidhaa zetu ni programu ya wavuti, ambayo ni monolith ambayo imeundwa kwa njia ambayo inaweza kugawanywa kwa urahisi katika huduma. Programu hii ina jukumu la kuchakata data iliyopakuliwa, kukusanya takwimu kutoka kwa mifumo tofauti na kuziwasilisha kwa watumiaji wa mfumo.
Ili kuwasiliana kati ya viunganishi na programu ya wavuti, tulilazimika kuunda huduma ya ziada, ambayo tuliiita Wakala wa Kiunganishi. Hufanya kazi za Ugunduzi wa Huduma na Kiratibu Kazi. Huduma hii huendesha kazi za kukusanya data kwa kila kiunganishi kila usiku. Kuandika safu ya huduma ilikuwa rahisi zaidi kuliko kuunganisha wakala wa ujumbe, na kwetu ilikuwa muhimu kupata matokeo haraka iwezekanavyo.
Kwa unyenyekevu na kasi ya maendeleo, tuliamua pia kuwa huduma zote zitakuwa API za Wavuti. Hii ilifanya iwezekane kukusanya haraka uthibitisho wa dhana na kuthibitisha kuwa muundo mzima unafanya kazi.
Kazi tofauti, ngumu zaidi ilikuwa kuweka ufikiaji wa kukusanya data kutoka kwa akaunti tofauti, ambayo, kama tulivyoamua, inapaswa kutekelezwa na watumiaji kupitia kiolesura cha wavuti. Inajumuisha hatua mbili tofauti: kwanza, mtumiaji anaongeza ishara ili kufikia akaunti kupitia OAuth, na kisha kusanidi mkusanyiko wa data kwa mteja kutoka kwa akaunti maalum. Kupata tokeni kupitia OAuth ni muhimu kwa sababu, kama tulivyokwisha andika, si rahisi kila mara kukabidhi uwezo wa kufikia akaunti unayotaka kwenye tovuti.
Ili kuunda utaratibu wa wote wa kuchagua akaunti kutoka kwa tovuti, ilitubidi kuongeza mbinu kwenye API ya viunganishi ambayo hurejesha JSON Schema, ambayo hutolewa katika fomu kwa kutumia kijenzi kilichorekebishwa cha JSONEditor. Kwa njia hii, watumiaji waliweza kuchagua akaunti ambazo wanaweza kupakua data.
Ili kuzingatia mipaka ya ombi iliyopo kwenye tovuti, tunachanganya maombi ya mipangilio ndani ya tokeni moja, lakini tunaweza kuchakata tokeni tofauti kwa sambamba.
Tulichagua MongoDB kama hifadhi ya data iliyopakiwa kwa programu ya wavuti na viunganishi, ambayo ilituruhusu kutokuwa na wasiwasi sana kuhusu muundo wa data katika hatua za awali za uundaji, wakati muundo wa kifaa cha programu hubadilika kila siku nyingine.
Hivi karibuni tuligundua kuwa sio data zote zinazofaa katika MongoDB na, kwa mfano, ni rahisi zaidi kuhifadhi takwimu za kila siku katika hifadhidata ya uhusiano. Kwa hivyo, kwa viunganishi ambavyo muundo wa data unafaa zaidi kwa hifadhidata ya uhusiano, tulianza kutumia PostgreSQL au Seva ya MS SQL kama hifadhi.
Usanifu na teknolojia zilizochaguliwa zilituruhusu kujenga na kuzindua bidhaa ya D1.Digital kwa haraka kiasi. Zaidi ya miaka miwili ya ukuzaji wa bidhaa, tulitengeneza viunganishi 23 vya tovuti, tulipata uzoefu muhimu sana wa kufanya kazi na API za wahusika wengine, tukajifunza kuepuka mitego ya tovuti tofauti, ambazo kila moja zilikuwa na zake, zilichangia maendeleo ya API ya angalau 3. tovuti, zilizopakuliwa kiotomatiki habari kuhusu kampeni karibu 15 na kwa uwekaji zaidi ya 000, zilikusanya maoni mengi kutoka kwa watumiaji juu ya uendeshaji wa bidhaa na imeweza kubadilisha mchakato kuu wa bidhaa mara kadhaa, kulingana na maoni haya.
Usanifu wa suluhisho 2.0
Miaka miwili imepita tangu kuanza kwa maendeleo D1.Dijitali. Kuongezeka kwa mara kwa mara kwa mzigo kwenye mfumo na kuibuka kwa vyanzo vipya zaidi vya data hatua kwa hatua kulionyesha matatizo katika usanifu wa ufumbuzi uliopo.
Tatizo la kwanza linahusiana na kiasi cha data iliyopakuliwa kutoka kwa tovuti. Tulikabiliwa na ukweli kwamba kukusanya na kusasisha data zote muhimu kutoka kwa tovuti kubwa zilianza kuchukua muda mwingi. Kwa mfano, kukusanya data kutoka kwa mfumo wa matangazo wa AdRiver, ambao tunafuatilia takwimu za nafasi nyingi, huchukua takriban saa 12.
Ili kutatua tatizo hili, tulianza kutumia kila aina ya ripoti ili kupakua data kutoka kwa tovuti, tunajaribu kuendeleza API zao pamoja na tovuti ili kasi ya uendeshaji wake ikidhi mahitaji yetu, na kusawazisha upakuaji wa data iwezekanavyo.
Tatizo jingine linahusiana na usindikaji wa data iliyopakuliwa. Sasa, takwimu mpya za uwekaji zinapowasili, mchakato wa hatua nyingi wa kukokotoa upya vipimo huzinduliwa, unaojumuisha kupakia data ghafi, kukokotoa vipimo vilivyojumlishwa kwa kila tovuti, kulinganisha data kutoka vyanzo tofauti na kila kimoja na kingine, na kukokotoa vipimo vya muhtasari wa kampeni. Hii husababisha mzigo mwingi kwenye programu ya wavuti ambayo hufanya mahesabu yote. Mara kadhaa, wakati wa mchakato wa kuhesabu upya, programu ilitumia kumbukumbu yote kwenye seva, kuhusu GB 10-15, ambayo ilikuwa na athari mbaya zaidi kwa kazi ya watumiaji na mfumo.
Matatizo yaliyotambuliwa na mipango kabambe ya maendeleo zaidi ya bidhaa ilituongoza kwenye hitaji la kufikiria upya usanifu wa maombi.
Tulianza na viunganishi.
Tuligundua kuwa viunganisho vyote vinafanya kazi kulingana na mfano huo, kwa hivyo tukaunda mfumo wa bomba ambalo ili kuunda kiunganishi ulilazimika kupanga mantiki ya hatua, iliyobaki ilikuwa ya ulimwengu wote. Ikiwa kiunganishi kinahitaji uboreshaji, basi tunaihamisha mara moja kwenye mfumo mpya wakati huo huo kiunganishi kinaboreshwa.
Wakati huo huo, tulianza kupeleka viunganishi kwa Docker na Kubernetes.
Tulipanga kuhamia Kubernetes kwa muda mrefu sana, tulijaribu mipangilio ya CI/CD, lakini tulianza kusonga tu wakati kiunganishi kimoja, kwa sababu ya hitilafu, kilianza kula zaidi ya 20 GB ya kumbukumbu kwenye seva, na kuua michakato mingine. . Wakati wa uchunguzi, kiunganishi kilihamishiwa kwenye nguzo ya Kubernetes, ambapo hatimaye ilibakia, hata baada ya kosa kurekebishwa.
Haraka sana tuligundua kuwa Kubernetes ilikuwa rahisi, na ndani ya miezi sita tulihamisha viunganishi 7 na Wakala wa Viunganishi, ambavyo hutumia rasilimali nyingi zaidi, hadi kwenye kundi la uzalishaji.
Kufuatia viunganishi, tuliamua kubadilisha usanifu wa programu iliyobaki.
Shida kuu ilikuwa kwamba data hutoka kwa viunganishi hadi kwa proksi katika vikundi vikubwa, na kisha kugonga DANBoID na kutumwa kwa programu kuu ya wavuti kwa usindikaji. Kwa sababu ya idadi kubwa ya uhesabuji upya wa vipimo, kuna mzigo mkubwa kwenye programu.
Pia imeonekana kuwa vigumu sana kufuatilia hali ya kazi za kukusanya data binafsi na kuripoti hitilafu zinazotokea ndani ya viunganishi vya programu kuu ya wavuti ili watumiaji waweze kuona kinachoendelea na kwa nini data haikukusanywa.
Ili kutatua matatizo haya, tulitengeneza usanifu 2.0.
Tofauti kuu kati ya toleo jipya la usanifu ni kwamba badala ya API ya Wavuti, tunatumia RabbitMQ na maktaba ya MassTransit ili kubadilishana ujumbe kati ya huduma. Ili kufanya hivyo, tulilazimika kuandika tena Wakala wa Viunganishi kabisa, na kuifanya kuwa Kitovu cha Viunganishi. Jina lilibadilishwa kwa sababu jukumu kuu la huduma si tena katika kusambaza maombi kwa viunganishi na nyuma, lakini katika kudhibiti mkusanyiko wa vipimo kutoka kwa viunganishi.
Kutoka kwa programu kuu ya wavuti, tulitenganisha habari kuhusu uwekaji na takwimu kutoka kwa tovuti katika huduma tofauti, ambayo ilifanya iwezekanavyo kuondokana na mahesabu yasiyo ya lazima na kuhifadhi tu takwimu zilizohesabiwa na zilizojumuishwa katika kiwango cha uwekaji. Pia tuliandika upya na kuboresha mantiki ya kukokotoa takwimu za msingi kulingana na data ghafi.
Wakati huo huo, tunahamisha huduma na programu zote hadi Docker na Kubernetes ili kurahisisha uwekaji suluhu na iwe rahisi kudhibiti.
Tuko wapi sasa
Usanifu wa uthibitisho wa dhana 2.0 bidhaa D1.Dijitali tayari na kufanya kazi katika mazingira ya mtihani na seti ndogo ya viunganishi. Kilichosalia tu ni kuandika upya viunganishi vingine 20 kwenye mfumo mpya, kujaribu kuwa data imepakiwa ipasavyo na vipimo vyote vimekokotwa ipasavyo, na kusambaza muundo mzima katika toleo la umma.
Kwa kweli, mchakato huu utafanyika hatua kwa hatua na tutalazimika kuacha upatanifu wa nyuma na API za zamani ili kuweka kila kitu kifanye kazi.
Mipango yetu ya haraka ni pamoja na kuunda viunganishi vipya, kuunganishwa na mifumo mipya na kuongeza vipimo vya ziada kwenye seti ya data iliyopakuliwa kutoka kwa tovuti zilizounganishwa na mifumo ya matangazo.
Pia tunapanga kuhamisha programu zote, ikijumuisha programu kuu ya wavuti, hadi Docker na Kubernetes. Ikiunganishwa na usanifu mpya, hii itarahisisha kwa kiasi kikubwa upelekaji, ufuatiliaji na udhibiti wa rasilimali zinazotumiwa.
Wazo lingine ni kujaribu chaguo la hifadhidata ya kuhifadhi takwimu, ambayo kwa sasa imehifadhiwa katika MongoDB. Tayari tumehamisha viunganishi vipya kadhaa kwenye hifadhidata za SQL, lakini tofauti hiyo haionekani, na kwa takwimu zilizojumlishwa kwa siku, ambazo zinaweza kuombwa kwa muda wa kiholela, faida inaweza kuwa mbaya sana.
Kwa ujumla, mipango ni kubwa, wacha tuendelee :)
Waandishi wa makala R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mikhail Kotsik ()
Chanzo: mapenzi.com