Алексей Найденов. ITooLabs. Случай за разработка на телефонна платформа Go (Golang). Част 1

Алексей Найденов, изпълнителен директор ITooLabs, разказва за разработването на телекомуникационна платформа за телеком оператори на езика за програмиране Go (Golang). Алексей също така споделя опита си от внедряването и работата на платформата в един от най-големите азиатски телекомуникационни оператори, който използва платформата за предоставяне на услуги за гласова поща (VoiceMail) и виртуална телефонна централа (Cloud PBX).

Алексей Найденов (по-нататък - АН): - Здравейте всички! Казвам се Алексей Найденов. Аз съм директор на ITooLabs. Първо бих искал да отговоря какво правя тук и как се озовах тук.

Ако погледнете Bitrix24 Marketplace (раздел „Телефония“), тогава 14 приложения и 36, които са там (40%), сме ние:

По-точно това са нашите партньорски оператори, но зад всичко това стои нашата платформа (Platform as a Service) – това, което им продаваме за дребни стотинки. Всъщност бих искал да говоря за развитието на тази платформа и как стигнахме до Go.

Числата за нашата платформа сега са:

44 партньорски оператора, включително MegaFon. Най-общо казано, обичаме да се впускаме в приключения и всъщност имаме достъп до 100 милиона абонати на 44 оператора тук в Русия. Ето защо, ако някой има някакви бизнес идеи, винаги сме щастливи да ги изслушаме.

• 5000 потребителски компании.
• Общо 20 000 абонати. Всичко е b2b - работим само с фирми.
• 300 разговора на минута през деня.
• 100 милиона минути разговори миналата година (празнувахме). Това е без да се вземат предвид вътрешните преговори, които са на нашата платформа.

Как започна?

Как правилните пичове започват да правят своя собствена платформа? Трябва също така да вземем предвид, че имахме история на развитие на "твърдо предприятие" и дори в най-точното време на годината за предприятие! Беше онова щастливо време, когато дойдеш при клиента и кажеш: „Имаме нужда от още няколко сървъра.“ И клиентът: „Да, няма въпрос! Имаме десетка в багажника.

Така че направихме Oracle, Java, WebSphere, Db2 и всичко това. Затова взехме, разбира се, най-добрите решения на доставчиците, интегрирахме ги и се опитахме да излетим с тях. Играеха сами. Би било такъв вътрешен стартъп.

Всичко започна през 2009 г. От 2006 г. ние сме тясно ангажирани в решенията на операторите, по един или друг начин. Направихме няколко персонализирани виртуални телефонни централи (като това, което сега имаме по поръчка): погледнахме, решихме, че е добре и решихме да раздвижим вътрешно стартиране.

Вземете VMWare. Тъй като вървяхме сами, трябваше незабавно да изоставим готиния доставчик Storage. Ние знаем всичко за тях: че обещанията трябва да се разделят на 3, а цената трябва да се умножи по 10. Затова направихме DirDB и т.н.

След това започна да расте. Услугата за таксуване беше добавена към това, тъй като платформата вече не можеше да се справи. След това сървърът за таксуване от MySQL се премести в Mongo. В резултат на това получихме работещо решение, което обработва всички повиквания, които отиват там:

Но някъде вътре се върти същият продукт на доставчика - основният, ядрен, който някога взехме. Приблизително в края на 2011 г. осъзнахме за себе си, че основното пречка за нас, разбира се, ще бъде този конкретен продукт - ще се сблъскаме с него. Видяхме стена пред нас, в която се втурнахме в пълен галоп, докато клиентите вървяха, бяха добавени.
Съответно трябваше да направим нещо. Разбира се, направихме доста проучвания за различни продукти - както с отворен код, така и такива от доставчици. Няма да се спирам на това сега - не е това въпросът. Последният резервен вариант, за който помислихме, беше да направим наша собствена платформа.

В крайна сметка стигнахме до този вариант. Защо? Защото всички доставчици и продукти с отворен код са направени за решаване на проблеми преди 10 години. Е, ако е 10-годишен, и още няколко! Изборът за нас стана очевиден: или се сбогуваме с нашата страхотна идея за идеална услуга (за партньори, оператори и себе си), или правим нещо свое.

Решихме да направим нещо различно!

Изисквания за платформата

Ако правите нещо дълго време (експлоатирате нечий друг продукт), тогава в главата ви бавно се формира мисълта: как бих го направил сам? Тъй като всички в компанията сме програмисти (с изключение на продавачите, няма непрограмисти), нашите изисквания са били формирани дълго време и са били ясни:

