Կրկին հրապարակում ենք համաժողովի զեկույցի սղագրությունը Բարձր բեռնում ++ Անցյալ տարվա նոյեմբերի 2016-7-ը մերձմոսկովյան Սկոլկովոյում տեղի ունեցած 8թ. Վլադիմիր Պրոտասով բացատրում է, թե ինչպես կարելի է ընդլայնել NGINX ֆունկցիոնալությունը OpenResty-ի և Lua-ի հետ:

Բարև բոլորին, ես Վլադիմիր Պրոտասովն եմ, աշխատում եմ Parallels-ում: Ես ձեզ մի փոքր կպատմեմ իմ մասին: Ես ծախսում եմ իմ կյանքի երեք քառորդը ծածկագիր գրելով: Ես դարձա ծրագրավորող մինչև հիմքը բառացի իմաստով. երբեմն երազումս կոդ եմ տեսնում: Կյանքի մեկ քառորդը արդյունաբերական զարգացումն է, կոդ գրելը, որն անմիջապես գնում է արտադրություն: Կոդ, որը ձեզանից ոմանք օգտագործում են, բայց դա չեն գիտակցում:

Այսպիսով, դուք հասկանում եք, թե որքան վատ էր դա: Երբ ես մի փոքր փոքր էի, ես եկա և ինձ տվեցին այս երկու տերաբայթանոց տվյալների բազաները: Այժմ այստեղ բոլորի համար մեծ ծանրաբեռնվածություն է: Ես գնացի կոնֆերանսների և հարցրի. «Տղե՛րք, ասեք ինձ, դուք մեծ տվյալներ ունեք, ամեն ինչ լավ է: Քանի՞ բազա ունեք այնտեղ: Նրանք ինձ պատասխանեցին. «Մենք ունենք 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: Դուք բոլորդ գիտեք, որ նա արագ և հիանալի է: Նրանք դրա մեջ սինխրոն I/O են ստեղծել, այնպես որ մենք կարիք չունենք որևէ բան շրջելու, ճիշտ այնպես, ինչպես նրանք արել են Python-ում: Gevent-ը հիանալի է, հիանալի, բայց եթե գրեք C կոդ և ինչ-որ բան սխալ է, ապա Gevent-ի հետ դուք կխելագարվեք այն կարգաբերելիս: Ես փորձ ունեի. երկու ամբողջ օր պահանջվեց՝ հասկանալու համար, թե ինչն է սխալ եղել այնտեղ: Եթե ​​ինչ-որ մեկը մի քանի շաբաթ չփորեր, չգտներ խնդիրը, չգրեր ինտերնետում, իսկ Google-ը չգտներ այն, ապա մենք լրիվ կխելագարվեինք։

NGINX-ն արդեն ունի քեշավորում և ստատիկ բովանդակություն: Պետք չէ անհանգստանալ, թե ինչպես դա անել մարդկայնորեն, որպեսզի ինչ-որ տեղ չդանդաղեցնեք, որպեսզի ինչ-որ տեղ նկարագրողներ չկորցնեք: Nginx-ը շատ հարմար է տեղակայման համար, դուք կարիք չունեք մտածելու, թե ինչ վերցնել՝ WSGI, PHP-FPM, Gunicorn, Unicorn: Nginx-ը տեղադրվեց, տրվեց ադմիններին, նրանք գիտեն ինչպես աշխատել դրա հետ։ Nginx-ը մշակում է հարցումները կառուցվածքային ձևով: Այս մասին կխոսեմ մի փոքր ուշ: Մի խոսքով, այն ունի մի փուլ, երբ նա պարզապես ընդունել է հարցումը, երբ այն մշակել է այն և երբ բովանդակությունը մատուցել է օգտագործողին:

Nginx-ը հիանալի է, բայց կա մեկ խնդիր. այն բավականաչափ ճկուն չէ, նույնիսկ այն բոլոր հիանալի հատկանիշներով, որոնք տղաները խցկել են կոնֆիգուրացիայի մեջ, չնայած այն, ինչ կարելի է կարգավորել: Այս ուժը բավարար չէ։ Ահա թե ինչու Տաոբաոյի տղաները վաղուց, թվում է, թե ութ տարի առաջ, Լուային ներկառուցեցին դրա մեջ: Ի՞նչ է դա տալիս:

