ჩვენ კვლავ ვაქვეყნებთ კონფერენციის ანგარიშის ჩანაწერს მაღალი დატვირთვა ++ 2016 წელი, რომელიც გაიმართა სკოლკოვოში, მოსკოვის მახლობლად, გასული წლის 7-8 ნოემბერს. ვლადიმერ პროტასოვი განმარტავს, თუ როგორ უნდა გააფართოვოთ NGINX ფუნქციონირება OpenResty-ით და Lua-ით.

მოგესალმებით ყველას, მე მქვია ვლადიმირ პროტასოვი, ვმუშაობ პარალელებს. ცოტას ჩემს შესახებ მოგიყვებით. ჩემი ცხოვრების სამ მეოთხედს ვატარებ კოდების წერაში. მე გავხდი პროგრამისტი პირდაპირი გაგებით: ზოგჯერ სიზმარში კოდს ვხედავ. სიცოცხლის მეოთხედი არის ინდუსტრიული განვითარება, კოდის წერა, რომელიც პირდაპირ წარმოებაში გადადის. კოდი, რომელსაც ზოგიერთი თქვენგანი იყენებს, მაგრამ ვერ აცნობიერებს მას.

ასე რომ, გესმით, რა ცუდი იყო. ცოტა უმცროსი რომ ვიყავი, მოვედი და მომცეს ეს ორი ტერაბაიტიანი მონაცემთა ბაზა. ახლა აქ ყველასთვის დიდი დატვირთვაა. მივედი კონფერენციებზე და ვკითხე: „ბიჭებო, მითხარით, დიდი მონაცემები გაქვთ, ყველაფერი მაგარია? რამდენი ბაზა გაქვს იქ? მათ მიპასუხეს: ”ჩვენ გვაქვს 100 გიგაბაიტი!” მე ვუთხარი: "მაგარია, 100 გიგაბაიტი!" და მე ვფიქრობდი, როგორ შემენარჩუნებინა ჩემი პოკერის სახე. თქვენ ფიქრობთ, დიახ, ბიჭები მაგრები არიან და შემდეგ დაბრუნდებით და აინტერესებთ ამ მრავალ ტერაბაიტიან მონაცემთა ბაზებს. და ეს არის უმცროსი. წარმოგიდგენიათ ეს რა დარტყმაა?

მე ვიცი პროგრამირების 20-ზე მეტი ენა. ეს არის ის, რაც მე უნდა გაერკვია, როდესაც ვმუშაობდი. კოდს გაძლევენ Erlang, C, C++, Lua, Python, Ruby, რაღაც სხვა და ეს ყველაფერი უნდა გაჭრა. ზოგადად, მომიწია. ზუსტი რიცხვის დათვლა ვერ მოხერხდა, მაგრამ სადღაც 20-ში რიცხვი დაიკარგა.

რადგან ყველამ იცის რა არის პარალელები და რას ვაკეთებთ, არ ვისაუბრებ იმაზე, თუ რა მაგრები ვართ და რას ვაკეთებთ. უბრალოდ გეტყვით, რომ ჩვენ გვაქვს 13 ოფისი მთელს მსოფლიოში, 300-ზე მეტი თანამშრომელი, განვითარება მოსკოვში, ტალინსა და მალტაში. თუ სურვილი გაქვთ, შეგიძლიათ აიღოთ და გადახვიდეთ მალტაში, თუ ზამთარში ცივა და ზურგის გათბობა გჭირდებათ.

კონკრეტულად, ჩვენი განყოფილება პითონ 2-ში წერს. ჩვენ ბიზნესში ვართ და დრო არ გვაქვს მოდური ტექნოლოგიების დანერგვისთვის, ამიტომ ვიტანჯებით. ჩვენ ვიყენებთ Django-ს, რადგან მას აქვს ყველაფერი და რაც არ იყო საჭირო, ავიღეთ და გადავყარეთ. ასევე MySQL, Redis და NGINX. კიდევ ბევრი მაგარი რამე გვაქვს. ჩვენ გვაქვს MongoDB, გვყავს კურდღლები დარბიან, გვაქვს ყველაფერი - მაგრამ ეს ჩემი არ არის და მე ამას არ ვაკეთებ.

