Tere! Oleme "Hosting Technologies" ja käivitasime 5 aastat tagasi - esimene spetsiaalselt arendajatele loodud vd-majutus. Püüame muuta selle mugavaks, nagu DigitalOcean, kuid Venemaa toe, makseviiside ja serveritega Venemaal. Kuid DigitalOcean pole mitte ainult töökindlus ja hind, vaid ka teenus.
ISPsystemi tarkvara osutus köieks, mis sidus meie käed teel laheda teenuse poole. Kolm aastat tagasi kasutasime Billmanageri arveldust ja VMmanageri serveri juhtpaneeli ning saime kiiresti aru, et ilma oma juhtpaneelita on head teenust peaaegu võimatu pakkuda.
Kuidas ISP-süsteem mugavuse hävitas
Vead
Ise me viga parandada ei saanud – iga kord pidime kellegi teise toele kirjutama ja ootama. Mis tahes probleemi lahendus nõudis kolmanda osapoole ettevõtte reageerimist.
ISP-süsteemi tugi vastas normaalselt, kuid parandused tulid alles mõne väljalaske järel ja siis mitte alati ja mitte kõigis. Mõnikord parandati kriitilisi vigu mitu nädalat. Pidime kliente rahustama, vabandama ja ootama, kuni ISPsystem vea parandab.
Seisakuoht
Värskendused võivad tekitada ettearvamatuid seisakuid, mis kutsusid esile uusi vigu.
Iga uuendus oli loterii: pidin arveldust varjama ja uuenduste jumalatele ohvreid tooma – paar korda põhjustas uuendus 10-15 minutilist seisakut. Meie administraatorid istusid sel ajal silma peal – me ei teadnud kunagi, kui kaua seisakuaeg kestab, ega osanud ennustada, millal ISPsystem otsustab uue värskenduse välja anda.
Viiendal põlvkonnal läks Billmanager paremaks, kuid vajalikele funktsioonidele juurdepääsu saamiseks pidin installima beetaversiooni, mida juba iga nädal uuendati. Kui midagi läks katki, pidin andma juurdepääsu teistele arendajatele, et nad saaksid midagi parandada.
Ebamugav paneeli liides
Kõik oli jagatud erinevatesse paneelidesse ja juhitud erinevatest kohtadest. Näiteks kliendid maksid Billmanageri kaudu ja nad pidid VMManageris VDS-i taaskäivitama või uuesti installima. Meie töötajad pidid ka akende vahel vahetama, et klienti aidata, kontrollida tema serveri koormust või vaadata, millist operatsioonisüsteemi ta kasutab.
Selline liides võtab aega – nii meil kui ka klientidel. Sellises olukorras ei saa rääkida mugavusest, nagu DigitalOceanil.
Lühikesed elutsüklid koos sagedaste API värskendustega
Kirjutasime oma pluginad – näiteks lisamakseviisidega plugina, mida VMManageris pole.
Viimastel aastatel oli VMManager suhteliselt lühike elutsükkel ja uutes versioonides võisid muutujate või funktsioonide nimed API-s suvaliselt muutuda – see rikkus meie pistikprogrammid. Vanemate versioonide tugi lõpetati kiiresti ja seda tuli värskendada.
Ei saa muuta
Täpsemalt on see võimalik, kuid äärmiselt ebaefektiivne. Litsentsipiirangud ei luba lähtekoodis muudatusi teha, kirjutada saab ainult pluginaid. Maksimaalne pistikprogrammide arv – mõned menüüelemendid, samm-sammult viisard. ISPsüsteem on loodud mitmekülgseks, kuid vajasime spetsiaalseid lahendusi.
Nii et otsus oli küps kirjutada oma paneel. Oleme seadnud eesmärgid:
- Reageerige kiiresti vigadele ja vigadele ning saate need ise parandada, ilma et klient peaks ootama.
- Muutke liidest vabalt töövoogude ja kliendi vajaduste jaoks.
- Suurendage kasutatavust puhta ja arusaadava disainiga.
Ja hakkasime arenema.
Uus paneelarhitektuur
Meil on isemajandav arendusmeeskond, seega kirjutasime paneeli ise.
Põhitöö tegid ära kolm inseneri - tehniline direktor Sergei mõtles välja arhitektuuri ja kirjutas serveriagendi, Aleksei arveldas ja esiotsa pani kokku meie esiserver Artõš.
1. samm: serveriagent
Serveriagent on pythoni veebiserver, mis haldab teeki , mis omakorda juhib .
Agent haldab kõiki serveris olevaid teenuseid: vd-de loomist, peatamist, kustutamist, operatsioonisüsteemide installimist, parameetrite muutmist ja nii edasi libvirti teegi kaudu. Artikli ilmumise hetkel on tegemist enam kui neljakümne erineva funktsiooniga, mida täiendame sõltuvalt ülesandest ja kliendi vajadustest.
Teoreetiliselt saaks libvirti juhtida otse arveldamisest, kuid see nõudis liiga palju lisakoodi ja otsustasime need funktsioonid agendi ja arveldamise vahel eraldada – arveldamine teeb lihtsalt päringud agendile JSON API kaudu.
Agent on esimene asi, mille tegime, kuna see ei vajanud liidest ja seda oli võimalik testida otse serverikonsoolist.
Mida serveriagent meile andis: on ilmunud kiht, mis lihtsustab kõigi elu - arveldamiseks pole vaja tervet käskude hunnikut saata, vaid teha ainult päring. Ja agent teeb kõik vajaliku: näiteks eraldab kettaruumi ja RAM-i.
2. samm. Arveldamine
Meie arendaja Alexi jaoks ei olnud see esimene juhtpaneel – Alex on hostimisega tegelenud juba pikka aega, seega sai ta üldiselt aru, mida vajab klient ja mida hostija.
Nimetame omavahelist arveldust “juhtpaneeliks”: see ei sisalda mitte ainult raha ja teenuseid, vaid ka nende haldamist, kliendituge ja palju muud.
ISPSystem tarkvaralt üleminekuks oli vaja klientide jaoks täielikult säilitada eelmine funktsionaalsus, viia kõik kasutajate finantstoimingud vanalt arveldamiselt uude, samuti kõik nendevahelised teenused ja ühendused. Uurisime, mis on praeguses tootes, siis konkurentide lahendusi, peamiselt DO ja Vultr. Vaatasime puudusi ja eeliseid, kogusime tagasisidet inimestelt, kes töötasid ISPsystemi vanade toodetega.
Uues arvelduses kasutati kahte pinu: klassikalist PHP-d, MySQL-i (ja tulevikus on plaanis minna üle PostgreSQL-ile), Yii2 raamistikuna taustaprogrammina ja VueJS-i esiküljel. Virnad töötavad üksteisest sõltumatult, on välja töötatud erinevate inimeste poolt ja suhtlevad JSON API abil. Arendamiseks kasutame siis ja praegu и JetBrainsist ja armastan neid väga (hei poisid!)
Paneel on kujundatud modulaarselt: maksesüsteemi moodulid, domeeniregistri moodul või näiteks SSL sertifikaadi moodul. Saate hõlpsasti lisada uue funktsiooni või eemaldada vana. Laienemise alus on rajatud arhitektuurselt, sh vastupidises suunas, „riistvara poole“.
Mida me saime: juhtpaneel, mille üle on meil täielik kontroll. Nüüd parandatakse vead tundide, mitte nädalate jooksul ja uusi funktsioone rakendatakse klientide, mitte ISPSystemi nõudmisel.
3. samm Liides
Liides on meie meeskonna vaimusünnitus.
Esiteks vaatasime, mis juhtuks, kui teeksime ISPsystem API-le lisandmooduli, muutmata liideses põhimõtteliselt midagi. Selgus nii ja naa ja otsustasime teha kõike nullist.
Uskusime, et peaasi, et liides oleks loogiline, puhta ja minimalistliku disainiga ning siis saame ilusa paneeli. Megaplanis arutati elementide asukohta ja tasapisi hakkab sündima liides, mida kasutajad nüüd juhtpaneelil näevad.
Esimesena ilmus arvelduslehe kujundus, sest oleme ISPsystemile juba teinud maksepluginad.
Esiots
Nad otsustasid teha paneelist SPA-rakenduse – ressursse vähenõudliku ja kiire andmelaadimisega. Meie esiotsa Artysh otsustas selle Vue's kirjutada - sel ajal oli Vue just ilmunud. Eeldasime, et raamistik areneb dünaamiliselt, nagu React, mõne aja pärast kasvab Vue kogukond ja ilmub raamatukogude meri. Panustasime Vue peale ja ei kahetsenud – nüüd kulub vähe aega, et lisada esiküljele uusi funktsioone, mis on juba tagumisse otsa programmeeritud. Esipaneeli kohta räägime lähemalt eraldi artiklis.
Esiosa ühendamine taustaga
Esiosa ühendati taustaprogrammiga tõukemärguannete kaudu. Pidin kõvasti tööd tegema ja oma töötleja kirjutama, kuid nüüd uuendatakse lehel olevat teavet peaaegu kohe.
Mis juhtus: Paneeli liides on muutunud lihtsamaks. Muutsime selle kohanemisvõimeliseks ja kiire laadimine võimaldab seda kasutada isegi mobiiltelefonist viimastel minutitel enne õhkutõusmist, ilma paneeliga töötamiseks eraldi rakendust installimata.
Etapp 4. Testimine ja migratsiooniskeem
Kui kõik läks käima ja esimesed katsed läbi said, kerkis küsimus migratsioonist. Kõigepealt installisime arvelduse ja alustasime selle toimimise testimist serveriagendiga.
Seejärel kirjutasime lihtsa skripti, mis kannab andmebaasi vanast arveldamisest uude.
Pidin sõna otseses mõttes kõike testima ja uuesti üle kontrollima, kuna andmed liideti üheks uueks andmebaasiks kolmest vanast: Billmanager, VMmanager ja halduri IPmanager. Võib-olla on testmigratsioonid uue paneeli väljatöötamise protsessis kõige keerulisem asi.
Pärast uuesti kontrollimist sulgesime vana arvelduse. Lõplik andmete migratsioon oli väga murettekitav hetk, kuid jumal tänatud, et see lõppes mõne minutiga ja ilma märgatavate probleemideta. Oli väiksemaid vigu, mille parandasime nädala jooksul. Suurem osa ajast kulus juhtunu katsetamisele.
Seejärel saatsime klientidele kirjad uue paneeli aadressi ja arveldamisega ning tegime ümbersuunamise.
Kokkuvõttes: SEE ON ELUS!
Õnnelik lõpp
Alates meie tarkvara esimestest töötundidest tundsime kõiki ülemineku rõõme. Kood oli täielikult meie oma ja mugava arhitektuuriga ning liides puhas ja loogiline.
Esimene ülevaatus pärast uue paneeli käivitamist
Käivitasime üleminekuprotsessi detsembris, 2017. aasta uusaasta eel, kui koormus oli kõige väiksem, et klientide jaoks üleminek lihtsamaks muuta - pühade eel ei tööta peaaegu keegi.
Peamine, mille oma süsteemile üleminekul saime (peale üldise töökindluse ja mugavuse), on võimalus kiiresti lisada võtmeklientide jaoks funktsioone – olla nende nägu, mitte tagumik.
Mis edasi?
Me kasvame, andmete hulk, kliendid, kliendiandmed kasvavad. Pidin taustaprogrammi lisama Memcachedi serveri ja kaks erinevate ülesannetega järjekorrahaldurit. Esiküljel on vahemälu ja oma järjekorrad.
Muidugi oli meil endiselt seiklusi, kui toode arenes ja muutus keerukamaks, näiteks kui lisasime HighLoadi.
Järgmises artiklis räägime teile, kuidas Hi-CPU tariif käivitati: riistvara, tarkvara, milliseid ülesandeid lahendasime ja mida tegime.
Allikas: www.habr.com