1. Висока скорост на развитие. Продуктът на продавача, който ни измъчваше, не ни устройваше на първо място, защото всичко се получаваше дълго и бавно. Искахме бързо – имахме много идеи! Все още имаме много идеи, но тогава списъкът с идеи беше такъв, че изглеждаше като десет години напред. Сега само за една година.
2. Максимално оползотворяване на многоядреното желязо. Това също беше важно за нас, защото видяхме, че ще има само все повече и повече ядра.
3. Висока надеждност. Този, който също плакахме.
4. Висока отказоустойчивост.
5. Искахме да завършим с ежедневен процес на освобождаване. За да направим това, ни трябваше избор на език.

Съответно, от изискванията към продукта, които сме си представили, явно логично растат и изискванията към езика.

1. Ако искаме поддръжка за многоядрени системи, тогава имаме нужда от поддръжка за паралелно изпълнение.
2. Ако се нуждаем от скорост на разработка, имаме нужда от език, който поддържа конкурентно развитие, конкурентно програмиране. Ако някой не е срещал разликата, тогава е много проста:
   • паралелното програмиране е за това как две различни нишки работят на различни ядра;
   • едновременното изпълнение, по-специално поддръжката на едновременност, е за това как езикът (или времето за изпълнение, каквото и да е) помага да се скрие цялата сложност, която идва от паралелното изпълнение.
3. Висока стабилност. Очевидно се нуждаехме от клъстер и той беше по-добър от това, което имахме в продукта на доставчика.

Всъщност нямахме много възможности, ако си спомняте. Първо, Erlang - ние го обичаме и го знаем, това беше моят личен, личен фаворит. Второ, Java дори не е Java, а конкретно Scala. Трето, езикът, който тогава изобщо не знаехме - Го. Току-що се появи тогава, по-точно съществуваше от около две години, но все още не беше пуснат.

Победени Go!

История на Go

На него направихме платформа. Ще се опитам да обясня защо.

Кратка история на Go. Започнато през 2007 г., отворено през 2009 г., първата версия беше пусната през 2012 г. (тоест започнахме да работим още преди първото издание). Инициаторът беше Google, който искаше да замени, както подозирам, Java.

Авторите са много известни:

• Кен Томсън, който стоеше зад Unix, изобрети UTF-8, работи върху системата Plan 9;
• Роб Пайк, който проектира UTF-8 с Кен, също работи върху Plan 9, Inferno, Limbo в Bell Labs;
• Робърт Гизмър, когото познаваме и обичаме за изобретяването на Java HotSpot Compiler и за работата по генератора във V8 (интерпретатора на Javascript на Google);
• И над 700 сътрудници, включително някои от нашите корекции.

Погледнете с един поглед

Виждаме, че езикът е повече или по-малко прост и разбираем. Имаме очевидни типове: в някои случаи те трябва да бъдат декларирани, в други не (което означава, че типовете така или иначе се извеждат).

Вижда се, че е модерно да се описват структури. Вижда се, че имаме концепцията за указател (където е звездичката). Вижда се, че има специална поддръжка за деклариране на инициализация на масиви и асоциативни масиви.

Приблизително разбираемо - можете да живеете. Опитвам се да напиша Здравей, свят:

какво виждаме Това е C-подобен синтаксис, точката и запетая не е задължителна. Може да бъде разделител за два реда, но само ако това са две конструкции, които са точно на един ред.

Виждаме, че скобите в контролните структури (на 14-ия ред) не са задължителни, но фигурните винаги са задължителни. Виждаме, че писането е статично. Тим в повечето случаи се показва. Този пример е малко по-сложен от обичайния Hello, world - само за да покаже, че има библиотека.

Какво друго виждаме важно? Кодът е организиран в пакети. И за да използвате пакета във вашия собствен код, трябва да го импортирате с помощта на директивата за импортиране - това също е важно. Започваме - работи. Страхотен!

Нека опитаме нещо по-сложно: Здравей, свят, но сега е http сървър. Какво интересно виждаме тук?

Първо, функцията действа като параметър. Това означава, че функцията, която имаме, е „първокласен гражданин“ и можете да правите много интересни неща с нея във функционален стил. След това виждаме неочакваното: директивата за импортиране препраща директно към хранилището на GitHub. Точно така, така е – нещо повече, така трябва да се постъпва.

В Go универсалният идентификатор на пакета е URL адресът на неговото хранилище. Има специална помощна програма Goget, която работи за всички зависимости, изтегля ги, инсталира ги, компилира ги и ги подготвя за използване, ако е необходимо. В същото време Goget знае за html-meta. Съответно можете да поддържате http директория, която ще съдържа връзки към конкретното ви хранилище (както правим ние например).