• չափ. Այն փոքր է։ LuaJIT-ը տալիս է մոտ 100-200 կիլոբայթ հիշողության գերբեռնվածություն և նվազագույն կատարողականի ծախս:
• Բարեմաղթել. LuaJIT թարգմանիչը շատ իրավիճակներում մոտ է C-ին, որոշ իրավիճակներում այն ​​պարտվում է Java-ին, որոշ դեպքերում գերազանցում է նրան: Որոշ ժամանակ այն համարվում էր արվեստի վիճակ, ամենաթեժ JIT կոմպիլյատորը: Հիմա ավելի սառն են, բայց շատ ծանր են, օրինակ նույն V8-ը։ Որոշ JS թարգմանիչներ և Java HotSpot-ն ավելի արագ են որոշ կետերում, բայց որոշ տեղերում նրանք դեռ կորցնում են:
• Հեշտ է սովորել. Եթե ​​դուք ունեք, ասենք, Perl կոդերի բազա, և չեք Booking, ապա չեք գտնի Perl ծրագրավորողներ։ Քանի որ դրանք չկան, բոլորը տարվել են, և նրանց սովորեցնելը երկար ու դժվար է: Եթե ​​դուք ցանկանում եք ծրագրավորողներ այլ բանի համար, դուք նույնպես կարող եք նրանց վերապատրաստել կամ գտնել: Լուայի դեպքում ամեն ինչ պարզ է. Ցանկացած կրտսեր կարող է սովորել Լուա երեք օրում: Ինձանից մոտ երկու ժամ պահանջվեց դա հասկանալու համար: Երկու ժամ անց ես արդեն կոդ էի գրում արտադրության մեջ։ Մոտ մեկ շաբաթ անց նա անմիջապես գնաց արտադրություն և հեռացավ:

Արդյունքում, այն ունի հետևյալ տեսքը.

Այստեղ շատ բան կա: OpenResty-ն հավաքել է մի շարք մոդուլներ՝ և՛ luash, և՛ շարժիչային: Եվ դուք ամեն ինչ պատրաստ եք՝ տեղակայված և աշխատող:

օրինակները

Բավական է բառերը, անցնենք ծածկագրին։ Ահա մի փոքրիկ Բարև աշխարհ.

Ի՞նչ կա այնտեղ: Սա Էնգինի տեղանքն է: Մենք չենք անհանգստանում, մենք չենք գրում մեր սեփական երթուղին, մենք պատրաստ չենք վերցնում, մենք այն արդեն ունենք NGINX-ում, մենք ապրում ենք լավ և ծույլ կյանքով:

content_by_lua_block բլոկ է, որն ասում է, որ մենք մատուցում ենք բովանդակություն՝ օգտագործելով Lua script: Մենք վերցնում ենք Engins փոփոխականը remote_addr և դրիր այն string.format. Դա նույնն է, ինչ sprintf, միայն Լուա, միայն ճիշտ։ Եվ մենք տալիս ենք հաճախորդին:

Արդյունքում, այն կունենա հետևյալ տեսքը.

Բայց վերադառնանք իրական աշխարհ։ Ոչ ոք չի տեղակայում 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: Մենք պետք է ներգրավենք ֆրոնտ-end ծրագրավորողներին: Երբեմն մենք սկզբում չենք ուզում դա անել: Իսկ SEO-ի մասնագետները կասեն, որ եթե մենք նկարներ ենք փնտրում, ապա դա նրանց համար նշանակություն չունի։ Եվ եթե մենք նրանց որոշակի բովանդակություն տանք, նրանք կասեն, որ մեր որոնման համակարգերը ոչինչ չեն ինդեքսավորում:

Ի՞նչ անել դրա հետ կապված: Իհարկե, մենք օգտվողին կտանք HTML: Ձեռքով ստեղծելը comme il faut չէ, ուստի մենք ցանկանում ենք օգտագործել կաղապարներ: Դրա համար կա գրադարան lua-resty-template.

