Aleksei Naidyonov. ITooLabs. Juhtum Go (Golang) telefoniplatvormi arendusest. Osa 1

Aleksandr Naidjonov, tegevjuht ITooLabs, räägib sideplatvormi arendamisest telekommunikatsiooni operaatoritele Go (Golang) programmeerimiskeeles. Aleksandr jagab ka kogemusi platvormi juurutamisest ja kasutamisest ühes Aasia suurimaid telekommunikatsiooni operaatoreid, kes kasutas platvormi häälsõnumite (VoiceMail) ja Virtuaalse PBX (Cloud PBX) teenuste pakkumiseks.

Aleksandr Naidjonov (edaspidi – AN): – Tere kõigile! Minu nimi on Aleksandr Naidjonov. Olen ITooLabsi direktor. Esiteks tahaksin vastata, mida ma siin teen ja kuidas ma siia sattusin.

Kui vaatate Bitrix24 turuosa (jaotises „Telefonia”), siis 14 rakendust ja 36, mis seal on (40%) – see oleme meie:

Täpsemalt öeldes on need meie partner- operaatorid, kuid kogu selle taga on meie platvorm (Platform as a Service) – see, mida me neile väikese tasu eest müüme. Just platvormi arendamisest ja sellest, kuidas me Go-sse jõudsime, tahaksin rääkida.

Numbrid meie platvormi kohta praegu:

44 operaatorpartnerit, sealhulgas «MegaFon». Me oleme üldiselt väga avatud uutele seiklustele ja meil on tegelik juurdepääs 100 miljonile abonendile 44 operaatorilt siin Venemaal. Seetõttu, kui kellelgi on äriideid, oleme alati valmis kuulama.

• 5000 kasutajafirmat.
• Kokku 20 000 abonenti. Kõik see on B2B – me töötame ainult ettevõtetega.
• 300 kõnet minutis päevasel ajal.
• Eelmisel aastal 100 miljonit kõnetundi (me tähistasime seda). See ei arvestanud meie platvormil toimuvaid siseseid kõnesid.

Kuidas see kõik algas?

Kuidas õiged tüübid oma platvormi looma hakkavad? Tuleb arvestada, et meie ajaloos oli ka 'hardsell-ettevõtte' arendus, ja veel õigeaegselt ettevõtte jaoks! See oli see õnnelik aeg, kus lähed kliendi juurde ja ütled: 'Vajame veel paar serverit.' Ja klient: 'Pole probleemi! Meil on rack'is kümneid.'

Seetõttu tegelesime Oracle'i, Java, WebSphere'i, Db2 ja muu taolisega. Me valisime loomulikult parimad tarnijate lahendused, integreerisime need ja proovisime nendega tõusta. Tegime seda omaette. See oli nagu sisemine start-up.

Kõik see algas 2009. aastal. Alates 2006. aastast oleme tihedalt tegelenud operaatorilahendustega. Valmistasime mitmeid eritellimusel valmistatud virtuaalseid PSTN-i, nagu see, mis meil praegu tellida on: vaatlesime, otsustasime, et see on hea, ja otsustasime luua sisemise start-up'i.

Võtsime VMWare'i. Kuna tegime seda oma vahenditega, pidime kohe loobuma kallist tarnijate salvestusest. Me teame nende kohta kõike: lubadused tuleb jagada kolme ja hind korrutada kümnega. Seetõttu tegime DirDB ja nii edasi.

Siis hakkas see kasvama. Sellele lisandus arveldusteenus, kuna platvorm ei suutnud enam hakkama saada. Siis kolis arvelduse server MySQL-st Mongo-le. Tulemuseks oli töötav lahendus, mis töötleb kõiki sinna kõige lähenenud kõnesid:

Aga kuskil seal sees keerleb see vendor-toode – peamine, tuumik, mille me kunagi valisime. Umbes 2011. aasta lõpus mõistsime, et see toode on meie peamine kitsaskoht – me jõuame just sellesse. Me nägime end ees seina, mille poole me täies hoos jookseme, kuna kliendid tulid juurde.
Seega pidiime midagi ette võtma. Loomulikult tegime üsna pikka aega erinevate toodete – nii avatud lähtekoodiga kui ka vendorite – uuringuid. Ma ei hakka praegu sellele peatuma – teema ei ole see. Viimane varuplaan, mille üle me rääkisime, oli omaenda platvormi loomine.

