PĂ«rshĂ«ndetje! Ne jemi «TeknologjitĂ« e Hosting» dhe 5 vjet mĂ« parĂ« lansuam â hostingun e parĂ« vds, i krijuar posaçërisht pĂ«r zhvilluesit. Ne synojmĂ« ta bĂ«jmĂ« atĂ« tĂ« lehtĂ« pĂ«r t'u pĂ«rdorur, si DigitalOcean, por me mbĂ«shtetje nĂ« rusisht, mĂ«nyra pagese dhe servera nĂ« Rusi. Por DigitalOcean nuk Ă«shtĂ« vetĂ«m besueshmĂ«ri dhe çmim, Ă«shtĂ« gjithashtu dhe shĂ«rbim.
Software nga ISPsystem doli të ishte një litar që na lidhte duar në rrugën tonë për një shërbim të shkëlqyer. Tre vjet më parë ne përdorëm faturimin Billmanager dhe panelin e menaxhimit të serverëve VMmanager dhe shpejt e kuptuam se të ofronim një shërbim të mirë pa panelin tonë ishte praktikisht e pamundur.
Si ISPsystem vrau lehtësinë
Gabimet
Ne nuk mund tĂ« riparonim gabimin vetĂ« â nĂ« çdo rast duhet tĂ« shkruanim nĂ« mbĂ«shtetje tĂ« huaj dhe tĂ« prisnim. Zgjidhja e çdo problemi kĂ«rkonte reagimin e njĂ« kompanie tĂ« tretĂ«.
Mbështetje nga ISPsystem përgjigjej normalisht, por riparimet vinin vetëm pas disa lëshimeve, dhe asnjëherë jo gjithmonë dhe jo të gjitha. Ndërsa disa gabime kritike u rregulluan pas disa javësh. Në këtë mënyrë duhet të qetësonim klientët, të kërkonim falje dhe të prisnim që ISPsystem të rregullonte gabimin.
Kërcënimi i ndërprerjeve
Përditësimet mund të shkaktonin ndërprerje të paparashikuara, që provokonin gabime të reja.
Ădo pĂ«rditĂ«sim ishte njĂ« lotari: ishim tĂ« detyruar tĂ« mbyllnim faturimin dhe tĂ« bĂ«nim sakrifica pĂ«r zotat e pĂ«rditĂ«simeve â disa herĂ« pĂ«rditĂ«simi shkaktonte njĂ« ndĂ«rprerje pĂ«r 10-15 minuta. Administratoret tanĂ« gjatĂ« kĂ«saj kohe ishin tĂ« shqetĂ«suar â ne kurrĂ« nuk e dinim se sa do tĂ« zgjasĂ« ndĂ«rprerja dhe nuk mund tĂ« parashikonim, kur ISPsystem do tĂ« vendoste tĂ« lĂ«shonte njĂ« pĂ«rditĂ«sim tĂ« ri.
Me gjeneratën e pestë të Billmanager, gjërat u përmirësuan, por për të marrë qasje në funksionet e nevojshme duhej të instalonim beta versionin, i cili tashmë përditësohej çdo javë. Nëse diçka prishte, na duhej të jepnim qasje zhvilluesve të huaj, që të rregullonin diçka.
Ndërfaqja e paqartë e panelit
Të gjitha ishin të ndara në panele të ndryshme dhe menaxhoheshin nga vende të ndryshme. Për shembull, klientët paguanin përmes Billmanager, ndërsa rifreskimi ose ribërja e VDS duhej ta bënte në VMManager. Punonjësit tanë gjithashtu duhej të kalonin midis dritareve për të ndihmuar klientin, për të verifikuar ngarkesën në serverin e tij ose për të parë se cila OS po përdorte.
NjĂ« ndĂ«rfaqe e tillĂ« i merr kohĂ« â si tonĂ«n ashtu edhe tĂ« klientĂ«ve. NĂ« njĂ« situatĂ« tĂ« tillĂ« nuk Ă«shtĂ« çështje komoditeti, si nĂ« DigitalOcean.
Ciklet e shkurtra të jetës me përditësim të shpeshtë të API
Ne kemi shkruar plugins tanĂ« â pĂ«r shembull, njĂ« plugin me mĂ«nyra shtesĂ« pagese qĂ« nuk ekzistojnĂ« nĂ« VMManager.
NĂ« vitet e fundit, VMManager ka pasur njĂ« cikĂ«l jetĂ«shkurtĂ«r, ku emrat e variablave ose funksioneve nĂ« API mund tĂ« ndryshonin nĂ« versione tĂ« reja â kjo thyej plugins tona. MbĂ«shtetje pĂ«r versionet e vjetra Ă«shtĂ« mbyllur shpejt dhe duhej tĂ« pĂ«rditĂ«soheshim.
Nuk mund të përmirësojmë
Saktësisht, mundemi, por shumë joefikas. Kufizimet e licencës nuk lejojnë të bëjmë ndryshime në kodin burimor, mund të shkruajmë vetëm plugins. Maksimumi i plugins është disa elemente menaxheriale, një udhëzues hap pas hapi. ISPsystem janë orientuar në universialitet, ndërsa ne na nevojiteshin zgjidhje të specializuara.
Kështu që u bë vendimi të shkruajmë panelin tonë. Vendosëm qëllimet:
- Të reagojmë shpejt ndaj gabimeve, defekteve dhe të kemi mundësinë për t'i rregulluar vetë, pa e bërë klientin të presë.
- Të modifikojmë lirshëm ndërfaqen sipas proceseve të punës dhe nevojave të klientit.
- Të rrisim përdorshmërinë me një dizajn të pastër dhe të qartë.
Dhe filluam zhvillimin.
Arkitektura e panelit të ri
Kemi një ekip zhvillimi të vetë-mjaftueshëm, kështu që panelin e shkruam vetë.
Pjesa mĂ« e madhe e punĂ«s Ă«shtĂ« kryer nga tre inxhinierĂ« â Drejtori Teknik Sergey krijoi arkitekturĂ«n dhe shkroi agjentin server, Alexei bĂ«ri faturimin, ndĂ«rsa frontend-in e krijoi frontend-i ynĂ« Artysh.
Hapi 1. Agjenti server
Agjenti server është një server web në Python, që menaxhon bibliotekën , e cila, nga ana e saj, menaxhon .
Agjenti menaxhon të gjitha shërbimet në server: krijimin, ndalimin, fshirjen e vds, instalimin e sistemeve operative, ndryshimin e parametrave dhe kështu me radhë përmes bibliotekës libvirt. Në momentin e publikimit të artikullit, ka më shumë se dyzet funksione të ndryshme që ne i plotësojmë në varësi të detyrës dhe nevojave të klientit.
Teorikisht, libvirt mund tĂ« menaxhohej direkt nga faturimi, por kjo kĂ«rkonte shumĂ« mĂ« shumĂ« kod shtesĂ« dhe vendosĂ«m t'i ndajmĂ« kĂ«to funksione midis agjentit dhe faturimit â faturimi thjesht bĂ«n kĂ«rkesa te agjenti pĂ«rmes API JSON.
Agjenti ishte gjëja e parë që bëjmë, pasi nuk kërkonte asnjë ndërfaqe dhe mund të testoheshim drejtpërdrejt nga konsola e serverit.
ĂfarĂ« na dha agjenti server: u shfaq njĂ« ndĂ«rfaqe qĂ« e thjeshton jetĂ«n e tĂ« gjithĂ«ve â billingut nuk i nevojitet tĂ« dĂ«rgojĂ« njĂ« mori komandash, por thjesht tĂ« bĂ«jĂ« njĂ« kĂ«rkesĂ«. Agjenti do tĂ« bĂ«jĂ« gjithçka qĂ« nevojitet: pĂ«r shembull, do tĂ« ndajĂ« hapĂ«sirĂ«n nĂ« disk dhe kujtesĂ«n operative.
Hapi 2. Billingu
PĂ«r zhvilluesin tonĂ« Alex, kjo nuk ishte paneli i parĂ« i menaxhimit â Alex ka punuar nĂ« hostim pĂ«r njĂ« kohĂ« tĂ« gjatĂ«, kĂ«shtu qĂ« ai nĂ« pĂ«rgjithĂ«si e kuptonte se çfarĂ« i nevojitej klientit dhe çfarĂ« i nevojitej hosterit.
Billingu ne e quajmë midis vetes «paneli i menaxhimit»: në të nuk ka vetëm para dhe shërbime, por edhe menaxhimi i tyre, përkrahja e klientëve dhe shumë më tepër.
Për të kaluar nga softi ISPSystem, ishte e nevojshme të ruhej plotësisht funksionaliteti i mëparshëm për klientët, të transferoheshin të gjitha veprimet financiare të përdoruesve nga billing të vjetër në atë të ri, si dhe të gjitha shërbimet dhe lidhjet midis tyre. Studiuam çfarë kishte në produktin aktual, pastaj zgjidhjet e konkurentëve, kryesisht DO dhe Vultr. Shikuam dobësitë dhe avantazhet, mbledhim komente nga njerëzit që kanë punuar me produktet e vjetra nga ISPsystem.
Në billingun e ri përdorëm dy steka: PHP klasik, MySQL (dhe në të ardhmen planifikohet që të kalojmë në PostgreSQL), Yii2 si një framerwork në backend dhe VueJS në frontend. Stekat punojnë pavarësisht nga njëri-tjetri, zhvillohen nga njerëz të ndryshëm, dhe komunikojnë përmes JSON API. Për zhvillimin atëherë dhe tani ne përdorim dhe nga JetBrains dhe i duam shumë (hej, djem!)
Paneli Ă«shtĂ« projektuar sipas njĂ« parimi modular: modulet e sistemeve tĂ« pagesave, moduli i regjistruesve tĂ« domini ose, pĂ«r shembull, moduli i certifikatave SSL. Mund tĂ« shtohet lehtĂ«sisht njĂ« funksion i ri ose tĂ« hiqet njĂ« tĂ« vjetĂ«r. ĂshtĂ« parashikuar ndihma pĂ«r zgjerimin, pĂ«rfshirĂ« edhe nĂ« anĂ«n e kundĂ«rt, «me pajisjen».
ĂfarĂ« morĂ«m: paneli i menaxhimit, mbi tĂ« cilin kemi kontroll tĂ« plotĂ«. Tani gabimet rregullohen brenda disa orĂ«ve, jo javĂ«sh, dhe funksionet e reja realizohen sipas kĂ«rkesĂ«s sĂ« klientĂ«ve, jo sipas dĂ«shirĂ«s sĂ« ISPSystem.
Hapi 3. Interfaces
Interfaces â krijimi ynĂ« i ekipit.
Fillimisht shikuam se çfarë do të ndodhte nëse bënim një shtesë mbi API ISPsystem, duke mos ndryshuar asgjë në mënyrë drastike në interface. Doli disi dhe vendosëm ta bëjmë gjithçka nga e para.
Ne kemi besuar se e rëndësishme është të krijojmë një ndërfaqe logjike, me një dizajn të pastër dhe minimalistik dhe atëherë do ta kemi një panel të bukur. Vendosjen e elementeve e kemi diskutuar në Megaplan dhe ngadalë do të lindë ajo ndërfaqe që përdoruesit e shohin tani në panelin e kontrollit.
E para u shfaq dizajni i faqes së faturimit, sepse ne tashmë bëmë plugins pagesash për ISPsystem.
Frontend
Pjesa e panelit u vendos tĂ« zhvillohet si njĂ« aplikacion SPA - i papĂ«rfillshĂ«m pĂ«r burimet dhe me ngarkim tĂ« shpejtĂ« tĂ« tĂ« dhĂ«nave. Frontend-i ynĂ«, Artysh, vendosi ta zhvillojĂ« atĂ« nĂ« Vue - nĂ« atĂ« kohĂ« Vue sapo ishte paraqitur. Ne parashikuam se ky framework do tĂ« zhvillohet dinamikisht, si React, dhe pas njĂ«farĂ« kohĂ« komuniteti i Vue do tĂ« rritet dhe do tĂ« shfaqen njĂ« mori bibliotekash. Ne e pĂ«rzgjodhĂ«m Vue dhe nuk u penduam â tani shtimi i funksioneve tĂ« reja nĂ« frontend qĂ« tashmĂ« janĂ« programuar nĂ« backend merr pak kohĂ«. MĂ« shumĂ« rreth frontend-it tĂ« panelit do tĂ« tregojmĂ« nĂ« njĂ« artikull tĂ« veçantĂ«.
Lidhja e frontend-it me backend-in
Frontend-i u lidh me backend-in përmes push-eve. Duhej të punonim dhe të shkruanim një trajtues të vetin, por tani përditësimi i informacionit në faqe ndodh pothuajse menjëherë.
ĂfarĂ« rezultoi: ndĂ«rfaqja e panelit u bĂ« mĂ« e thjeshtĂ«. E bĂ«mĂ« atĂ« adaptuese, dhe ngarkimi i shpejtĂ« lejon pĂ«rdorimin e saj edhe nga celularĂ«t nĂ« minutat e fundit para ngritjes, pa instaluar njĂ« aplikacion tĂ« veçantĂ« pĂ«r tĂ« punuar me panelin.
Hapi 4. Testimi dhe skema e migracionit
Kur gjithçka ishte funksional dhe kishim kaluar testet e para, u vendos çështja e migracionit. Me të parën, ne instaluam faturimin dhe filluam të testonim funksionimin e tij me agjentin server.
Më pas shkruam një skript të thjeshtë që transferon bazën e të dhënave nga faturimi i vjetër në të riun.
Duhej të testonim dhe risistem që çdo gjë, pasi të dhënat u derdhën në një bazë të re nga tri të vjetra: Billmanager, VMmanager dhe IPmanager. Sigurisht, migrimet testuese ishin më të vështirat me të cilat u përballëm gjatë zhvillimit të panelit të ri.
Pas rivlerësimeve, mbyllëm faturimin e vjetër. Migrimi i fundit i të dhënave ishte një moment shumë shqetësues, por, falë Zotit, u realizua për disa minuta dhe pa probleme të dukshme. Ka pasur disa defekte të vogla, të cilat i riparuam gjatë javës. Koha kryesore u mor nga testimi i asaj që rezultoi.
Më pas, ne dërguam letrat klientëve me adresën e panelit të ri dhe faturimit dhe bëmë një redirigjim.
Në fund: Eshte e gjallë!
PĂ«rfundimi i lumtur
Që në orët e para të funksionimit të softuerit tonë, ne ndjemë të gjitha përfitimet e kalimit. Kodi ishte plotësisht ynë dhe me një arkitekturë të përshtatshme, ndërsa ndërfaqja ishte e pastër dhe logjike.
Rishikimi i parë pas lançimit të panelit të ri
Ne filluam procesin e kalimit në dhjetor, përpara Vitit të Ri 2017, kur ngarkesat ishin më të ulëta, për të bërë kalimin më të lehtë për klientët - pothuajse askush nuk punon para festave.
Gjithashtu, ajo që fituam nga kalimi në sistemin tonë (përveç besueshmërisë dhe lehtësisë së përgjithshme) ishte mundësia për të shtuar shpejt funksionalitete për klientët kryesorë - të ishim fytyra e tyre, e jo mbrapa.
ĂfarĂ« ndodh mĂ« tej?
Ne po rritemi, po rritet numri i të dhënave, klientëve, të dhënave të klientëve. Në backend duhej të shtonim një server Memcached dhe dy menaxherë radhësh me detyra të ndryshme. Në frontend ka ruajtje në cache dhe radhë të veta.
Sigurisht, ne patëm edhe aventura gjatë zhvillimit dhe përmirësimit të produktit, për shembull, kur shtonim HighLoad.
Në artikullin tjetër do të tregojmë si e zhvilluam planin Hi-CPU: për harduerin, software, çfarë sfidash zgjidhëm dhe çfarë arritëm.
Burimi: habr.com