Դուք հավանաբար տեսել եք երեք սարսափելի OPM տառերը: OpenResty-ն ունի իր փաթեթների կառավարիչը, որի միջոցով կարող եք տեղադրել մի շարք տարբեր մոդուլներ, մասնավորապես. lua-resty-template. Սա պարզ կաղապարային շարժիչ է, որը նման է Django կաղապարներին: Այնտեղ կարող եք գրել կոդը և կատարել փոփոխականի փոխարինում։

Արդյունքում ամեն ինչ կունենա հետևյալ տեսքը.

Մենք վերցրեցինք տվյալները և դարձրեցինք կաղապարը, կրկին երկու տողով: Օգտատերը գոհ է, կատուներ է ստացել։ Քանի որ մենք ընդլայնեցինք խնդրանքը, նա նաև կատվի ձագերի համար մորթյա կնիք ստացավ։ Երբեք չգիտես, միգուցե նա հենց սա էր փնտրում, բայց չկարողացավ ճիշտ ձևակերպել իր խնդրանքը։

Ամեն ինչ լավ է, բայց մենք մշակման փուլում ենք և դեռ չենք ցանկանում դա ցույց տալ օգտատերերին: Եկեք թույլտվությունը կատարենք։ Դա անելու համար եկեք տեսնենք, թե ինչպես է NGINX-ը մշակում հարցումը OpenResty-ի պայմաններով.

• Առաջին փուլ - մուտք, երբ օգտատերը հենց նոր եկավ, և մենք նրան նայեցինք վերնագրերով, IP հասցեով և այլ տվյալներով։ Մենք կարող ենք անմիջապես կտրել այն, եթե դա մեզ դուր չի գալիս: Սա կարող է օգտագործվել թույլտվության համար, կամ եթե մենք ստանում ենք բազմաթիվ հարցումներ, մենք կարող ենք հեշտությամբ կտրել դրանք այս փուլում:
• վերագրանցել. Մենք վերագրում ենք որոշ հարցումների տվյալներ:
• պարունակություն. Մենք տրամադրում ենք բովանդակությունը օգտվողին:
• վերնագրերի զտիչ. Մենք փոխարինում ենք պատասխանների վերնագրերը: Եթե ​​օգտագործեինք proxy_pass, մենք կարող ենք վերաշարադրել որոշ վերնագրեր՝ նախքան այն օգտատիրոջը տալը։
• մարմնի ֆիլտր. Մենք կարող ենք փոխել մարմինը:
• մուտք - անտառահատումներ. Դուք կարող եք գրել տեղեկամատյաններ elasticsearch-ում առանց լրացուցիչ շերտի:

Մեր թույլտվությունը կունենա հետևյալ տեսքը.

Մենք սա կավելացնենք այդ մեկին location, որը մենք նախկինում նկարագրել ենք, և այնտեղ տեղադրել հետևյալ կոդը.

Մենք նայում ենք՝ տեսնելու, թե արդյոք ունենք թխուկի նշան: Եթե ​​ոչ, ապա մենք թույլտվություն ենք խնդրում: Օգտատերերը խորամանկ են և կարող են կռահել, որ պետք է թխուկի նշան դնել: Հետևաբար, մենք այն կդնենք նաև Redis-ում.

Redis-ի հետ աշխատելու կոդը շատ պարզ է և չի տարբերվում այլ լեզուներից։ Միևնույն ժամանակ, բոլոր մուտքերը/ելքերը, այստեղ և այնտեղ, չեն արգելափակվում: Եթե ​​դուք գրում եք սինխրոն կոդ, այն աշխատում է ասինխրոն: Գրեթե նման է gevent-ին, բայց լավ է արված:

Եկեք կատարենք ինքնին թույլտվությունը.