Lõppkokkuvõttes jõudsimegi selle valikuni. Miks? Sest kõik vendorite ja avatud lähtekoodiga tooted on loodud 10-aastase taguse probleemide lahendamiseks. Hea küll, kui 10 aastat, mõned on aga vanemad! Meile osutus valik selgeks: kas loobume oma kaunilt ideest ideaalsest teenusest (partnerite, operaatorite ja enda jaoks), või teeme midagi ise.

Otsustasime teha midagi ise!

Platvormi nõuded

Kui millegagi pikka aega tegeled (kasutad kellegi teise toodet), siis hakkavad peas tasapisi mõtted liikuma: kuidas ma teeksin seda ise? Kuna meie ettevõttes on kõik programmeerijad (välja arvatud müüjad, mitte-programmeerijaid pole), on meil nõuded juba ammu välja kujunenud ja need on selged:

1. Kiire arenduskiirus. Valmistooted, mis meid vaevasid, ei sobinud meile eelkõige selle pärast, et kõik toimus aeglaselt ja vaevaliselt. Me soovisime kiiresti – meil oli palju ideid! Meil on ka praegu palju ideid, kuid tookord oli ideeideede nimekiri niinavõrd pikk, et tundus nagu oleksime kümme aastat ette vaatamas. Praegu on see vaid aasta.
2. Maksimaalne mitme tuuma kasutamine. See oli meile samuti oluline, kuna nägime, et tuumade arv suureneb pidevalt.
3. Kõrge usaldusväärsus. See on ka asi, mille pärast oleme palju nutnud.
4. Kõrge tõrke kindlus.
5. Soovisime lõpuks jõuda protsessini, mille korraldamine toimuks igapäevaste väljalaskepunktide kaudu. Selleks vajasime keele valikut.

Seega, meie endi toodet toetavad nõuded viivad ilmnevalt loogiliselt keele nõudeni.

1. Kui vajame mitme tuuma süsteemide tuge, on meil vaja ka paralleelse täitmise tuge.
2. Kui me vajame arenduse kiirust, vajame me keelt, mis toetab konkurentsset arendust, konkurents-programmeerimist. Kui keegi ei ole kunagi kokku puutunud erinevusega, siis see on väga lihtne:
   • paralleelprogrammeerimine – see puudutab kaht erinevat lõime, mis töötavad erinevates tuumades;
   • konkurentsiline täitmine, täpsemalt konkurentsi toetas – see on see, kuidas keel (või tööaeg, pole vahet) aitab peita kogu keerukuse, mis tuleneb paralleelsest täitmisest.
3. Kõrge vastupidavus. Ilmselgelt oli meil vaja klastrit, ja see pidanuks olema parem kui see, mis meil oli tarnija tootes.

Meil ei olnud tegelikult palju variante, kui meenutada. Esiteks, „Erlang“ – me armastame seda ja tunneme seda, see oli minu isiklik, isiklik lemmik. Teiseks, Java – isegi mitte Java, vaid konkreetne Scala. Kolmandaks, keel, mida me sel hetkel üldse ei teadnud – Go. See oli just turule tulnud, täpsemalt umbes kaks aastat olemas olnud, kuid veel ei olnud avaldanud.

Võitis Go!

Go ajalugu

Meie loodud platvorm on sellel. Proovin selgitada, miks.

Lühike ajalugu Go-st. See käivitus 2007. aastal, avati 2009. aastal, esimene versioon ilmus 2012. aastal (see tähendab, et me hakkasime töötama juba enne esimest väljaannet). Algataja oli Google, kes soovis ilmselt Java-d asendada.

Autorid on väga tuntud:

