Alekszej Naidenov, vezérigazgató , egy távközlési platform fejlesztéséről beszél távközlési szolgáltatók számára a Go (Golang) programozási nyelven. Alexey emellett megosztja tapasztalatait a platform bevezetésével és üzemeltetésével kapcsolatban az egyik legnagyobb ázsiai távközlési szolgáltatónál, amely a platformot hangposta (VoiceMail) és Virtuális PBX (Cloud PBX) szolgáltatások nyújtására használta.
Alekszej Naydenov (a továbbiakban – AN): - Sziasztok! A nevem Alekszej Naidenov. Az ITooLabs igazgatója vagyok. Először is arra szeretnék választ adni, hogy mit keresek itt, és hogyan kerültem ide.
Ha megnézi a Bitrix24 Marketplace-et ("Telefónia" szakasz), akkor 14 alkalmazás és 36 ott található (40%) mi vagyunk:
Pontosabban ezek a partner üzemeltetőink, de mindezek mögött a mi platformunk (Platform as a Service) áll - amit egy kis fillérért eladunk nekik. Valójában ennek a platformnak a fejlesztéséről szeretnék beszélni, és arról, hogyan jutottunk el a Go-hoz.
A platformunk jelenlegi számai a következők:
44 partnerszolgáltató, köztük a MegaFon. Általánosságban elmondható, hogy nagyon szeretünk különféle kalandokban részt venni, és Oroszországban 100 szolgáltató 44 millió előfizetőjéhez férünk hozzá. Ezért ha valakinek van üzleti ötlete, azt mindig szívesen meghallgatjuk.
- 5000 felhasználó cég.
- Összesen 20 feliratkozó. Ez mind b000b – csak cégekkel dolgozunk.
- 300 hívás percenként a nap folyamán.
- 100 millió hívásperc tavaly (ünnepeltük). Mindezt anélkül, hogy figyelembe vennénk a platformunkon folyó belső tárgyalásokat.
Hogyan kezdődött?
Hogyan kezdik el a megfelelő srácok saját platformjuk elkészítését? Figyelembe kell venni azt is, hogy nálunk is volt „hardcore vállalkozás” fejlesztés, méghozzá az év legpontosabb szakaszában egy vállalkozás számára! Ez volt az a boldog időszak, amikor odajön az ügyfélhez, és azt mondja: "Szükségünk van még néhány szerverre." És az ügyfél: „Igen, nem kérdés! Van egy tízesünk a rackben.
Tehát megcsináltuk az Oracle-t, a Java-t, a WebSphere-t, a Db2-t és minden mást. Ezért természetesen a legjobb szállítói megoldásokat vettük, integráltuk, és megpróbáltuk bevetni őket. Egyedül játszottak. Ez egy ilyen belső indítás lenne.
Az egész 2009-ben kezdődött. 2006 óta így vagy úgy szorosan részt veszünk az üzemeltetői döntésekben. Több egyedi virtuális alközpontot is készítettünk (mint a most megrendelt): megnéztük, úgy döntöttünk, hogy jó, és úgy döntöttünk, hogy elindítunk egy belső indítást.
Vegyük a VMWare-t. Mivel egyedül sétáltunk, azonnal el kellett hagynunk a menő Storage eladót. Mindent tudunk róluk: az ígéreteket el kell osztani 3-mal, és a költségeket meg kell szorozni 10-zel. Ezért megcsináltuk a DirDB-t és így tovább.
Aztán elkezdett növekedni. Ehhez jött hozzá a számlázási szolgáltatás, mert a platform már nem bírta. Ezután a MySQL számlázási szervere a Mongo-ba költözött. Ennek eredményeként egy működő megoldást kaptunk, amely feldolgozza az összes oda érkező hívást:
De valahol odabent ugyanaz a gyártó terméke forog – a fő, a nukleáris termék, amit valaha vettünk. Körülbelül 2011 végére magunk is rájöttünk, hogy számunkra a fő szűk keresztmetszet természetesen ez a termék lesz – bele fogunk futni. Egy falat láttunk magunk előtt, amibe teljes vágtával berohantunk, ahogy sétáltak a vásárlók, kiegészültünk.
Ennek megfelelően tennünk kellett valamit. Természetesen elég sok kutatást végeztünk különféle termékeken – mind a nyílt forráskódú, mind a gyártói termékeken. Ezen most nem térek ki – nem ez a lényeg. A legutolsó tartalék lehetőség az volt, hogy saját platformot készítünk.
Végül erre a lehetőségre jutottunk. Miért? Mert minden gyártói és nyílt forráskódú termék 10 évvel ezelőtt a problémák megoldására készült. Nos, ha egy 10 éves, és még néhány! Nyilvánvalóvá vált számunkra a választás: vagy búcsút mondunk az ideális szolgáltatásról alkotott nagyszerű ötletünknek (partnereinknek, üzemeltetőinknek és magunknak), vagy megcsinálunk valamit.
Úgy döntöttünk, hogy valami mást csinálunk!
Platformkövetelmények
Ha már régóta csinálsz valamit (valaki más termékét használod), akkor lassan megfordul a fejedben a gondolat: hogyan csinálnám ezt én? Mivel mindannyian programozók vagyunk a cégnél (kivéve az értékesítőket, nincs nem programozó), követelményeink már régen kialakultak, és egyértelműek voltak:
- Magas fejlesztési sebesség. A minket meggyötört eladó terméke eleve nem jött be, mert sokáig és lassan ment minden. Gyorsan akartunk – rengeteg ötletünk volt! Sok ötletünk van még, de akkor olyan volt az elképzelések listája, hogy úgy tűnt, tíz évre van előre. Most csak egy évig.
- A többmagos vas maximális kihasználása. Ez nekünk is fontos volt, mert láttuk, hogy csak egyre több lesz a mag.
- Magas megbízhatóság. Akit mi is sírtunk.
- Magas hibatűrés.
- Azt akartuk, hogy a végén egy napi kiadási folyamat legyen. Ehhez nyelvválasztásra volt szükségünk.
Ennek megfelelően a termékkel szemben támasztott követelményekből, amelyeket magunk elé állítottunk, egyértelműen logikus módon nőnek a nyelvi követelmények.
- Ha többmagos rendszerekhez szeretnénk támogatást, akkor a párhuzamos végrehajtás támogatására van szükségünk.
- Ha fejlesztési sebességre van szükségünk, akkor versenyképes fejlesztést támogató nyelvre, versenyképes programozásra van szükségünk. Ha valaki nem találkozott a különbséggel, akkor nagyon egyszerű:
- a párhuzamos programozás arról szól, hogy két különböző szál hogyan fut különböző magokon;
- A párhuzamos végrehajtás, pontosabban a párhuzamos végrehajtás támogatása arról szól, hogy a nyelv (vagy futásidejű, bármi) hogyan segít elrejteni a párhuzamos végrehajtásból származó összes bonyolultságot.
- Magas stabilitás. Nyilvánvalóan szükségünk volt egy klaszterre, és ez jobb volt, mint ami a gyártó termékén volt.
Nem volt sok lehetőségünk, ha emlékszel. Először is, Erlang - szeretjük és ismerjük, ez volt a személyes, személyes kedvencem. Másodszor, a Java nem is Java, hanem kifejezetten Scala. Harmadszor, a nyelv, amelyet akkoriban egyáltalán nem ismertünk - Menj. Akkor még csak megjelent, pontosabban már vagy két éve létezett, de még nem adták ki.
Legyőzött Go!
A Go története
Platformot készítettünk rá. Megpróbálom elmagyarázni, miért.
A Go rövid története. 2007-ben indult, 2009-ben nyitották meg, az első verzió 2012-ben jelent meg (vagyis már az első kiadás előtt elkezdtünk dolgozni). A kezdeményező a Google volt, amely, ahogy gyanítom, a Java-t akarta lecserélni.
A szerzők nagyon híresek:
- Ken Thomson, aki a Unix mögött állt, feltalálta az UTF-8-at, dolgozott a Plan 9 rendszeren;
- Rob Pike, aki Kennel együtt feltalálta az UTF-8-at, a Plan 9-en, az Infernón, a Limbón is dolgozott a Bell Labs-nál;
- Robert Giesmer, akit a Java HotSpot Compiler feltalálásáért és a V8-as generátoron végzett munkájáért (a Google Javascript értelmezője) ismerünk és szeretünk;
- És több mint 700 közreműködő, köztük néhány javításunk.
Menjen egy pillantással
Látjuk, hogy a nyelv többé-kevésbé egyszerű és érthető. Nyilvánvaló típusaink vannak: bizonyos esetekben deklarálni kell, máskor nem szükséges (ez azt jelenti, hogy a típusok így vagy úgy következtetnek).
Látható, hogy divat a szerkezetek leírása. Látható, hogy megvan a mutató fogalma (ahol a csillag van). Látható, hogy speciális támogatás létezik a tömbök és az asszociatív tömbök inicializálásának deklarálására.
Nagyjából érthető – lehet élni. Megpróbálok írni Hello, world:
Mit látunk? Ez C-szerű szintaxis, a pontosvessző nem kötelező. Ez lehet két sor elválasztója, de csak akkor, ha két olyan konstrukcióról van szó, amelyek pontosan ugyanabban a sorban vannak.
Látjuk, hogy a vezérlőszerkezetekben (a 14. sorban) a zárójelek nem kötelezőek, de a göndör kapcsos zárójelek mindig szükségesek. Látjuk, hogy a gépelés statikus. Tim a legtöbb esetben megjelenik. Ez a példa egy kicsit bonyolultabb, mint a szokásos Hello, world - csak azért, hogy megmutassa, hogy van könyvtár.
Mit látunk még fontosnak? A kód csomagokba van rendezve. És ahhoz, hogy a csomagot saját kódjában használhassa, importálnia kell az import direktíva segítségével - ez is fontos. Kezdjük – működik. Nagy!
Próbáljunk meg valami bonyolultabbat: Hello, világ, de most egy http szerver. Mit látunk itt érdekesnek?
Először is a függvény paraméterként működik. Ez azt jelenti, hogy a funkciónk „első osztályú állampolgár”, és funkcionális stílusban sok érdekes dolgot lehet vele csinálni. Ezután valami váratlant látunk: az import direktíva közvetlenül kapcsolódik a GitHub adattárhoz. Így van, így van – ráadásul így is kell csinálni.
A Go alkalmazásban a csomag univerzális azonosítója a tárhely URL-je. Létezik egy speciális Goget segédprogram, amely az összes függőséget kezeli, letölti, telepíti, lefordítja, és szükség esetén előkészíti használatra. Ugyanakkor Goget tud a html-metáról. Ennek megfelelően tarthat egy http könyvtárat, amely tartalmazni fogja az adott tárhelyre mutató hivatkozásokat (ahogyan például mi is tesszük).
Mit látunk még? Http és Json a normál könyvtárban. Nyilvánvalóan létezik az introspekció - reflexió, amelyet a / json kódolásánál kell használni, mert egyszerűen behelyettesítünk valamilyen tetszőleges objektumot.
Lefuttatjuk és azt látjuk, hogy van 20 soros hasznos kódunk, ami lefordítja, lefutja és jelenti a gép aktuális átlagos terhelését (azon a gépen, amelyiken elindul).
Mi még fontos abból, amit itt azonnal láthatunk? Egy statikus binárisba (buinary) fordítódik. Ennek a binárisnak egyáltalán nincsenek függőségei, nincsenek könyvtárai! Bármilyen rendszerre átmásolható, azonnal lefuttatható, és működni fog.
Áttérve.
Go: metódusok és interfészek
A Gonak vannak módszerei. Bármilyen egyéni típushoz deklarálhat metódust. Ráadásul ez nem feltétlenül egy szerkezet, hanem lehet valamilyen típusú álnév. Deklarálhat egy álnevet az N32 számára, és metódusokat írhat neki, hogy valami hasznosat tegyen.
És itt esünk először kábulatba... Kiderült, hogy a Go-nak nincsenek órái. Aki ismeri a Go-t, azt mondhatja, hogy létezik típusinklúzió, de ez teljesen más. Minél előbb hagyja abba a fejlesztő, hogy öröklődésnek gondolja, annál jobb. A Go-ban nincsenek osztályok, és nincs öröklés sem.
Kérdés! Mit adott nekünk a Google vezette szerzői társaság, hogy megmutassuk a világ összetettségét? Kaptunk felületeket!
Az interfész egy speciális típus, amely lehetővé teszi egyszerű metódusok, metódus-aláírások írását. Továbbá minden olyan típus, amelyre ezek a metódusok léteznek (végrehajtva), megfelelnek ennek az interfésznek. Ez azt jelenti, hogy egyszerűen megírhatja a megfelelő függvényt az egyik típushoz, a másikhoz (ami az adott interfész típusnak felel meg). Ezután deklaráljon ennek az interfésznek egy típusú változóját, és rendelje hozzá az objektumok bármelyikét.
A hardcore rajongók számára elmondhatom, hogy ez a változó valójában két mutatót fog tartalmazni: az egyik az adatokra, a másik egy speciális leíró táblázatra, amely erre a típusra jellemző, az ilyen típusú interfészre. Azaz a fordító ilyen leíró táblázatokat készít a linkeléskor.
És természetesen vannak olyan mutatók, amelyek érvénytelenek a Go-ban. A szó interfész {} (két kapcsos kapcsos zárójellel) egy olyan változó, amely lehetővé teszi, hogy elvileg bármilyen objektumra mutassunk.
Eddig minden rendben van, minden ismerős. Semmi meglepő.
Menj: gorutin
Most elérkezünk a minket érdeklő dolgokhoz: könnyű folyamatok - gorutinok (gorutinok) a Go terminológiában.
- Először is, nagyon könnyűek (kevesebb, mint 2 KB).
- Másodszor, egy ilyen gorutin létrehozásának költsége elhanyagolható: másodpercenként ezret készíthet belőle - semmi sem fog történni.
- A saját ütemezőjük szolgálja ki őket, amely egyszerűen átadja az irányítást egyik gorutinról a másikra.
- Ebben az esetben az irányítás a következő esetekben kerül átadásra:
- ha go utasítással találkozunk (ha a gorutin elindítja a következő gorutint);
- ha a blokkoló bemeneti/kimeneti hívás engedélyezve van;
- ha beindul a szemétszállítás;
- ha elindul valamilyen művelet a csatornákkal.
Azaz, amikor egy Go program fut a számítógépen, akkor érzékeli a rendszer magjainak számát, annyi szálat indít el, amennyi szükséges (hány mag van a rendszerben, vagy hánynak mondtad meg). Ennek megfelelően az ütemező ezeket a könnyű végrehajtási szálakat futtatja az egyes magokban található összes operációs rendszer-szálon.
Meg kell jegyezni, hogy ez a leghatékonyabb módja a vas felhasználásának. A bemutatottakon kívül még sok mást is teszünk. Készítünk például DPI rendszereket, amelyek 40 gigabit kiszolgálását teszik lehetővé egy egységben (attól függően, hogy mi történik ezeken a vonalakon).
Ott már a Go előtt pontosan ugyanezt a sémát használtuk éppen ezért: mivel lehetővé teszi a processzor gyorsítótárának helyének mentését, jelentősen csökkenti az operációs rendszer kontextuskapcsolóinak számát (ami szintén nagyon sokáig tart). Ismétlem: ez a leghatékonyabb módja a vas hasznosításának.
Ez az egyszerű, 21 soros példa egy olyan példa, amely egyszerűen echo-szerverrel működik. Ugyanakkor vegye figyelembe, hogy a szervafüggvény rendkívül egyszerű, lineáris. Nincsenek visszahívások, nem kell vesződni és gondolkodni... Csak olvass és írj!
Ugyanakkor, ha olvas és ír, akkor valójában blokkolnia kell - ezt a gorutint egyszerűen sorba állítja, és az ütemező elveszi, amikor a végrehajtás újra lehetővé válik. Vagyis ez az egyszerű kód visszhangszerverként működhet annyi kapcsolatnál, amennyit a gép operációs rendszere megenged.
Folytatás hamarosan...
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com