OpenResty

ჩემს თავზე ვუთხარი. მოდით გავარკვიოთ რაზე ვისაუბრებ დღეს:

• რა არის OpenResty და რითი ჭამენ?
• რატომ ხელახლა გამოვიგონოთ სხვა ბორბალი, როდესაც გვაქვს Python, NodeJS, PHP, Go და სხვა მაგარი რაღაცეები, რომლითაც ყველა კმაყოფილია?
• და რამდენიმე მაგალითი ცხოვრებიდან. ძალიან მომიწია საუბრის შემცირება, რადგან ეს იყო 3,5 საათი, ასე რომ ბევრი მაგალითი არ იქნება.

OpenResty არის NGINX. მისი წყალობით ჩვენ გვაქვს სრულფასოვანი ვებ სერვერი, რომელიც კარგად არის დაწერილი და სწრაფად მუშაობს. ვფიქრობ, უმეტესობა ჩვენგანი იყენებს NGINX-ს წარმოებაში. ყველამ იცით, რომ ის სწრაფი და მაგარია. მათ შექმნეს მაგარი სინქრონული I/O მასში, ასე რომ, ჩვენ არ გვჭირდება არაფრის ციკლი, ისევე, როგორც ისინი გააკეთეს პითონში. Gevent მაგარია, მშვენიერია, მაგრამ თუ დაწერ C კოდს და რამე არასწორედ მოხდება, მაშინ გევენტით გაგიჟდებით მისი გამართვა. მე მქონდა გამოცდილება: მთელი ორი დღე დასჭირდა იმის გარკვევას, თუ რა მოხდა იქ. თუ ვინმეს რამდენიმე კვირა არ გაეთხარა, პრობლემა არ აღმოაჩინა, დაწერა ინტერნეტში და Google-მა ვერ იპოვა, მაშინ ჩვენ სულ გავგიჟდებოდით.

NGINX-ს უკვე აქვს ქეშირება და სტატიკური შინაარსი. თქვენ არ გჭირდებათ ფიქრი იმაზე, თუ როგორ უნდა გააკეთოთ ეს ადამიანურად, რომ სადმე არ შეანელოთ, რათა სადმე არ დაკარგოთ აღწერები. Nginx ძალიან მოსახერხებელია განლაგებისთვის, თქვენ არ გჭირდებათ ფიქრი იმაზე, თუ რა უნდა აიღოთ - WSGI, PHP-FPM, Gunicorn, Unicorn. Nginx იყო დაინსტალირებული, გადაეცა ადმინისტრატორებს, მათ იციან როგორ იმუშაონ მასთან. Nginx ამუშავებს მოთხოვნებს სტრუქტურირებული გზით. ამაზე ცოტა მოგვიანებით ვისაუბრებ. მოკლედ, მას აქვს ფაზა, როდესაც მან უბრალოდ მიიღო მოთხოვნა, როდის დაამუშავა და როდის მიაწოდა კონტენტი მომხმარებელს.

Nginx მაგარია, მაგრამ არის ერთი პრობლემა: ის არ არის საკმარისად მოქნილი, თუნდაც ყველა იმ მაგარი ფუნქციით, რაც ბიჭებმა ჩასვეს კონფიგურაციაში, მიუხედავად იმისა, თუ რა შეიძლება იყოს კონფიგურირებული. ეს ძალა არ არის საკმარისი. ამიტომ ტაობაოს ბიჭებმა, დიდი ხნის წინ, როგორც ჩანს, რვა წლის წინ, ლუა ჩასვეს მასში. რას იძლევა?