• Ken Thompson, kes seisis Unix’i taga, mõtles välja UTF-8, töötas Plan 9 süsteemi kallal;
• Rob Pike, kes koos Keniga mõtles välja UTF-8, töötas samuti Plan 9, Inferno ja Limbo kallal Bell Labs’is;
• Robert Griesemer, keda me tunneme ja armastame selle eest, et ta mõtles välja Java HotSpot Compileri ja töötas V8 (Google’i Javascript’i tõlgendaja) generaatori kallal;
• Ja üle 700 osaleja, sealhulgas mõned meie plaastrid.

Go: esimene pilk

Näeme, et keel on enam-vähem lihtne ja arusaadav. Meil on ilmseid tüüpe: mõnel juhul tuleb neid deklareerida, mõnel juhul mitte (see tähendab, et tüübid tuletatakse, niikuinii).

On näha, et struktuure on moes kirjeldada. On näha, et meil on pointeri kontseptsioon (seal, kus on tähekene). On näha, et massiivide ja assotsiatiivsete massiivide deklareerimiseks ja initsialiseerimiseks on spetsiaalne tugi.

Umbes selge – elada on võimalik. Proovime kirjutada Hello, world:

Mida näeme? See on C-sarnane süntaks, semikoolon ei ole kohustuslik. See võib olla kahe rea eraldaja, kuid ainult juhul, kui need on kaks konstruktsiooni, mis on tõepoolest ühel real.

Näeme, et juhtimistruktuurides (14. reas) on sulud mitte kohustuslikud, kuid süklites on need alati vajalikud. Näeme, et tüüpimine on staatiline. Enamikul juhtudel tuletatakse tüüp automaatselt. See näide on natuke keerulisem kui tavaline Hello, world – lihtsalt, et näidata, et on olemas teek.

Mida veel olulist näeme? Kood on organiseeritud pakettidesse. Ja et pakketti oma koodis kasutada, tuleb see importida import-direktiivi abil – see on samuti oluline. Käivitame – töötab. Suurepärane!

Proovime edasi midagi keerulisemat: Hello, world, kuid nüüd on see http-server. Mida huvitavat siin näeme?

Esiteks, funktsioon käitub parameetrina. See tähendab, et funktsioon on meil – "esmaklassiline kodanik" ning sellel on funktsionaalses stiilis palju huvitavat teha. Järgmisena näeme ootamatut: import direktiiv viitab otse GitHubi hoidurile. Kõik on õige, just nii ongi – veelgi enam, just nii tulekski teha.

Go keeles on paketi universaalne identifikaator selle hoiduri url. On olemas spetsiaalne tööriist Goget, mis läheb läbi kõikidest sõltuvustest, alla laadib need, installib, kompileerib ja valmistab need kasutamiseks ette, kui on vajalik. Samuti teab Goget html-meta kohta. Seega, on võimalik hoida http-katalooge, kus on lingid konkreetsetele oma hoidurile (nagu näiteks meie teeme).

Mida me veel näeme? Http ja Json on standardkasutuses. Omandatud on, ilmselt, introspektsioon – reflection, mida tuleks kasutada encoding/json'is, kuna me anname sellele lihtsalt mingi suvalise objekti.

Käivitame ja näeme, et oleme 20 reaga saanud kasuliku koodi, mis kompileerub, käivitub ja annab välja masina praeguse keskmise koormuse (masinal, kus see on käivitunud).
Mis on veel oluline, mida me siin kohe näeme? See kompileeritakse üheks staatiliseks binaariks (buinary). Sellel binaaril pole üldse mingeid sõltuvusi, ei ole raamatukogusid! Seda saab kopeerida igasse süsteemi, kohe käivitada ja see töötab.

Liigume edasi.

Go: meetodid ja liidesed

Go-l on meetodid. Sa saad deklareerida meetodi igasuguse kasutaja tüübi jaoks. Ja see ei pea olema struktuur, vaid võib olla ka mõne tüübi alias. Sa saad deklareerida alias'i N32-le ja kirjutada selle jaoks meetodeid, et teha midagi kasulikku.

