Отново публикуваме транскрипцията на доклада от конференцията HighLoad++ през 2016 г., която се проведе в подмосковното Сколково на 7—8 ноември миналата година. Владимир Протасов разказва как да разширим функционалността на NGINX с помощта на OpenResty и Lua.

Здравейте, аз съм Владимир Протасов, работя в Parallels. Ще ви разкажа малко за себе си. През три четвърти от живота си пиша код. Станах програмист до мозъка на костите в буквалния смисъл: понякога сънувам код. Четвърт от живота си съм в индустриална разработка, пишейки код, който отива директно в продукция. Код, с който някои от вас работят, но дори не подозират.

За да разберете колко лошо беше. Когато бях малък джуниор, дойдох и ми дадоха двутерабайтови бази. Сега тук на всички им е highload. Ходих на конференции, питах: „Хей, разкажете, имате ли big data, всичко е супер? Колко големи са вашите бази?“ Отговаряха: „Имаме 100 гигабайта!“ Аз казвах: „Супер, 100 гигабайта!“ А за себе си мислех как да задържа покерфейса си. Мислиш си, да, ребята са готини, а след това се връщаш и се занимаваш с тези многотерабайтни бази. И това беше, когато бях джуниор. Представяте ли си какъв удар е това?

Зная повече от 20 програмни езика. Това е нещо, с което трябваше да се справя по време на работата. Дават ти код на Erlang, на C, на C++, на Lua, на Python, на Ruby, на нещо друго и ти трябва да се справиш с всичко това. В общи линии, трябваше. Не успях да преброя точно, но изгубих сметката някъде след 20.

Тъй като всички присъстващи знаят какво е Parallels и с какво се занимаваме, няма да говоря за това колко сме велики и какво правим. Ще кажа само, че имаме 13 офиса по света, повече от 300 служители, разработка в Москва, Талин и Малта. При желание можеш да вземеш и да се преместиш на Малта, ако зимата е студена и искаш да затоплиш гърба си.

Конкретно нашият отдел пише на Python 2. Занимаваме се с бизнес и нямаме време да внедряваме модни технологии, затова страдаме. Имаме Django, защото там има всичко, а излишното сме изхвърлили. Също MySQL, Redis и NGINX. Има и много други готини неща. Имаме MongoDB, имаме зайци, имаме всичко — но това не е моя работа и не се занимавам с това.

OpenResty

Разказах за себе си. Нека обсъдим какво точно ще говоря днес:

Какво е OpenResty и с какво се храни?
Защо да изобретяваме още един велосипед, когато имаме Python, NodeJS, PHP, Go и други страхотни неща, с които всички сме доволни?
И малко примери от живота. Нужно ми беше да съкратя презентацията си значително, защото тя беше с продължителност 3,5 часа, така че примерите ще бъдат малко.

OpenResty е NGINX. Благодарение на него имаме пълноценен уеб сървър, който е добре написан и работи бързо. Мисля, че повечето от нас използват NGINX в продукция. Всички знаете, че е бърз и супер. В него е реализирано страхотно синхронно въвеждане/извеждане, така че не е нужно да изобретявате отново колелото, както направиха в Python с gevent. Gevent е страхотен, но ако напишете код на C и нещо се обърка, то ще се побъркате при дебъгването му. Аз имах опит: отне ми цели два дни, за да разбера какво не е наред. Ако някой не беше исследвал проблема в продължение на няколко седмици, не беше го публикувал в интернет и Google не го беше намерил, щяхме да бъдем наистина в затруднение.

В NGINX вече са направени кеширане и статичен контент. Не е нужно да се тревожите как да го направите по правилния начин, за да не се забавя нещо или да загубите дескриптори. Nginx е много удобен за деплой, не трябва да мислите какво да използвате – WSGI, PHP-FPM, Gunicorn, Unicorn. Инсталирате Nginx, давате на администраторите и те знаят как да работят с него. Nginx структурирано обработва заявките. Малко по-късно ще говоря за това. Кратко, той има фаза, когато само е приел заявката, след това я е обработил и накрая е предал съдържанието на потребителя.

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

Размер. Той е малък. LuaJIT дава около 100-200 килобайта overhead по памет и минимален overhead по производителност.
Скорост. Интепретатор LuaJIT в много ситуации е близък до C; в някои случаи проявява с Java, а в други - я надминава. Някога той се считаше за state of the art, най-добрият JIT компилатор. Сега има по-добри, но те са много тежки, например V8. Някои JavaScript интерпретатори и Java HotSpot са по-бързи в определени моменти, но на други места все още остават назад.
Лесно усвояване. Ако имате, да речем, кодова база на Perl и не сте Booking, няма да намерите Perl програмисти. Защото ги няма, всички са взети, а обучението им отнема време и е сложно. Ако искате програмисти на нещо друго, вероятно също ще трябва да ги преквалифицирате или да ги намерите. При Lua всичко е просто. Lua може да бъде научен от всеки начинаещ за три дни. На мен ми отне около два часа, за да се справя. След два часа вече пишех код за продукция. След седмица той замина за продукция.