• Размер. Ის პატარაა. LuaJIT იძლევა დაახლოებით 100-200 კილობაიტი მეხსიერების ზედნადებს და მინიმალურ შესრულებას.
• სიჩქარის. LuaJIT თარჯიმანი ბევრ სიტუაციაში ახლოს არის C-სთან, ზოგიერთ სიტუაციაში ის კარგავს Java-ს, ზოგიერთში კი აჯობებს მას. გარკვეული პერიოდის განმავლობაში იგი ითვლებოდა ხელოვნების დონედ, ყველაზე მაგარ JIT შემდგენლად. ახლა არის უფრო მაგარი, მაგრამ ისინი ძალიან მძიმეა, მაგალითად, იგივე V8. ზოგიერთი JS თარჯიმანი და Java HotSpot ზოგიერთ წერტილში უფრო სწრაფია, მაგრამ ზოგიერთ ადგილას ისინი მაინც კარგავენ.
• მარტივი სწავლა. თუ თქვენ გაქვთ, ვთქვათ, Perl კოდის ბაზა და არ ხართ დაჯავშნილი, ვერ იპოვით Perl პროგრამისტებს. იმის გამო, რომ ისინი არ არსებობენ, ისინი ყველა წაიყვანეს და მათი სწავლება გრძელი და რთულია. თუ პროგრამისტები სხვა რამეში გსურთ, შეიძლება ასევე მოგიწიოთ მათი გადამზადება ან პოვნა. ლუას შემთხვევაში ყველაფერი მარტივია. ლუას სწავლა ნებისმიერ უმცროსს შეუძლია სამ დღეში. დაახლოებით ორი საათი დამჭირდა ამის გასარკვევად. ორი საათის შემდეგ მე უკვე ვწერდი კოდს წარმოებაში. დაახლოებით ერთი კვირის შემდეგ ის პირდაპირ წარმოებაზე წავიდა და წავიდა.

შედეგად, ასე გამოიყურება:

აქ ბევრია. OpenResty-მ შეაგროვა უამრავი მოდული, როგორც luash, ასევე ძრავის მოდული. თქვენ კი ყველაფერი მზად გაქვთ - განლაგებული და სამუშაო.

მაგალითები

საკმარისია ლექსები, გადავიდეთ კოდზე. აქ არის პატარა Hello World:

რა არის იქ? ეს არის ენგინსის ადგილმდებარეობა. ჩვენ არ ვნერვიულობთ, ჩვენ არ ვწერთ ჩვენს მარშრუტებს, არ ვიღებთ მზას - ჩვენ ის უკვე გვაქვს NGINX-ში, ჩვენ ვცხოვრობთ კარგი და ზარმაცი ცხოვრებით.

content_by_lua_block არის ბლოკი, რომელიც ამბობს, რომ ჩვენ ვემსახურებით კონტენტს Lua სკრიპტის გამოყენებით. ჩვენ ვიღებთ Engins ცვლადს remote_addr და ჩასვით string.format. იგივეა რაც sprintf, მხოლოდ ლუაში, მხოლოდ სწორი. და ჩვენ ვაძლევთ მას კლიენტს.

შედეგად, ის ასე გამოიყურება:

მაგრამ დავუბრუნდეთ რეალურ სამყაროს. არავინ ახორციელებს Hello World წარმოებას. ჩვენი აპლიკაცია ჩვეულებრივ მიდის მონაცემთა ბაზაში ან სადმე სხვაგან და უმეტესად ელოდება პასუხს.

ის უბრალოდ ზის და ელოდება. არ არის ძალიან კარგი. როდესაც 100.000 XNUMX მომხმარებელი მოდის, ჩვენთვის ძალიან რთულია. მოდით გამოვიყენოთ მარტივი აპლიკაცია, როგორც მაგალითი. ჩვენ ვეძებთ სურათებს, მაგალითად, კატების. მაგრამ ჩვენ უბრალოდ არ მოვძებნით, ჩვენ გავაფართოვებთ საკვანძო სიტყვებს და, თუ მომხმარებელი მოძებნის "კნუტებს", ჩვენ ვიპოვით კატებს, ბეწვიან კატებს და ა.შ. პირველ რიგში, ჩვენ უნდა მივიღოთ მოთხოვნის მონაცემები ბექენდზე. ეს ასე გამოიყურება:

ორი ხაზი საშუალებას გაძლევთ აირჩიოთ GET პარამეტრები, გართულებების გარეშე. შემდეგი, ვთქვათ, მონაცემთა ბაზიდან საკვანძო სიტყვისა და გაფართოების ნიშნით, ჩვენ ვიღებთ ამ ინფორმაციას ჩვეულებრივი SQL მოთხოვნის გამოყენებით. Ეს მარტივია. ეს ასე გამოიყურება:

ბიბლიოთეკის დაკავშირება resty.mysql, რომელიც უკვე გვაქვს ნაკრებში. არაფრის დაყენება არ გვჭირდება, ყველაფერი მზადაა. ჩვენ აღვნიშნავთ, თუ როგორ უნდა დააკავშიროთ და გააკეთოთ SQL მოთხოვნა:

აქ ცოტა საშინელია, მაგრამ ყველაფერი მუშაობს. აქ 10 არის ზღვარი. ჩვენ ამოვიღებთ 10 ჩანაწერს, ჩვენ ვართ ზარმაცი, არ გვინდა მეტის ჩვენება. დამავიწყდა ლიმიტი SQL-ში.

შემდეგ ჩვენ ვპოულობთ სურათებს ყველა შეკითხვისთვის. ვაგროვებთ მოთხოვნებს და ვავსებთ ლუას ცხრილს ე.წ reqsდა ჩვენ ვაკეთებთ ngx.location.capture_multi.

ყველა ეს მოთხოვნა იგზავნება პარალელურად, პასუხები კი ჩვენთან ბრუნდება. მუშაობის დრო უდრის ყველაზე ნელის რეაგირების დროს. თუ ჩვენ ყველანი ვიღებთ 50 მილიწამში და გავგზავნეთ ასი მოთხოვნა, მაშინ პასუხს 50 მილიწამში მივიღებთ.

ვინაიდან ჩვენ ზარმაცები ვართ და არ გვინდა HTTP-ის დაწერა და ქეშირება, ჩვენ ვაიძულებთ NGINX-ს ყველაფერი გააკეთოს ჩვენთვის. როგორც ხედავთ, იყო მოთხოვნა url/fetch, ის აქაა:

ჩვენ ვამარტივებთ proxy_pass, ჩვენ მივუთითებთ, სად უნდა ქეში, როგორ გავაკეთოთ ეს და ყველაფერი მუშაობს ჩვენთვის.

მაგრამ ეს საკმარისი არ არის, ჩვენ მაინც უნდა მივცეთ მონაცემები მომხმარებელს. უმარტივესი იდეაა ყველაფრის სერიული გადაცემა JSON-ში, მარტივად, ორ სტრიქონში. ჩვენ ვაძლევთ Content-Type-ს, ვაძლევთ JSON-ს.

მაგრამ არის ერთი სირთულე: მომხმარებელს არ სურს JSON-ის წაკითხვა. ჩვენ უნდა მოვიზიდოთ ფრონტ-ენდის დეველოპერები. ზოგჯერ ჩვენ არ გვინდა ამის გაკეთება თავიდან. და SEO სპეციალისტები იტყვიან, რომ თუ ჩვენ ვეძებთ სურათებს, მაშინ მათთვის არ აქვს მნიშვნელობა. და თუ მათ გარკვეულ შინაარსს მივცემთ, ისინი იტყვიან, რომ ჩვენი საძიებო სისტემები არაფერს არ ინდექსირებენ.

რა უნდა გააკეთოს ამაზე? რა თქმა უნდა, მომხმარებელს მივცემთ HTML-ს. ხელით გენერირება არ არის comme il faut, ამიტომ გვინდა გამოვიყენოთ შაბლონები. ამისათვის არის ბიბლიოთეკა lua-resty-template.

თქვენ ალბათ გინახავთ სამი საშინელი ასო OPM. OpenResty-ს გააჩნია საკუთარი პაკეტის მენეჯერი, რომლის მეშვეობითაც შეგიძლიათ დააინსტალიროთ სხვადასხვა მოდული, კერძოდ, lua-resty-template. ეს არის მარტივი შაბლონის ძრავა, Django შაბლონების მსგავსი. იქ შეგიძლიათ დაწეროთ კოდი და შეასრულოთ ცვლადის ჩანაცვლება.