Какво друго виждаме? Http и Json в обикновената библиотека. Очевидно има интроспекция - рефлексия, която трябва да се използва в кодирането / json, защото ние просто заместваме някакъв произволен обект за него.

Пускаме го и виждаме, че имаме 20 реда полезен код, който компилира, изпълнява и дава текущото средно натоварване на машината (на машината, на която работи).
Какво друго е важно от това, което виждаме веднага тук? Той се компилира в един статичен двоичен файл (buinary). Този двоичен файл няма никакви зависимости, няма библиотеки! Може да се копира във всяка система, да се стартира веднага и ще работи.

Преминавайки.

Go: методи и интерфейси

Go има методи. Можете да декларирате метод за всеки потребителски тип. Освен това, това не е непременно структура, но може да бъде псевдоним от някакъв тип. Можете да декларирате псевдоним за N32 и да напишете методи, за да направи нещо полезно.

И тук изпадаме в ступор за първи път ... Оказва се, че Go няма класове като такива. Тези, които познават Go може да кажат, че има включване на типове, но това е съвсем различно. Колкото по-скоро разработчикът спре да мисли за това като за наследство, толкова по-добре. В Go няма класове, няма и наследяване.

Въпрос! Какво ни даде компанията от автори, ръководена от Google, за да покажем сложността на света? Дадени са ни интерфейси!

Интерфейсът е специален тип, който ви позволява да пишете прости методи, сигнатури на методи. Освен това всеки тип, за който тези методи съществуват (се изпълняват), ще съответства на този интерфейс. Това означава, че можете просто да напишете съответната функция за един тип, за друг (който съответства на този тип интерфейс). След това декларирайте променлива от типа на този интерфейс и присвоете някой от тези обекти към нея.

За хардкор феновете мога да кажа, че тази променлива всъщност ще съдържа два указателя: един към данни, а другият към специална дескрипторна таблица, която е специфична за този конкретен тип, към интерфейса на този тип. Тоест, компилаторът прави такива таблици с дескриптори по време на свързване.

И, разбира се, има указатели за празнота в Go. Думата интерфейс {} (с две фигурни скоби) е променлива, която ви позволява да посочите всеки обект по принцип.
Дотук всичко е наред, всичко е познато. Нищо изненадващо.

Отидете: goroutines

Сега стигаме до това, което ни интересува: леки процеси - горутини (goroutines) в терминологията на Go.

1. Първо, те са наистина леки (по-малко от 2 Kb).
2. Второ, разходите за създаване на такава goroutine са незначителни: можете да създадете хиляда от тях в секунда - нищо няма да се случи.
3. Те се обслужват от техен собствен планировчик, който просто прехвърля контрола от една горутина на друга.
4. В този случай контролът се прехвърля в следните случаи:
   • ако се срещне оператор go (ако goroutine стартира следващата goroutine);
   • ако е разрешено блокиращо входно/изходно повикване;
   • ако се задейства събиране на боклук;
   • ако се стартира някаква операция с канали.

Тоест, всеки път, когато програма Go се изпълнява на компютър, тя открива броя на ядрата в системата, стартира толкова нишки, колкото е необходимо (колко ядра има системата или колко сте й казали). Съответно планировчикът ще изпълнява тези леки нишки за изпълнение на всички тези нишки на операционната система във всяко ядро.

Трябва да се отбележи, че това е най-ефективният начин за оползотворяване на желязото. Освен това, което сме показали, ние правим много повече. Ние правим, например, DPI системи, които позволяват обслужване на 40 гигабита в едно устройство (в зависимост от това какво се случва в тези линии).

Там, дори преди Go, използвахме точно същата схема точно поради тази причина: тъй като ви позволява да запазите местоположението на кеша на процесора, значително да намалите броя на превключванията на контекста на ОС (което също отнема много време). Повтарям: това е най-ефективният начин за използване на желязото.

Този прост пример от 21 реда е пример, който просто прави ехо-сървър. В същото време имайте предвид, че функцията за обслужване е изключително проста, тя е линейна. Няма обаждания, няма нужда да се мъчите и мислите... Просто четете и пишете!

В същото време, ако четете и пишете, това всъщност трябва да блокира - тази goroutine просто се поставя на опашка и се взема от планировчика, когато изпълнението стане възможно отново. Това означава, че този прост код може да действа като ехо сървър за толкова връзки, колкото операционната система на тази машина позволява.

Продължение съвсем скоро...

Малко реклами 🙂

Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, облачен VPS за разработчици от $4.99, уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да споделите сървър? (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV от $199 в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за Как да изградим инфраструктура Corp. клас с използване на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за стотинка?

Източник: www.habr.com