Ի՞նչ է սերվերը. պարզ ուղեցույց հավելվածներ կառուցողների համար

Սերվերը համակարգիչ է՝ կամ դրա վրա աշխատող ծրագիր, որը սպասում է հարցումների և պատասխանում է դրանց։ Երբ բացում եք կայք, ձեր բրաուզերը (client) հարցում է ուղարկում ինտերնետով, և ինչ-որ տեղ գտնվող սերվերը ուղարկում է հետ էջը, նկարները կամ տվյալները։ Յուրաքանչյուր հավելված, որ օգտագործում եք, էլ․ փոստից մինչև internet banking, կախված է սերվերներից, որ դա անում են օրական միլիոնավոր անգամ։

Ինչու են սերվերները կարևոր AI-ով կառուցելիս

Երբ AI կառուցիչը ձեզ հավելված է պատրաստում, կոդի մի մասը աշխատում է այցելուի բրաուզերում, իսկ մյուս մասը սովորաբար աշխատում է սերվերում։ Սերվերի մասն անում է այն, ինչ բրաուզերին չի կարելի վստահել կամ ինքնուրույն չի կարող անել․

• Տվյալների պահպանում և բեռնում տվյալների բազայից։
• Գաղտնիքների պահպանում, օրինակ՝ վճարման կամ AI մատակարարի API բանալիներ, որոնք երբեք չպետք է հասնեն բրաուզեր։
• Թույլտվությունների ստուգում․ համոզվել, որ օգտատերը կարող է տեսնել և փոխել միայն իր սեփական գրառումները։
• Այլ ծառայությունների հետ խոսելը․ քարտից գումար գանձել, էլ․ նամակ ուղարկել, AI մոդել կանչել։

Սերվերի գործը իմանալը օգնում է հասկանալ, թե որտեղ են իրականում ապրում ձեր հավելվածի կանոնները, ինչու որոշ փոփոխություններ վերահրապարակում են պահանջում, և ինչի համար եք վճարում հավելված հոսթելիս։ Երկու կեսերի բաժանման համար տե՛ս frontend-ը և backend-ը։

Ամենօրյա անալոգիա

Սերվերը նման է փոստային բաժանմունքի գիշերային աշխատակցին։ Նա ոչ ոքի չի փնտրում, այլ սպասում է։ Հաճախորդը (client) մոտենում է հարցումով՝ «ուղարկեք այս ծանրոցը», «ունե՞ք իմ նամակները», և պաշտոնյան մշակում է այն և հետ է տալիս արդյունքը։ Մեկ պաշտոնյան կարող է սպասարկել շատ հաճախորդների մեկը մյուսից հետո, և զբաղված փոստատանը բացում է ավելի շատ դարակներ։

Փոստատանը նաև կանոններ ունի, որոնք հաճախորդը չի կարող անտեսել․ ծանրոց ստանալու համար պետք է ցուցադրեք նույնականացման փաստաթուղթ։ Դա էլ է սերվերի գործը հավելվածում․ բրաուզերը կարող է խնդրել ամեն ինչ, բայց սերվերն է որոշում, թե ինչ է ստանում։

Ինչպես է հարցումը հասնում սերվերին

Երբ ինչ-որ մեկը այցելում է https://bookings.example.com/schedule․

1. DNS որոնում։ Բրաուզերը դոմեյնների անվանման համակարգից հարցնում է, թե որ IP հասցեին է ցույց տալիս bookings.example.com-ը։ Տե՛ս ինչպես են աշխատում դոմեյններն ու DNS-ը։
2. Միացում։ Բրաուզերը միանում է այդ հասցեին՝ HTTPS-ի 443 պորտով և հաստատում գաղտնագրված կապ։ Տե՛ս ինչ է HTTPS-ը։
3. Հարցում։ Ուղարկում է HTTP հարցում՝ GET /schedule։
4. Աշխատանք։ Սերվերը գործարկում է այն կոդը, որ մշակում է /schedule-ը, օրինակ՝ տվյալների բազայից փնտրում է այսօրվա ամրագրումները։
5. Պատասխան։ Ուղարկում է կարգավիճակի կոդ (200 OK) և բովանդակությունը՝ HTML էջ կամ JSON տվյալներ, որ էջը ցուցադրի։

Այս ամենը սովորաբար տևում է վայրկյանի մասնիկ։

Սերվերների տեսակներ, որ կլսեք

Նկատեք, որ «սերվեր» բառը նշանակում է և՛ մեքենա, և՛ ծրագիր։ «Սերվերը կործանվեց» կարող է նշանակել երկուսից էլ մեկը։

Աշխատած օրինակ՝ սրահի ամրագրման հավելված

Նայեք, թե ինչ է անում սերվերը փոքր սրահի ամրագրման հավելվածում․

• Այցելուն բացում է կայքը։ Սերվերը (կամ դրա առջև գտնվող CDN) ուղարկում է էջի ֆայլերը։
• Էջը սերվերից հարցնում է GET /api/slots?date=2026-10-03։ Սերվերը տվյալների բազայից փնտրում է ազատ ժամերը և վերադարձնում դրանք JSON-ով։
• Այցելուն ամրագրում է 14:00-ը։ Էջը ուղարկում է POST /api/bookings։ Սերվերը ստուգում է, որ ժամը դեռ ազատ է, չի վստահում բրաուզերի խոսքին, պահում է ամրագրումը և վերադարձնում 201 Created։
• Սերվերը էլ․ փոստի ծառայությանը կանչում է գաղտնի բանալիով, որ պահվում է սերվերում, հաստատման նամակ ուղարկելու համար։