Մենք ասում ենք, որ պետք է կարդալ խնդրանքի հիմնական մասը։ Մենք ստանում ենք POST արգումենտներ և ստուգում ենք, որ մուտքի և գաղտնաբառը ճիշտ են: Եթե ​​դրանք սխալ են, ապա մենք բողոքարկում ենք ձեզ թույլտվություն ստանալու համար: Իսկ եթե ճիշտ է, ապա Redis-ում գրեք նշանը.

Մի մոռացեք տեղադրել թխուկը, սա նույնպես արվում է երկու տողով.

Օրինակը պարզ է և ենթադրական։ Իհարկե, մենք չենք սարքի ծառայություն, որը մարդկանց կատուներ ցույց կտա։ Բայց մեզ ո՞վ է ճանաչում։ Այսպիսով, եկեք անդրադառնանք, թե ինչ կարելի է անել արտադրության մեջ:

• Մինիմալիստական ​​հետնամաս. Երբեմն մենք պետք է ընդամենը մի քիչ տվյալներ արտածենք հետնամասում. ինչ-որ տեղ մենք պետք է տեղադրենք ամսաթիվ, ինչ-որ տեղ մենք պետք է ցուցադրենք ցուցակը, ասենք, թե քանի օգտվող կա կայքում այժմ, կցել հաշվիչ կամ վիճակագրություն: Ինչ-որ փոքր բան: Որոշ նվազագույն կտորներ կարելի է շատ հեշտությամբ պատրաստել: Սա կդարձնի այն արագ, հեշտ և հիանալի:
• Տվյալների նախնական մշակում. Երբեմն մենք ցանկանում ենք գովազդ տեղադրել մեր էջում, և մենք ստանում ենք այս գովազդը՝ օգտագործելով API հարցումները: Սա շատ հեշտ է անել այստեղ: Մենք չենք բեռնում մեր բեքենդը, որն արդեն նստած աշխատում է։ Դուք կարող եք այն վերցնել և հավաքել այստեղ: Մենք կարող ենք միացնել որոշ JS կամ, ընդհակառակը, անջատել այն և նախապես մշակել ինչ-որ բան՝ նախքան այն օգտատիրոջը տալը:
• Ճակատ՝ միկրոսերվիսի համար. Սա նույնպես շատ լավ դեպք է, իրականացրել եմ։ Մինչ այդ ես աշխատել եմ Tenzor ընկերությունում, որը զբաղվում է էլեկտրոնային հաշվետվություններով և հաշվետվություններ է տրամադրում երկրի իրավաբանական անձանց մոտավորապես կեսին: Մենք ստեղծեցինք ծառայություն, այնտեղ շատ բաներ արվեցին՝ օգտագործելով նույն մեխանիզմը՝ երթուղավորում, լիազորում և այլն։
  OpenResty-ը կարող է օգտագործվել որպես ձեր միկրոծառայությունների սոսինձ՝ ապահովելով ամեն ինչի մեկ մուտք և մեկ ինտերֆեյս: Քանի որ միկրոսերվիսները կարող են գրվել այնպես, որ դուք ունեք Node.js այստեղ, PHP այստեղ, Python այստեղ, որոշ Erlang բան այստեղ, մենք հասկանում ենք, որ մենք չենք ցանկանում ամենուր նույն կոդը վերաշարադրել: Հետևաբար, OpenResty-ն կարելի է միացնել առջևի մասում:

