Sveiki! Esame „Hosting Technologies“ ir pradėjome veiklą prieš 5 metus - pirmasis vds priegloba, sukurta specialiai kūrėjams. Stengiamės, kad tai būtų patogu, kaip ir „DigitalOcean“, bet su Rusijos palaikymu, mokėjimo būdais ir serveriais Rusijoje. Tačiau „DigitalOcean“ yra ne tik patikimumas ir kaina, bet ir aptarnavimas.
Programinė įranga iš ISPsystem pasirodė kaip virvė, kuri surišo mūsų rankas pakeliui į šaunią paslaugą. Prieš trejus metus naudojome „Billmanager“ atsiskaitymą ir „VMmanager“ serverio valdymo pultą ir greitai supratome, kad be savo skydelio beveik neįmanoma teikti geros paslaugos.
Kaip ISP sistema nužudė patogumą
Klaidas
Negalėjome patys ištaisyti klaidos – kiekvieną kartą turėdavome rašyti kažkieno palaikymo tarnybai ir laukti. Norint išspręsti bet kokią problemą, reikėjo trečiosios šalies įmonės atsakymo.
ISPsistemos palaikymas sureagavo normaliai, bet pataisymai atsirado tik po kelių leidimų, o ne visada ir ne visų. Kartais kritinių klaidų taisymas užtrukdavo kelias savaites. Turėjome nuraminti klientus, atsiprašyti ir laukti, kol ISPsystem ištaisys klaidą.
Prastovos grėsmė
Atnaujinimai gali sukelti nenuspėjamų prastovų, dėl kurių atsirado naujų klaidų.
Kiekvienas atnaujinimas buvo loterija: teko dangstyti atsiskaitymus ir aukotis atnaujinimų dievams – porą kartų atnaujinimas sukeldavo 10-15 minučių prastovos. Šiuo metu mūsų administratoriai tapo pilki prieš mūsų akis – niekada nežinojome, kiek truks prastovos, ir negalėjome numatyti, kada ISPsystem nuspręs išleisti naują naujinimą.
„Billmanager“ pagerėjo penktoje kartoje, tačiau, kad galėčiau pasiekti reikiamas funkcijas, turėjau įdiegti beta versiją, kuri jau buvo atnaujinama kiekvieną savaitę. Jei kažkas sugedo, turėjote suteikti prieigą kitiems kūrėjams, kad jie galėtų tai ištaisyti.
Nepatogi skydelio sąsaja
Viskas buvo padalinta į skirtingas plokštes ir valdoma iš skirtingų vietų. Pavyzdžiui, klientai mokėjo per Billmanager, bet turėjo iš naujo paleisti arba iš naujo įdiegti VDS VMManager. Mūsų darbuotojai taip pat turėjo perjungti langus, kad padėtų klientui, patikrintų serverio apkrovą arba pamatytų, kokią OS naudoja.
Tokia sąsaja užima laiko – tiek mūsų, tiek klientų. Šioje situacijoje nekalbama apie tokius patogumus kaip „DigitalOcean“.
Trumpas gyvavimo ciklas su dažnais API atnaujinimais
Parašėme savo įskiepius – pavyzdžiui, papildinį su papildomais mokėjimo būdais, kurių nėra VMManager.
Pastaraisiais metais VMManager gyvavimo ciklas buvo gana trumpas, o naujos versijos galėjo atsitiktinai pakeisti kintamųjų ar funkcijų pavadinimus API – tai sulaužė mūsų įskiepius. Senesnių versijų palaikymas buvo greitai nutrauktas ir reikėjo atnaujinti.
Negalima modifikuoti
Tiksliau, tai įmanoma, bet itin neveiksminga. Licencijos apribojimai neleidžia keisti šaltinio kodo, galite rašyti tik papildinius. Maksimalus įskiepių skaičius – kai kurie meniu elementai, žingsnis po žingsnio vedlys. ISPsistema skirta universalumui, tačiau mums reikėjo specializuotų sprendimų.
Taigi sprendimas parašyti savo panelę buvo subrendęs. Mes išsikėlėme tikslus:
- Greitai reaguokite į klaidas ir klaidas ir galėsite jas pataisyti patys, neversdami kliento laukti.
- Laisvai modifikuokite sąsają, kad ji atitiktų kliento darbo procesus ir poreikius.
- Pagerinkite naudojimo patogumą naudodami švarų ir aiškų dizainą.
Ir mes pradėjome plėtrą.
Naujos plokštės architektūra
Turime savarankišką kūrimo komandą, todėl panelę rašėme patys.
Pagrindinį darbą atliko trys inžinieriai – technikos direktorius Sergejus sugalvojo architektūrą ir parašė serverio agentą, Aleksejus išrašė sąskaitas, o frontendą surinko mūsų frontenderis Artysh.
1 veiksmas: serverio agentas
Serverio agentas yra Python žiniatinklio serveris, valdantis biblioteką , kuris savo ruožtu valdo .
Agentas per libvirt biblioteką valdo visas serveryje esančias paslaugas: kuria, stabdo, trina vds, įdiegia operacines sistemas, keičia parametrus ir t.t. Šio straipsnio publikavimo metu tai yra daugiau nei keturiasdešimt skirtingų funkcijų, kurias pridedame atsižvelgdami į kliento užduotį ir poreikius.
Teoriškai libvirt būtų galima valdyti tiesiogiai iš atsiskaitymo, tačiau tam reikėjo per daug papildomo kodo, todėl nusprendėme šias funkcijas padalyti tarp agento ir atsiskaitymo – atsiskaitymas tiesiog pateikia užklausas agentui per JSON API.
Agentas buvo pirmasis dalykas, kurį padarėme, nes jam nereikėjo jokios sąsajos ir jį buvo galima išbandyti tiesiai iš serverio konsolės.
Ką mums davė serverio agentas: atsirado sluoksnis, kuris palengvina buitį visiems - atsiskaitymui nereikia siuntinėti visos krūvos komandų, o tik pateikti užklausą. O agentas padarys viską, ko reikia: pavyzdžiui, paskirs vietos diske ir RAM.
2 veiksmas. Atsiskaitymas
Mūsų kūrėjui Aleksui tai buvo ne pirmas valdymo pultas – Aleksas šeimininkavo ilgą laiką, todėl apskritai suprato, ko reikia klientui, o ko reikia šeimininkui.
Atsiskaitymą vadiname „valdymo skydeliu“: jame yra ne tik pinigai ir paslaugos, bet ir jų valdymas, klientų aptarnavimas ir daug daugiau.
Norėdami pereiti nuo ISPSystem programinės įrangos, klientai turėjo visiškai išsaugoti ankstesnį funkcionalumą, perkelti visus vartotojų finansinius veiksmus iš senojo atsiskaitymo į naują, taip pat visas paslaugas ir ryšius tarp jų. Ištyrėme, kas yra dabartiniame produkte, tada konkurentų sprendimus, daugiausia DO ir Vultr. Mes pažvelgėme į trūkumus ir privalumus, surinkome atsiliepimus iš žmonių, kurie dirbo su senais produktais iš ISPsystem.
Naujajame atsiskaityme buvo naudojami du krūvos: klasikinis PHP, MySQL (ir ateityje planuojama pereiti prie PostgreSQL), Yii2 kaip pagrindas fone ir VueJS priekyje. Stackai veikia nepriklausomai vienas nuo kito, yra kuriami skirtingų žmonių ir bendrauja naudojant JSON API. Plėtrai tada ir dabar naudojame и iš „JetBrains“ ir labai juos myliu (vaikinai!)
Skydas sukurtas moduliniu principu: mokėjimo sistemos moduliai, domenų registratorių modulis arba, pavyzdžiui, SSL sertifikatų modulis. Galite lengvai pridėti naują funkciją arba pašalinti seną. Pagrindai plėtrai klojami architektūriškai, įskaitant priešingą pusę, „į techninę įrangą“.
Ką mes gavome: valdymo pultas, kurį mes visiškai valdome. Dabar klaidos taisomos valandomis, o ne savaitėmis, o naujos funkcijos diegiamos klientų, o ne ISPSystem prašymu.
3 veiksmas. Sąsaja
Sąsaja yra mūsų komandos sumanymas.
Pirmiausia pažiūrėjome, kas nutiktų, jei sukurtume ISPsystem API priedą, iš esmės nieko nekeisdami sąsajoje. Taip išėjo ir mes nusprendėme viską daryti nuo nulio.
Tikėjome, kad svarbiausia, kad sąsaja būtų logiška, su švariu ir minimalistiniu dizainu, ir tada gausime gražų skydelį. „Megaplan“ buvo aptartas elementų išdėstymas ir palaipsniui gims sąsaja, kurią vartotojai dabar mato valdymo skydelyje.
Pirmiausia buvo sukurtas atsiskaitymo puslapio dizainas, nes jau buvome sukūrę mokėjimų papildinius ISPsistemai.
Frontend
Jie nusprendė skydelį paversti SPA programa – nereikli resursų ir greitai įkeliami duomenys. Mūsų frontender Artysh nusprendė tai parašyti Vue – tuo metu Vue ką tik pasirodė. Darėme prielaidą, kad sistema vystysis dinamiškai, kaip ir „React“, o po kurio laiko „Vue“ bendruomenė augs ir atsiras bibliotekų jūra. Pasirinkome „Vue“ ir nesigailėjome – dabar naujų funkcijų, kurios jau buvo užprogramuotos backend, pridėjimas priekyje užima nedaug laiko. Daugiau apie priekines plokštes papasakosime atskirame straipsnyje.
Ryšys tarp frontend ir backend
Priekinė dalis buvo prijungta prie užpakalinės sistemos per tiesioginius pranešimus. Turėjau sunkiai dirbti ir parašyti savo tvarkyklę, tačiau dabar informacija puslapyje atnaujinama beveik akimirksniu.
Kas nutiko: Skydelio sąsaja tapo paprastesnė. Padarėme jį adaptyvų, o greitas įkėlimas leidžia juo naudotis net iš mobiliųjų telefonų paskutinėmis minutėmis prieš kilimą, neįdiegiant atskiros aplikacijos darbui su skydeliu.
4 žingsnis. Testavimo ir perkėlimo schema
Viskam prasidėjus ir praėjus pirmiesiems išbandymams iškilo migracijos klausimas. Pirmiausia įdiegėme atsiskaitymą ir pradėjome testuoti jo darbą su serverio agentu.
Tada parašėme paprastą scenarijų, kuris perkelia duomenų bazę iš senosios atsiskaitymo sistemos į naują.
Teko išbandyti ir dar kartą patikrinti pažodžiui viską, nes duomenys buvo sujungti į vieną naują duomenų bazę iš trijų senų: Billmanager, VMmanager ir IPmanager manager. Galbūt bandomasis perkėlimas yra pats sunkiausias dalykas, su kuriuo susidūrėme kurdami naują skydelį.
Po pakartotinio patikrinimo uždarėme seną atsiskaitymą. Galutinis duomenų perkėlimas buvo labai nerimą keliantis momentas, tačiau, ačiū Dievui, jis buvo baigtas per kelias minutes ir be pastebimų problemų. Buvo nedidelių klaidų, kurias ištaisėme per savaitę. Didžioji dalis laiko buvo skirta bandymams, kas atsitiko.
Tada išsiuntėme klientams laiškus su naujojo skydelio adresu ir atsiskaitymu bei atlikome peradresavimą.
Apibendrinant galima teigti, kad: TAI GYVA!
Laiminga pabaiga
Nuo pat pirmųjų darbo su mūsų programine įranga valandų pajutome visus perėjimo malonumus. Kodas buvo visiškai mūsų ir turėjo patogią architektūrą, o sąsaja buvo švari ir logiška.
Pirmoji peržiūra paleidus naują skydelį
Perėjimo procesą pradėjome gruodžio mėnesį, 2017-ųjų Naujųjų metų išvakarėse, kai buvo mažiausiai darbo krūvio, kad klientams būtų lengviau pereiti – švenčių išvakarėse beveik niekas nedirba.
Pagrindinis dalykas, kurį gavome pereidami prie mūsų sistemos (be bendro patikimumo ir patogumo), buvo galimybė greitai pridėti funkcionalumą pagrindiniams klientams – būti jų veidu, o ne užpakaliu.
Kas toliau?
Mes augame, auga duomenų, klientų, klientų duomenų kiekis. Užpakalinėje sistemoje turėjome pridėti „Memcached“ serverį ir dvi eilių tvarkykles su skirtingomis užduotimis. Frontend turi talpyklą ir savo eiles.
Žinoma, vis dar patyrėme nuotykių, kai produktas vystėsi ir tapo sudėtingesnis, pavyzdžiui, kai įtraukėme „HighLoad“.
Kitame straipsnyje mes jums pasakysime, kaip pradėjome naudoti „Hi-CPU“ tarifą: apie aparatinę įrangą, programinę įrangą, kokias problemas išsprendėme ir ko pasiekėme.
Šaltinis: www.habr.com