В резултат това изглежда по следния начин:

Тук има много неща. В OpenResty са събрани куп модули, както луашни, така и от NGINX. И всичко е готово - деплойвате и работи.

Примери

Достатъчно с лириката, преминаваме към кода. Ето един малък Hello World:

Какво има тук? Това е NGINX местоположение. Ние не се притесняваме, не пишем собствен роутинг, не взимаме готов като имаме в NGINX, живеем добре и лениво.

content_by_lua_block – това е блок, който указва, че предоставяме съдържание чрез Lua скрипт. Взимаме променлива от NGINX remote_addr и я вмъкваме в string.format. Това е същото като sprintf, само че на Lua, само че правилно. И предоставяме на клиента.

В резултат това ще изглежда по следния начин:

Но да се върнем в реалния свят. В продукция никой не деплойва Hello World. Обикновено нашето приложение прави запитвания към базата данни или другаде и повечето време чака отговор.

Просто седи и чака. Това не е много добре. Когато идват 100,000 потребители, става много трудно. Затова да създадем просто приложение. Ще търсим картинки, например, на котки. Но няма да търсим просто така, ще разширим ключовите думи и ако потребителят е търсил 'котенца', ще му намерим котки, пухкави и др. първо трябва да получим данните от запитването на бэкенда. Изглежда така:

Две реда ви позволяват да вземете GET-параметри, без никакви трудности. След това, да кажем, от базата данни с таблица по ключова дума и разширение получаваме тази информация по стандартен SQL-запит. Всичко е просто. Изглежда така:

Свързваме библиотеката resty.mysql, която вече имаме в комплекта. Не ни трябва да инсталираме нищо, всичко е готово. Указваме как да се свържем и правим SQL-запит:

Тук е малко страшно, но всичко работи. Тук 10 — е лимитът. Извличаме 10 записа, мързеливи сме, не искаме да показваме повече. За лимита в SQL забравих.

След това намираме изображения по всички запитвания. Събираме пакет от запитвания и запълваме Lua-таблица, наречена reqs, и правим ngx.location.capture_multi.

Всички тези запитвания отиват на паралелно обработване, и ни се връщат отговори. Времето за работа е равно на времето за отговор на най-бавния. Ако всичките ни отговори дойдат за 50 милисекунди и сме изпратили сто запитвания, то отговорът ни идва за 50 милисекунди.

Тъй като сме мързеливи и не искаме да пишем обработка на HTTP и кеширане, ще накараме NGINX да свърши всичко вместо нас. Както видяхте, там имаше запитване към url/fetch, ето го:

Правим прост proxy_pass, указваме къде да се кешира, как да го направим, и всичко работи.

Но това не е достатъчно, също трябва да предадем данните на потребителя. Най-простата идея е всичко да се сериализира в JSON, лесно е, за две реда. Изпращаме Content-Type, изпращаме JSON.

Но има една трудност: потребителят не иска да чете JSON. Трябва да привличаме фронтенд разработчици. Понякога не ни се иска да го правим отначало. И SEO специалистите ще кажат, че ако търсим изображения, то е без значение за тях. А ако им предоставим някакво съдържание, те ще кажат, че нашите търсачки нищо не индексират.

Какво да правим с това? Разбира се, ще предоставим на потребителя HTML. Ръчно генерирането не е подходящо, затова искаме да използваме шаблони. За това има библиотека lua-resty-template.

Вероятно вече сте видели трите страшни букви OPM. OpenResty идва с свой пакетен мениджър, чрез който можете да инсталирате още куп различни модули, в частност lua-resty-template. Това е прост шаблонен двигател, близък до шаблоните на Django. Можете да напишете код и да направите заместване на променливи.

В резултат всичко ще изглежда горе-долу така:

Събрахме данните и отново рендерирахме шаблона в две линии. Потребителят е доволен, получи котенца. Понеже разширихме запитите, той получи и морско коте. Може би именно това е търсил, но не успя да формулира правилно запитването си.

Всичко е супер, но ние сме в развитие и не искаме все още да показваме на потребителите. Нека направим авторизация. За да направим това, да видим как NGINX обработва запита в термини на OpenResty:

Първа фаза — access, когато потребителят тъкмо е пристигнал и ние го разглеждаме, основавайки се на заглавията, IP адреса и други данни. Можем веднага да го блокираме, ако не ни харесва. Това може да се използва за авторизация или, ако получаваме много запити, можем лесно да ги спираме в тази фаза.
rewrite. Преписваме някои данни от запитването.
content. Даваме съдържанието на потребителя.
headers filter. Подменяме заглавията на отговора. Ако сме използвали proxy_pass, можем да препишем някои заглавия, преди да ги предоставим на потребителя.
body filter. Можем да подменим тялото.
log — логване. Могат да се записват логове в elasticsearch без допълнителен слой.

Нашата авторизация ще изглежда приблизително така:

Ще добавим това в location, който описахме по-рано, и ще поставим такъв код:

