PĂ«rshĂ«ndetje! Ne jemi "TeknologjitĂ« e Hostingut" dhe 5 vjet mĂ« parĂ« lançuam â hostimi i parĂ« VDS, krijuar veçanĂ«risht pĂ«r zhvilluesit. Ne synojmĂ« ta bĂ«jmĂ« tĂ« pĂ«rshtatshĂ«m si DigitalOcean, por me mbĂ«shtetje ruse, mĂ«nyra pagese dhe servera nĂ« Rusi. MegjithatĂ«, DigitalOcean nuk Ă«shtĂ« vetĂ«m besueshmĂ«ri dhe çmim, por gjithashtu njĂ« shĂ«rbim.
Softi nga ISPsystem u bë një litar që na lidhte duar për të ofruar 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 kuptuam se ofrimi i një shërbimi të mirë pa panelin tonë ishte praktikisht i pamundur.
Si ISPsystem vrau lehtësinë
Bugs
Ne nuk mund tĂ« rregullojmĂ« vetĂ« bug-un â çdo herĂ« duhej tĂ« shkruanim nĂ« mbĂ«shtetje tĂ« njĂ« kompanie tjetĂ«r dhe tĂ« prisnim. Zgjidhja e çdo problemi kĂ«rkonte reagimin e kompanisĂ« sĂ« jashtme.
Mbështetja e ISPsystem përgjigjej normalisht, por rregullimet vinin vetëm pas disa lansimeve, dhe jo gjithmonë dhe jo të gjitha. Ndonjëherë, bugs kritikë rregulloheshin për disa javë. Na duhej të qetësojmë klientët, të kërkojmë falje dhe të presim derisa ISPsystem të rregullojë bug-un.
Kërcënimi i pezullimeve
Përditësimet mund të sillnin ndërprerje të paparashikueshme, të cilat provokonin gabime të reja.
Ădo pĂ«rditĂ«sim ishte njĂ« llotari: duhej tĂ« mbyllnim faturimin dhe tĂ« sillnim flijime pĂ«r perĂ«nditĂ« e pĂ«rditĂ«simeve â disa herĂ« pĂ«rditĂ«simi shkaktonte ndĂ«rprerje pĂ«r 10-15 minuta. AdministratorĂ«t tanĂ« kishin frikĂ« nĂ« atĂ« kohĂ« â kurrĂ« nuk e dinim se sa do tĂ« zgjaste ndĂ«rprerja dhe nuk mund tĂ« parashikonim kur ISPsystem do tĂ« vendoste tĂ« lĂ«shonte njĂ« pĂ«rditĂ«sim tĂ« ri.
Në brezin e pestë Billmanager u bë më mirë, por për të qasje të veçorive të nevojshme duhej të instalonim versionin beta, i cili përditësohej çdo javë. Nëse diçka prishej, duhej të jepnin qasje zhvilluesve të jashtëm për të bërë disa korrigjime.
Ndërfaqe e pakëndshme e panelit.
Gjithçka ishte e ndarë në panelet të ndryshme dhe menaxhohej nga vende të ndryshme. Për shembull, klientët paguanin përmes Billmanager, ndërsa ata duhej ta rindalonin ose ta riparojnë VDS-në në VMManager. Punonjësit tanë gjithashtu duhej të kalonin midis dritareve për t'i ndihmuar klientit, për të kontrolluar ngarkesën në serverin e tij apo për të parë se cila OS po përdorte.
Ky kyçje zĂ« shumĂ« kohĂ« â pĂ«r ne dhe klientĂ«t. NĂ« njĂ« situatĂ« tĂ« tillĂ«, nuk flitet pĂ«r rehatinĂ« si te DigitalOcean.
Ciklet e shkurtra të jetës me përditësime të shpeshta të API
Kemi shkruar plugina tĂ« veta â pĂ«r shembull, njĂ« plugin me mĂ«nyra tĂ« tjera pagesash qĂ« nuk ekzistojnĂ« nĂ« VMManager.
NĂ« vitet e fundit, VMManager kishte njĂ« cikĂ«l relativisht tĂ« shkurtĂ«r jetese, ku nĂ« versionet e reja emrat e variablave ose funksioneve nĂ« API mund tĂ« ndryshonin pa paralajmĂ«rim â kjo prishte pluginat tanĂ«. MbĂ«shtetja pĂ«r versionet e vjetra u ndĂ«rpre shpejt dhe duhej tĂ« pĂ«rditĂ«soheshim.
Nuk mund të ripunosh
MĂ« saktĂ«, mundesh, por shumĂ« joefektivisht. Kufizimet licencuese nuk lejojnĂ« ndryshime nĂ« kodin burimor, mund tĂ« shkruash vetĂ«m plugina. Maksimumi i pluginave â disa elemente tĂ« menusĂ«, njĂ« master hap pas hapi. ISPsystem janĂ« tĂ« ndĂ«rtuara pĂ«r universalitet, ndĂ«rsa ne na duheshin zgjidhje tĂ« specializuara.
Kështu erdhi vendimi për të shkruar panelin tonë. Vendosëm qëllimet:
- Të reagojmë shpejt ndaj gabimeve dhe defekteve dhe të kemi mundësinë t'i riparojmë vetë, pa e bërë klientin të presë.
- Të modifikojmë lirisht interfejsin sipas proceseve të punës dhe nevojave të klientit.
- Dizajni i pastër dhe i qartë rrit përdorshmërinë.
Dhe filluam zhvillimin.
Arkitektura e panelit të ri
Kemi një ekip zhvillimi të pavarur, kështu që panelin e kemi shkruar vetë.
Puna kryesore u krye nga tre inxhinierë - drejtori teknik Sergey krijoi arkitekturën dhe shkroi agjentin server, Alexei bëri faturimin, ndërsa frontendi u përgatit nga frontendi ynë Artush.
Hapi 1. Agjenti server
Agjenti server është një server web në Python, i cili menaxhon bibliotekën , e cila, nga ana tjetër, menaxhon .
Agjenti menaxhon të gjitha shërbimet në server: krijimi, ndalja, fshirja e VDS, instalimi i sistemeve operative, ndryshimi i parametrave dhe kështu me radhë përmes bibliotekës libvirt. Në momentin e daljes së artikullit, kjo përfshin më shumë se dyzet funksione të ndryshme, të cilat ne i plotësojmë në varësi të detyrave dhe nevojave të klientit.
Teoretikisht, me libvirt do të ishte e mundur të kishim menaxhuar drejtpërdrejt nga faturimi, por kjo kërkonte shumë kod shtesë dhe ne vendosëm t'i ndajmë këto funksione ndërmjet agjentit dhe faturimit - faturimi thjesht bën kërkesa te agjenti përmes JSON API.
Agenti është ai që ne e krijuam si të parën gjë, sepse ai nuk kërkonte asnjë ndërfaqe dhe mund të testoheshim direkt nga konsola e serverit.
ĂfarĂ« na dha agjenti i serverit: u shfaq njĂ« shtresĂ«, e cila thjeshton jetĂ«n e tĂ« gjithĂ«ve â faturimi nuk ka nevojĂ« 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Ă« alokojĂ« hapĂ«sirĂ« nĂ« hard disk dhe memorie RAM.
Hapi 2. Faturimi
PĂ«r zhvilluesin tonĂ« Alex, kjo nuk ishte paneli i parĂ« i menaxhimit â Alex ka kohĂ« qĂ« punon nĂ« hostim, kĂ«shtu qĂ« ai nĂ« pĂ«rgjithĂ«si e kuptonte çfarĂ« i nevojitet klientit dhe çfarĂ« i duhet hostit.
Faturimin ne e quajmë mes vete «paneli i menaxhimit»: atje ka jo vetëm para dhe shërbime, por edhe menaxhimi i tyre, mbështetje për klientët dhe shumë të tjera.
Për të kaluar nga softi ISPSystem, ishte e nevojshme të ruhej plotësisht funksionaliteti i mëparshëm për klientët, të dërgoheshin të gjitha veprimet financiare të përdoruesve nga bilingu i vjetër në të riun, si dhe të gjitha shërbimet dhe lidhjet midis tyre. Ne studiuam çfarë kishte në produktin aktual, pastaj zgjidhjet e konkurrentëve, kryesisht DO dhe Vultr. Shikojmë në mangësitë dhe avantazhet, mblodhëm komente nga njerëz që kanë punuar me produktet e vjetra nga ISPsystem.
Në bilingu të ri, kemi përdorur dy steka: PHP klasik, MySQL (dhe në të ardhmen planifikohet kalimi në PostgreSQL), Yii2 si kuadër në backend dhe VueJS në frontend. Stekat punojnë në mënyrë të pavarur 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 ata shumë (djem, përshëndetje!)
Paneli është projektuar mbi një parim modular: modulet e sistemeve të pagesave, moduli i regjistruesve të domeneve ose, për shembull, moduli i certifikatave SSL. Mund të shtohet lehtësisht një funksion i ri ose të hiqet një i vjetër. Ka një plan për zgjerim të ngritur arkitektonikisht, përfshirë edhe në drejtimin e kundërt, 'tek pajisja'.
ĂfarĂ« kemi arritur: panele e menaxhimit, mbi tĂ« cilin ne kemi kontroll tĂ« plotĂ«. Tani gabimet rregullohen brenda disa orĂ«sh, jo javĂ«sh, dhe funksionalitetet e reja realizohen sipas kĂ«rkesave tĂ« klientĂ«ve, jo sipas dĂ«shirĂ«s sĂ« ISPSystem.
Hapi 3. Ndërfaqja
NdĂ«rfaqja â krijimi ynĂ« me ekipin.
Fillimisht, ne shqyrtuam se çfarë do ndodhte nëse do të bënim një shtesë mbi API ISPsystem, pa ndryshuar ndjeshëm ndërfaqen. Rezultati ishte mesatar dhe vendosëm ta bënim gjithçka nga fillimi.
Ne besonim se e rëndësishmja është të krijonim një ndërfaqe logjike, me një dizajn të pastër dhe minimalistik, dhe atëherë do të kishim një panel të bukur. Vendosjen e elementeve e diskutonim në Megaplan dhe gradualisht lindi ajo ndërfaqe që përdoruesit e shohin tani në panelin e menaxhimit.
Së pari u shfaq dizajni i faqes së faturimit, pasi ne tashmë kishim bërë plugins pagesash për ISPsystem.
Frontend
Panele e vendosur tĂ« bĂ«het njĂ« aplikacion SPA â i kĂ«rkesave tĂ« ulĂ«ta pĂ«r burime dhe me ngarkim tĂ« shpejtĂ« tĂ« tĂ« dhĂ«nave. Frontend-i ynĂ«, Artysh, vendosi ta shkruajĂ« atĂ« nĂ« Vue â nĂ« atĂ« kohĂ« Vue sapo kishte dalĂ«. Ne supozuam se kuadri do tĂ« zhvillohej dinamiku, si React, dhe pas njĂ« kohe komuniteti i Vue do tĂ« rritej dhe do tĂ« shfaqeshin shumĂ« biblioteka. Ne vendosĂ«m pĂ«r Vue dhe nuk u penduam â tani shtimi i funksioneve tĂ« reja nĂ« front, tĂ« cilat tashmĂ« janĂ« programuar nĂ« backend, merr pak kohĂ«. MĂ« shumĂ« pĂ«r frontend-in e panelit do tĂ« tregojmĂ« nĂ« njĂ« artikull tĂ« veçantĂ«.
Lidhja midis frontend-it dhe backend-it
Frontend-i u lidh me backend-in përmes push-eve. Duhej të punonim dhe të shkruanim një trajtues të vetë, por tani përditësimi i informacionit në faqe ndodh pothuajse në mënyrë momentale.
ĂfarĂ« Ă«shtĂ« arritur: interfejsi i panelit u bĂ« mĂ« i thjeshtĂ«. Ne e bĂ«mĂ« atĂ« reagues dhe ngarkimi i shpejtĂ« lejon qĂ« tĂ« pĂ«rdoret edhe nga celularĂ«t nĂ« minutat e fundit para fluturimit, pa instaluar njĂ« aplikacion tĂ« veçantĂ« pĂ«r tĂ« punuar me panelin.
Hapi 4. Testimi dhe plani i migrimit
Kur çdo gjë filloi dhe kaluam testet e para, u shfaq pyetja për migrimin. E para që bëmë ishte të vendosnim faturimin dhe filluam ta testonim punën e tij me agjentin e serverit.
Pastaj shkruam një skript të thjeshtë që transferon të dhënat nga faturimi i vjetër në atë të ri.
Na duhej të testonim dhe rinovonim dosjet e gjitha, pasi të dhënat po derdheshin në një bazë të re nga tri të vjetra: Billmanager, VMmanager dhe IPmanager. Mendoj se migrimet testuese ishin më të vështirat që u ballafaquam gjatë zhvillimit të paneleve të reja.
Pas rinovimeve, ne e mbyllëm faturimin e vjetër. Migrimi final i të dhënave ishte një moment shumë stresues, por, falë Zotit, u realizua brenda disa minutash dhe pa probleme të dukshme. Kishte disa bug-e të vogla që i rregulluam gjatë një jave. Koha kryesore e mori testimi i asaj që kishim marrë.
Më pas, ne dërguam letra klientëve me adresën e panelit të ri dhe faturimit dhe bëmë redirect.
Si pĂ«rfundim: ITâS ALIVE!
Happy End
Që nga orët e para të funksionimit të softuerit tonë, përjetuam të gjitha të mirat e kalimit. Kodi ishte plotësisht i yni dhe me një arkitekturë praktike, ndërsa ndërfaqja ishte e pastër dhe logjike.
Përgjigjja e 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, qĂ« ta bĂ«nim kalimin mĂ« tĂ« lehtĂ« pĂ«r klientĂ«t â pothuajse askush nuk punon para festave.
Gj thingu kryesor qĂ« fituam me kalimin nĂ« sistemin tonĂ« (pĂ«rveç besueshmĂ«risĂ« dhe lehtĂ«sisĂ«) â ishte mundĂ«sia pĂ«r tĂ« shtuar shpejt funksionalitete pĂ«r klientĂ«t e rĂ«ndĂ«sishĂ«m â tĂ« jemi ata qĂ« i pĂ«rfaqĂ«sojmĂ«, jo ata qĂ« qĂ«ndrojnĂ« pas.
ĂfarĂ« ndodh mĂ« tej?
Ne po rritemi, po rritet numri i të dhënave, klientëve, të dhënave të klientëve. Në backend, ishte e nevojshme të shtonim një server Memcached dhe dy menaxherë të radhëve me detyra të ndryshme. Në frontend, ka caching dhe radhët tona.
Sigurisht, ne patëm gjithashtu aventurat tona gjatë zhvillimit dhe komplikimit të produktit, për shembull, kur shtonim HighLoad.
Në artikullin e ardhshëm do të tregojmë si e lançuam tarifën Hi-CPU: për harduerin, softuerin, çfarë detyrash zgjidhëm dhe çfarë arritëm.
Burimi: habr.com