Ja siin me esmakordselt saame takistuse... Selgub, et Go-l ei ole klasside mõistet nagu sellist. Need, kes tunnevad Go-d, võivad öelda, et seal on tüüpide kaasamine, kuid see on hoopis midagi muud. Mida varem arendaja lõpetab selle mõtlemise kui pärimisele, seda parem. Go-s klassid puuduvad ja pärimist samuti ei ole.

Küsimus! Mida on autorite ettevõte Google'i juhatuses meile andnud, et kuvada kogu selle maailma keerukust? Nad andsid meile liidesed!

Liides on spetsiaalne tüüp, mis võimaldab kirjutada lihtsalt meetodeid ja meetodite signatuure. Iga tüüp, mille jaoks need meetodid eksisteerivad (teostatakse), vastab sellele liidesele. See tähendab, et saate lihtsalt kirjeldada vastavat funktsiooni ühe tüübi jaoks, teise (mis vastab sellele liidese tüübile) jaoks. Seejärel deklareerige muutuja selle liidese tüübina ja määrake sellele ükskõik milline neist objektidest.

Hardcore'i armastajatele võin öelda, et selles muutujas on tegelikult kaks viidatud: üks andmete, teine spetsiaalse descriptorite tabeli peale, mis on iseloomulik just sellele konkreetsele tüübile, selle liidese tüübile. See tähendab, et kompilaator loob sellised descriptorite tabelid linkimise ajal.

Go-s on loomulikult ka void viidatud. Sõna interface {} (kaks kaarvilist sulgu) on muutuja, mis võimaldab viidata põhimõtteliselt igale objektile.
Siiani on kõik korras, kõik on harjumuspärane. Pole midagi üllatavat.

Go: goroutines

Nüüd jõuame sinna, mis köitis tähelepanu: kerged protsessid – goroutines Go terminoloogias.

1. Esiteks, need on tõeliselt kerged (alla 2 KB).
2. Teiseks, nende gorutiinide loomise kulud on tühised: neid saab luua kuni tuhat sekundis – midagi ei juhtu.
3. Nendega tegeleb nende enda ajakava, mis lihtsalt edastab juhtimise ühelt gorutiinilt teisele.
4. Juhtimine edastatakse järgmistel juhtudel:
   • kui kohtub go väljendiga (kui gorutiin käivitab järgmise gorutiini);
   • kui aktiveeritakse blokeeriv sisendi/välja kutsumine;
   • kui algatatakse prügi kogumine;
   • kui käivitatakse mõni operatsioon kanalitega.

See tähendab, et iga kord, kui Go programm käivitatakse arvutis, määrab see süsteemi tuumade arvu, käivitab vajalike lõimede arvu (nii palju tuumasid süsteemis või nii palju kui teie selle määrate). Vastavalt sellele käivitab ajakava kõik need kerged täitmisvood kõigis vajalikest operatsioonisüsteemi lõimedes igas tuumas.

Oluline on märkida, et see on kõige tõhusam viis riistvara käitlemiseks. Lisaks sellele pakume me veel palju muud. Näiteks arendame DPI-süsteeme, mis võimaldavad ühes ühikus hallata 40 gigabitti (sõltuvalt, mis toimub nende ridade sees).

Seal kasutasime juba Go eel sama skeemi just sellel põhjusel: see aitab säilitada protsessori vahemälu lokaalsust ning märgatavalt vähendada operatiiv süsteemi kontekstitühjendusi (mis samuti võtab palju aega). Kordan: see on kõige tõhusam viis riistvara kasutamiseks.

See lihtne 21-realine näide on näiteks, mis loob lihtsalt echo-serveri. Pange tähele, et funktsioon serve on äärmiselt lihtne ja lineaarne. Seal ei ole ühtegi tagasisidet, mingit vajadust muretseda ja mõelda... Sa lihtsalt loed ja kirjutad!

Samuti, kui sa loed ja kirjutad, peaks see tegelikult blokeerima – see gorutiin pannakse lihtsalt ootejärjekorda ja selle tõmbab planeerija välja siis, kui see uuesti täitmiseks võimalikult muutub. Seega võib see lihtne kood töötada echo-serverina nii palju ühendusi, kui operatsioonisüsteem sellel masinal lubab.

Peagi on see tulemas…

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com