შედეგად, ყველაფერი ასე გამოიყურება:

ჩვენ ავიღეთ მონაცემები და გამოვიტანეთ შაბლონი, ისევ ორ სტრიქონში. მომხმარებელი ბედნიერია, მან მიიღო კატები. მას შემდეგ, რაც მოთხოვნა გავაფართოვეთ, მან ასევე მიიღო ბეწვის ბეჭედი კნუტებისთვის. არასოდეს იცი, იქნებ ზუსტად ამას ეძებდა, მაგრამ თხოვნა სწორად ვერ ჩამოაყალიბა.

ყველაფერი მაგარია, მაგრამ ჩვენ დამუშავების პროცესში ვართ და ჯერ არ გვინდა ვაჩვენოთ მომხმარებლებს. მოდით გავაკეთოთ ავტორიზაცია. ამისათვის მოდით შევხედოთ, თუ როგორ ამუშავებს NGINX მოთხოვნას OpenResty პირობებით:

• პირველი ეტაპი არის შედიხართ, როდესაც მომხმარებელი ახლახან მოვიდა და ჩვენ მას შევხედეთ სათაურებით, IP მისამართით და სხვა მონაცემებით. ჩვენ შეგვიძლია მაშინვე გავწყვიტოთ, თუ არ მოგვწონს. ეს შეიძლება გამოვიყენოთ ავტორიზაციისთვის, ან თუ ბევრ მოთხოვნას მივიღებთ, ამ ფაზაში მარტივად შეგვიძლია მათი გაწყვეტა.
• ხელმეორე. ჩვენ გადავწერთ მოთხოვნის ზოგიერთ მონაცემს.
• შინაარსი. ჩვენ კონტენტს ვაწვდით მომხმარებელს.
• სათაურების ფილტრი. ჩვენ ვცვლით პასუხების სათაურებს. თუ გამოვიყენეთ proxy_pass, ჩვენ შეგვიძლია გადავიწეროთ რამდენიმე სათაური მომხმარებლისთვის მიცემამდე.
• სხეულის ფილტრი. ჩვენ შეგვიძლია შევცვალოთ სხეული.
• შესვლა - ხე-ტყე. თქვენ შეგიძლიათ დაწეროთ ჟურნალები elasticsearch-ში დამატებითი ფენის გარეშე.

ჩვენი ავტორიზაცია ასე გამოიყურება:

ჩვენ ამას დავამატებთ location, რომელიც ადრე აღვწერეთ და იქ დავაყენეთ შემდეგი კოდი:

ჩვენ ვუყურებთ, გვაქვს თუ არა ქუქი-ტოკენი. თუ არა, მაშინ ვითხოვთ ავტორიზაციას. მომხმარებლები ცბიერები არიან და შეუძლიათ გამოიცნონ, რომ მათ უნდა დააყენონ ქუქი-ტოკენი. ამიტომ, ჩვენ ასევე ჩავდებთ მას Redis-ში:

Redis-თან მუშაობის კოდი ძალიან მარტივია და არაფრით განსხვავდება სხვა ენებისგან. ამავდროულად, ყველა შეყვანა/გამომავალი, აქ და იქ, არ იბლოკება. თუ თქვენ წერთ სინქრონულ კოდს, ის მუშაობს ასინქრონულად. თითქმის როგორც გევენტი, მაგრამ კარგად გაკეთებული.

მოდით გავაკეთოთ ავტორიზაცია თავად:

ჩვენ ვამბობთ, რომ უნდა წავიკითხოთ მოთხოვნის ნაწილი. ჩვენ ვიღებთ POST არგუმენტებს და ვამოწმებთ, რომ შესვლა და პაროლი სწორია. თუ ისინი არასწორია, მაშინ ჩვენ გიწვევთ ავტორიზაციისთვის. და თუ სწორია, მაშინ ჩაწერეთ ჟეტონი Redis-ში:

არ დაგავიწყდეთ ქუქი-ფაილის დაყენება, ეს ასევე კეთდება ორ სტრიქონში:

მაგალითი მარტივი და სპეკულაციურია. რა თქმა უნდა, ჩვენ არ გავაკეთებთ სერვისს, რომელიც ხალხს კატებს აჩვენებს. მაგრამ ვინ გვიცნობს. მოდით გადავიდეთ იმაზე, თუ რა შეიძლება გაკეთდეს წარმოებაში.

• მინიმალისტური უკანა ნაწილი. ზოგჯერ ჩვენ გვჭირდება მხოლოდ მცირე რაოდენობის მონაცემების გამოტანა ბექენდში: სადღაც უნდა ჩავსვათ თარიღი, სადღაც უნდა გამოვაჩინოთ სია, ვთქვათ რამდენი მომხმარებელია საიტზე ახლა, დაურთოთ მრიცხველი ან სტატისტიკა. რაღაც ისეთი პატარა. ზოგიერთი მინიმალური ნაწილის დამზადება ძალიან მარტივად შეიძლება. ეს გახდის მას სწრაფ, მარტივ და შესანიშნავად.
• მონაცემთა წინასწარი დამუშავება. ზოგჯერ გვსურს რეკლამის ჩასმა ჩვენს გვერდზე და ამ რეკლამას ვიღებთ API მოთხოვნების გამოყენებით. ამის გაკეთება აქ ძალიან ადვილია. ჩვენ არ ვტვირთავთ ჩვენს ბექენდს, რომელიც უკვე ზის და მუშაობს. შეგიძლიათ აიღოთ და შეაგროვოთ აქ. ჩვენ შეგვიძლია გავაერთიანოთ ზოგიერთი JS ან, პირიქით, გავხსნათ იგი და წინასწარ დავამუშაოთ რაღაც, სანამ მომხმარებელს მივცემთ.
• ფასადი მიკროსერვისისთვის. ესეც ძალიან კარგი შემთხვევაა, განვახორციელე. მანამდე ვმუშაობდი ტენზორში, კომპანიაში, რომელიც ეწევა ელექტრონულ ანგარიშგებას და აწვდის ანგარიშგებას ქვეყნის იურიდიული პირების დაახლოებით ნახევარს. ჩვენ შევქმენით სერვისი, იქ ბევრი რამ გაკეთდა იგივე მექანიზმით: მარშრუტიზაცია, ავტორიზაცია და სხვა.
  OpenResty შეიძლება გამოყენებულ იქნას როგორც წებო თქვენი მიკროსერვისებისთვის, რაც უზრუნველყოფს ყველაფერზე ერთიან წვდომას და ერთ ინტერფეისს. ვინაიდან მიკროსერვისები შეიძლება დაიწეროს ისე, რომ თქვენ გქონდეთ Node.js აქ, PHP აქ, პითონი აქ, რაღაც Erlang აქ, ჩვენ გვესმის, რომ არ გვინდა ყველგან ერთი და იგივე კოდის გადაწერა. ამიტომ, OpenResty შეიძლება ჩაერთოს წინა მხარეს.