Проверяваме дали имаме cookie token. Ако няма, пренасочваме към авторизация. Потребителите са хитри и могат да предположат, че трябва да поставят cookie token. Затова ще го сложим и в Redis:

Кодът за работа с Redis е много прост и не се различава от другите езици. При това, целият вход/изход, както там, така и тук, е неблокиращ. Ако пишете синхронен код, той работи асинхронно. Нещо като с gevent, само че направено добре.

Нека направим самата авторизация:

Кажем, че трябва да четем тялото на запитването. Получаваме POST аргументите, проверяваме дали логинът и паролата са верни. Ако не са верни, пренасочваме към авторизация. А ако са верни, записваме token в Redis:

Не забравяйте да поставите cookie, това също се прави за две линии:

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

Минималистичен бекенд. Понякога ни трябва да предоставим съвсем малко данни в бекенда: понякога е нужно да добавим дата, понякога някакъв списък, да кажем колко потребители има в сайта, да добавим брояч или статистика. Нещо такова малко. Минималните части могат да се направят много лесно. Това ще се получи бързо, лесно и добре.
Предобработка на данни. Понякога искаме да интегрираме реклама в нашата страница, а тази реклама получаваме чрез API запитвания. Това може да се направи много лесно тук. Не зареждаме нашия бекенд, който така или иначе работи под натиск. Можем да вземем и съберем данните тук. Можем да сглобим някакъв JS или, обратно, да разделим нещо, да обработим нещо преди да го предоставим на потребителя.
Фасада за микросервиз. Това е също много добър случай, който реализирах. Преди това работих в компания Tenzor, която се занимава с електронно отчитане и осигурява отчетност за около половината на юридическите лица в страната. Ние направихме услуга, където с помощта на този механизъм са реализирани много неща: маршрутизация, авторизация и други.
OpenResty може да се използва като лепило за вашите микросервизи, което ще осигури единен достъп до всичко и единен интерфейс. Тъй като микросервизите могат да бъдат написани така, че тук имате Node.js, тук PHP, тук Python, тук нещо на Erlang, разбираме, че не искаме един и същ код да се пише навсякъде. Затова OpenResty може да се интегрира на фронта.
Статистика и аналитика. Обикновено NGINX стои на входа и всички запитвания минават през него. Именно на това място е много удобно да съберете данни. Можете да изчислите нещо веднага и да го запишете някъде, например в Elasticsearch, Logstash или просто да запишете в лог и после да го изпратите някъде.
Многопотребителски системи. Например, онлайн игри също могат да се правят много добре. Днес в Кейптаун Александър Гладыш ще разказва как бързо да се прокотипира многопотребителска игра с помощта на OpenResty.
Филтриране на запитвания (WAF). В момента е на мода да се използват различни web application firewall решения, като има много услуги, които ги предоставят. С помощта на OpenResty можете да създадете свой собствен web application firewall, който лесно и бързо ще филтрира заявките според вашите изисквания. Ако имате Python, знаете, че PHP определено няма да бъде инжектиран, освен ако разбира се, не го активирате от конзолата. Знаете, че имате MySQL и Python. Вероятно тук може да се опитат да направят някакъв directory traversal и да инжектират нещо в базата. Затова можете да филтрирате опасни заявки бързо и евтино направо на фронта.
Общество. Тъй като OpenResty е построен на базата на NGINX, той предлага и бонус – това е NGINX общността. Тя е много голяма и значителна част от въпросите, с които ще се сблъскате в началото, вече са решени от общността на NGINX.
Lua разработчици. Вчера разговарях с момчетата, които дойдоха на учебния ден HighLoad++ и чух, че само Tarantool е написан на Lua. Това не е така, на Lua са написани много неща. Примери: OpenResty, XMPP сървър Prosody, игралният двигател Love2D, Lua се използва в Warcraft и на други места. Има много Lua разработчици с голямо и отзивчиво общество. Всичките ми въпроси по Lua бяха решени в рамките на няколко часа. Когато пишех в списъка за разпространение, буквално след няколко минути получавах множество отговори с инструкции и разяснения. Това е супер. За съжаление, не навсякъде има такова добро душевно общество.
Има GitHub за OpenResty, където можете да създадете issue, ако нещо е счупено. Има списък за разпространение в Google Groups, където можете да обсъждате общи въпроси, и също така списък на китайски – ако случайно не владеете английски, а знаете китайски.

Резюме

Надявам се, че успях да предам, че OpenResty е много удобен фреймуърк, специално проектиран за уеб.
Има нисък праг на влизане, тъй като кодът е подобен на този, с който пишем, а езикът е доста прост и минималистичен.
Предлага асинхронно I/O без колбекове, така че няма да имаме заплетени структури, както понякога пишем в NodeJS.
Има лесен деплой, тъй като ни трябва само NGINX с необходимия модул и нашият код, и всичко веднага работи.
Голямо и отзивчиво общество.

Не разказах в детайли как се прави маршрутизиране, защото стана много дълга история.

Благодаря за вниманието!