• Վիճակագրություն և վերլուծություն. Սովորաբար NGINX-ը մուտքի մոտ է, և բոլոր հարցումներն անցնում են դրա միջով: Հենց այս վայրում է շատ հարմար հավաքել։ Դուք կարող եք անմիջապես հաշվարկել ինչ-որ բան և վերբեռնել այն ինչ-որ տեղ, օրինակ՝ Elasticsearch, Logstash, կամ պարզապես գրել այն գրանցամատյանում և այնուհետև ուղարկել ինչ-որ տեղ:
• Բազմ օգտագործող համակարգեր. Օրինակ, օնլայն խաղերը նույնպես շատ լավ են պատրաստվում: Այսօր Քեյփթաունում Ալեքսանդր Գլադիշը կխոսի այն մասին, թե ինչպես արագ ձևավորել բազմախաղացող խաղ OpenResty-ի միջոցով:
• Զտման հարցում (WAF). Մեր օրերում նորաձև է բոլոր տեսակի վեբ հավելվածների firewalls պատրաստելը, կան բազմաթիվ ծառայություններ, որոնք տրամադրում են դրանք: Օգտագործելով OpenResty-ը, դուք կարող եք ինքներդ ձեզ ստեղծել վեբ հավելվածի firewall, որը պարզապես և հեշտությամբ կզտի հարցումները ձեր պահանջներին համապատասխան: Եթե ​​ունես Python, ուրեմն հասկանում ես, որ PHP հաստատ չի ներարկվի քո մեջ, եթե, իհարկե, չասես այն կոնսոլից որևէ տեղ։ Դուք գիտեք, որ ունեք MySQL և Python: Հավանաբար, նրանք կարող են փորձել անել ինչ-որ գրացուցակի անցում և ինչ-որ բան ներարկել տվյալների բազայում: Հետևաբար, դուք կարող եք արագ և էժանորեն զտել տարօրինակ հարցումները հենց առջևում:
• Համայնք. Քանի որ OpenResty-ը կառուցված է NGINX-ի վրա, այն ունի բոնուս՝ սա NGINX համայնք. Այն շատ մեծ է, և այն հարցերի պատշաճ մասը, որոնք դուք կունենաք սկզբում, արդեն լուծվել են NGINX համայնքի կողմից:

  Lua մշակողները. Երեկ խոսեցի HighLoad++ թրեյնինգի օրը եկած տղաների հետ ու լսեցի, որ Լուաում միայն Tarantool է գրված։ Սա ճիշտ չէ, Լուաում շատ բան է գրված։ Օրինակներ՝ OpenResty, Prosody XMPP սերվեր, Love2D խաղային շարժիչ, Lua՝ գրված Warcraft-ում և այլուր: Կան շատ Lua ծրագրավորողներ, նրանք ունեն մեծ և արձագանքող համայնք: Լուայի բոլոր հարցերը լուծվեցին մի քանի ժամվա ընթացքում։ Երբ դուք գրում եք փոստային ցուցակում, բառացիորեն մի քանի րոպեի ընթացքում արդեն կան մի շարք պատասխաններ, որոնք նկարագրում են, թե ինչ և ինչպես, ինչ է: Հրաշալի է. Ցավոք սրտի, նման բարի, հոգեւոր համայնք ամենուր չէ։
  OpenResty-ի համար կա GitHub, որտեղ կարող եք խնդիր բացել, եթե ինչ-որ բան կոտրված է: Google Groups-ում կա փոստային ցուցակ, որտեղ կարող եք քննարկել ընդհանուր հարցեր, կա նամակացուց չինարեն լեզվով. երբեք չգիտեք, գուցե անգլերեն չեք խոսում, բայց չգիտեք չինարեն:

Արդյունքները

• Հուսով եմ, որ կարողացա փոխանցել, որ OpenResty-ը շատ հարմար շրջանակ է, որը հարմարեցված է համացանցի համար:
• Այն ունի մուտքի ցածր խոչընդոտ, քանի որ կոդը նման է նրան, ինչ մենք գրում ենք, լեզուն բավականին պարզ է և մինիմալիստական:
• Այն ապահովում է ասինխրոն I/O առանց հետադարձ զանգերի, մենք չենք ունենա լապշա, ինչպես երբեմն կարող ենք գրել NodeJS-ում:
• Այն ունի հեշտ տեղակայում, քանի որ մեզ անհրաժեշտ է միայն NGINX՝ անհրաժեշտ մոդուլով և մեր կոդով, և ամեն ինչ անմիջապես աշխատում է:
• Մեծ և արձագանքող համայնք:

Ես մանրամասն չպատմեցի, թե ինչպես է երթուղավորումն արվում, շատ երկար պատմություն ստացվեց։

Շնորհակալություն ձեր ուշադրության համար:

Վլադիմիր Պրոտասով - OpenResty. NGINX-ը վերածելով լիարժեք հավելվածների սերվերի

Source: www.habr.com