Отново публикуваме транскрипцията на доклада от конференцията 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 в продукция. Всички знаете, че е бърз и страхотен. В него е реализирано чудесно синхронно портфолие, така че не е нужно да измисляте неща, подобно на каквото направихме с gevent в Python. Gevent е страхотен, но ако напишете код на C и нещо се обърка, с gevent ще изпаднете в лудост, опитвайки се да го дебъгвате. Имах опит: отне ми цели два дни да разбера какво се е объркало. Ако някой не беше се ровил месеци преди това, не беше открил проблема, не бе написал в Интернет и Google не го беше намерил, щяхме напълно да се объркаме.

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

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

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

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

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

Примери

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

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

content_by_lua_block – това е блок, който казва, че предаваме съдържание с помощта на Lua скрипт. Вземаме енджинсовата променлива 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:

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

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

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

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

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

Нека направим самото удостоверяване:

Казваме, че трябва да четем тялото на заявката. Получаваме POST аргументи, проверяваме дали логинът и паролата са правилни. Ако не са правилни, прехвърляме на удостоверяване. А ако са правилни, записваме токена в 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 бяха решени в рамките на няколко часа. Когато пишеш в списъка за разпращане, буквално след няколко минути получаваш куп отговори, обясняват какво и как, какво на какво. Това е наистина страхотно. За съжаление, не навсякъде има такава добра душевна общност.
По отношение на OpenResty има GitHub, където можете да отворите проблем, ако нещо е счупено. Има списък за разпращане в Google Groups, където можете да обсъждате общи въпроси, има разпращане на китайски — кой знае, може би не владеете английски, а знаете китайски.

Итог

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

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

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