Եթե անջատեիք սերվերը, էջը գուցե դեռ բեռնվեր CDN-ից, բայց չէր կարողանա ցույց տալ ազատ ժամեր կամ պահել ամրագրումներ։

Ինչ է պետք սերվերին լավ աշխատելու համար

• Հիշողություն (RAM) և CPU։ Քիչ հիշողությունը հավելվածը կործանում է ծանրաբեռնվածության տակ, քիչ CPU-ն դանդաղեցնում է այն։
• Աշխատելը։ Անջատված սերվերը չի կարող պատասխանել։ Ոմանք հարթակներ անգործ հավելվածները քնեցնում են և արթնացնում հաջորդ այցի ժամանակ, ինչը խնայում է գումար, բայց կարող է առաջին հարցումն ավելի դանդաղ դարձնել։
• Կարգավորումներ և գաղտնիքներ, տրամադրված միջավայրի փոփոխականների միջոցով։
• Մատյաններ (logs)՝ սերվերի գրանցումը այն ամենի, ինչ տեղի ունեցավ։ Սա այն տեղն է, որտեղ նախ նայում եք, երբ ինչ-որ բան կոտրվում է։
• Թարմացումներ և անվտանգության պատչեր, որ կառավարվող հոստինգը ձեզ փոխարեն է անում։

Տարածված թյուրըմբռնումներ

• «Ամպը նշանակում է առանց սերվերների»։ Ամպը ուրիշ ընկերությունների սերվերներն են, որ վարձով են տրվում ժամով կամ օգտագործմամբ։
• «Սերվերը մեծ հատուկ համակարգիչ է»։ Ցանկացած համակարգիչ կարող է սերվեր լինել։ Ձեր նոութբուքը մեկը աշխատեցնում է, երբ բացում եք localhost-ը մշակման ժամանակ։
• «Եթե կոճակը թաքնված է, օգտատերերը չեն կարող այն անել։» Ցանկացած մարդ կարող է հարցումներ ուղարկել ուղղակիորեն ձեր սերվեր։ Թույլտվության ստուգումները պետք է լինեն սերվերում, ոչ միայն էջում։
• «Ավելի շատ սերվերներ դանդաղությունը կշտկեն»։ Հաճախ իրական պատճառը դանդաղ տվյալների բազայի հարցումն է կամ արտաքին API-ն։ Նախ գտեք խցանումը։
• «Հավելված ունենալու համար պետք է սերվեր կառավարել»։ Կառավարվող հարթակները սերվերները աշխատեցնում են ձեզ փոխարեն․ դուք տեղակայում եք կոդը, իսկ նրանք մշակում են մեքենաները։

Ինչ հարցնել AI կառուցիչից

• «Ո՞ր մասերն են այս հավելվածում աշխատում սերվերում, և որոնք՝ բրաուզերում։»
• «Պահիր բոլոր API բանալիները սերվերում և կարդա դրանք միջավայրի փոփոխականներից։»
• «Ստուգիր թույլտվությունները սերվերում յուրաքանչյուր հարցման համար, որ կարդում կամ փոխում է տվյալները։»
• «Ո՞ր տեղ են սերվերի մատյանները, և ի՞նչ են ասում այս սխալի մասին։»
• «Այս հավելվածին որևէ սերվեր պետք է՞, թե կարող է լինել ստատիկ կայք։»
• «Ի՞նչ է լինում առաջին հարցման հետ, երբ հավելվածը երկար ժամանակ անգործ է եղել։»

Սերվերներ Mythex-ում

Mythex-ում սերվերներ չեք կարգավորում և չեք կառավարում։ Կառուցելու ընթացքում ձեր հավելվածը աշխատում է նախադիտման համար մասնավոր ամպային սանդբոքսում։ Երբ հրապարակում եք, Mythex-ը այն տեղակայում է․ ստատիկ frontend-երը՝ որպես ստատիկ կայքեր, իսկ backend-երը (Node, Python, C#, Java և այլն)՝ որպես կոնտեյներներ, որոնք կառուցվում են Dockerfile-ից, առանց հոստինգը ձեր ձեռքով կարգավորելու։ Մեքենայի չափը Mythex-ն ընտրում է տեղակայման ժամանակ․ լռելյայն՝ 1 CPU և 512 ՄԲ հիշողություն, իսկ ավելին՝ պահանջով (մինչև 1 ԳԲ Free-ում, իսկ Pro-ում՝ մինչև 2 CPU, 4 ԳԲ և 3 մեքենա)։ Հրապարակված հավելվածները քնում են անգործության ժամանակ և արթնանում հաջորդ այցի ժամանակ, իսկ քնած հավելվածը հաշվողական ռեսուրսի համար ոչինչ չի ծախսում։ Մանրամասները կան API backend-երի և հոստինգի սահմանափակումների փաստաթղթերում, իսկ մեր վեբ հոստինգի ուղեցույցը տալիս է ավելի լայն պատկերը։

Հարցեր