• სტატისტიკა და ანალიტიკა. ჩვეულებრივ, NGINX არის შესასვლელთან და ყველა მოთხოვნა გადის მასში. სწორედ ამ ადგილას არის ძალიან მოსახერხებელი შეგროვება. შეგიძლიათ სასწრაფოდ გამოთვალოთ რაღაც და ატვირთოთ სადმე, მაგალითად, Elasticsearch, Logstash, ან უბრალოდ ჩაწეროთ ჟურნალში და შემდეგ გაგზავნოთ სადმე.
• მრავალ მომხმარებლის სისტემები. მაგალითად, ონლაინ თამაშებიც ძალიან კარგი გასაკეთებელია. დღეს კეიპტაუნში, ალექსანდრე გლადიში ისაუბრებს იმაზე, თუ როგორ სწრაფად მოაწყოთ მრავალმოთამაშიანი თამაში OpenResty-ის გამოყენებით.
• ფილტრაციის მოთხოვნა (WAF). დღესდღეობით მოდურია ყველა სახის ვებ აპლიკაციის ფეიერვოლების დამზადება; მათ აქვთ მრავალი სერვისი. OpenResty-ის გამოყენებით თქვენ შეგიძლიათ შექმნათ ვებ აპლიკაციის ბუხარი, რომელიც მარტივად და მარტივად გაფილტრავს მოთხოვნებს თქვენი მოთხოვნების შესაბამისად. თუ თქვენ გაქვთ Python, მაშინ გესმით, რომ PHP ნამდვილად არ იქნება თქვენში ინექცია, თუ, რა თქმა უნდა, არ დაასხით მას სადმე კონსოლიდან. თქვენ იცით, რომ გაქვთ MySQL და Python. ალბათ, ისინი შეიძლება შეეცადონ განახორციელონ რაიმე სახის დირექტორიაში გადაადგილება და რაიმეს შეყვანა მონაცემთა ბაზაში. აქედან გამომდინარე, შეგიძლიათ სწრაფად და იაფად გაფილტროთ უცნაური მოთხოვნები პირდაპირ წინა მხარეს.
• საზოგადოება ვინაიდან OpenResty აგებულია NGINX-ზე, მას აქვს ბონუსი: NGINX საზოგადოება. ის ძალიან დიდია და კითხვების სოლიდური ნაწილი, რომელიც თავიდან გექნებათ, უკვე გადაჭრილია NGINX საზოგადოების მიერ.

  ლუას დეველოპერები. გუშინ HighLoad++ ტრენინგზე მისულ ბიჭებს ველაპარაკე და გავიგე, რომ ლუაში მხოლოდ Tarantool ეწერა. ეს ასე არ არის, ლუაში ბევრი რამ წერია. მაგალითები: OpenResty, Prosody XMPP სერვერი, Love2D თამაშის ძრავა, Lua დაწერილი Warcraft-ში და სხვაგან. ლუას დეველოპერები ბევრია, მათ აქვთ დიდი და საპასუხო საზოგადოება. ჩემი ლუას ყველა კითხვა რამდენიმე საათში მოგვარდა. როდესაც თქვენ წერთ დაგზავნის სიას, ფაქტიურად რამდენიმე წუთში უკვე არის უამრავი პასუხი, სადაც აღწერილია რა და როგორ, რა არის რა. Შესანიშნავია. სამწუხაროდ, ასეთი კეთილი, სულიერი საზოგადოება ყველგან არ არის.
  არის GitHub OpenResty-სთვის, სადაც შეგიძლიათ გახსნათ საკითხი, თუ რამე გატეხილია. Google Groups-ში არის საფოსტო სია, სადაც შეგიძლიათ განიხილოთ ზოგადი საკითხები, არის საფოსტო სია ჩინურ ენაზე - თქვენ არასოდეს იცით, შესაძლოა ინგლისურად არ ლაპარაკობდეთ, მაგრამ იცით ჩინური.

შედეგები

• ვიმედოვნებ, რომ შევძელი გადმოგცეთ, რომ OpenResty არის ძალიან მოსახერხებელი ჩარჩო, რომელიც მორგებულია ვებზე.
• მას აქვს დაბალი ბარიერი შესვლისთვის, რადგან კოდი მსგავსია რასაც ჩვენ ვწერთ, ენა საკმაოდ მარტივი და მინიმალისტურია.
• ის უზრუნველყოფს ასინქრონულ I/O-ს გამოძახების გარეშე, ჩვენ არ გვექნება რაიმე noodles, როგორიც შეიძლება ზოგჯერ NodeJS-ში ჩავწეროთ.
• მას აქვს მარტივი განლაგება, რადგან ჩვენ გვჭირდება მხოლოდ NGINX საჭირო მოდულით და ჩვენი კოდით და ყველაფერი მუშაობს დაუყოვნებლივ.
• დიდი და საპასუხო საზოგადოება.

დეტალურად არ მითქვამს, როგორ კეთდება მარშრუტიზაცია, ძალიან გრძელი ამბავი აღმოჩნდა.

დიდი მადლობა!

ვლადიმერ პროტასოვი - OpenResty: NGINX-ის სრულფასოვან აპლიკაციის სერვერად გადაქცევა

წყარო: www.habr.com