5 вообичаени поставки на сервер за вашата веб-апликација

Вовед

Кога одлучувате која архитектура на сервер да ја користите за вашата околина, треба да се земат предвид многу фактори, како што се перформанси, приспособливост, достапност, доверливост, цена и управување.

Во ова упатство, ќе научите за најчесто користените поставки на серверот, со краток опис на секое, вклучувајќи ги добрите и лошите страни. Имајте на ум дека сите концепти опфатени овде може да се користат во различни комбинации еден со друг и дека секоја средина има различни барања, така што не постои единствена правилна конфигурација.

Поставување сè на еден сервер

Едно поставување на сервер е кога цела околина се наоѓа на еден сервер. За типична веб-апликација, ова ги вклучува веб-серверот, серверот за апликации и серверот за бази на податоци. Вообичаена варијација на ова поставување е стек LAMP, што значи Linux, Apache, MySQL и P<HP, на еден сервер. Пример за употреба за ова е кога сакате брзо да поставите апликација. Основно поставување како ова може да се користи за тестирање на идеја или да се активира едноставна веб-страница.

За жал, ова нуди малку во однос на приспособливоста и изолацијата на компонентите. Дополнително, апликацијата и базата на податоци се борат за истите ресурси на серверот како што се процесорот, меморијата, влезот/излезот и многу повеќе. Како резултат на тоа, ова може да предизвика слаби перформанси и да го отежне утврдувањето на основната причина. Користењето на еден сервер исто така не е лесно хоризонтално скалабилно. Можете да дознаете повеќе за хоризонталното скалирање во нашето упатство за Како да инсталирате LAMP на Ubuntu 22.04. Следното е визуелна претстава за користење на еден сервер:

Поставување сервер за посебна база на податоци

DMZ, или јавен интернет.

Пример за употреба е тоа што ова може брзо да ја постави вашата апликација и да ја спречи апликацијата и базата на податоци да се борат за истите системски ресурси. Можете исто така вертикално да ја скалирате секоја апликација и ниво на база на податоци посебно. Ова е можно со додавање на повеќе ресурси на кој било сервер има потреба од зголемен капацитет. Во зависност од поставувањето, ова исто така може да ја зголеми безбедноста со отстранување на вашата база на податоци од DMZ.

Ова поставување е малку покомплексно од еден сервер. Проблемите со перформансите, како високата латентност, може да се појават ако мрежната врска помеѓу двата сервери е географски оддалечена еден од друг. Може да има и проблеми со перформансите ако пропусниот опсег е премногу низок за количината на податоци што се пренесуваат. Можете да прочитате повеќе за Како да поставите далечинска база на податоци за да ги оптимизирате перформансите на страницата со MySQL. Следното е визуелна претстава за користење на посебен сервер за база на податоци:

Поставување Load Balancer (Обратно прокси)

Балансери на оптоварување може да се додадат во опкружувањето на серверот за да се подобрат перформансите и доверливоста со дистрибуција на обемот на работа низ повеќе сервери. Ако еден од серверите со балансирано оптоварување не успее, другите сервери ќе се справуваат со дојдовниот сообраќај додека неуспешниот сервер повторно не стане здрав. Може да се користи и за опслужување на повеќе апликации преку истиот домен и порта, со користење на обратен прокси на слојот 7. Неколку видови софтвер способни за обратно балансирање на оптоварувањето на прокси се HAProxy, Nginx и Varnish.

Пример за употреба е во средина која бара скалирање со додавање повеќе сервери, исто така познато како хоризонтално скалирање. Кога поставувате балансер на оптоварување, тој овозможува капацитет на околината што може да се зголеми со додавање на повеќе сервери на него. Може да заштити и од DDOS напади со ограничување на врските со клиентот на разумна количина и фреквенција.

Поставувањето на балансерот на оптоварување може да доведе до тесно грло во перформансите ако балансерот на товарот нема доволно ресурси или ако е лошо конфигуриран. Исто така, може да претставува сложеност што бара дополнително разгледување, како на пример каде да се изврши завршување на SSL и како да се ракува со апликации кои бараат лепливи сесии. Дополнително, балансерот на оптоварување е единствена точка на дефект, тоа значи дека ако се спушти, целата ваша услуга може да се намали. Поставувањето висока достапност (HA) е инфраструктура без ниту една точка на дефект. За да научите како да имплементирате поставување на HA, можете да ја прочитате и нашата документација за Вовед во концептите за HAProxy и Load Balancing. Следното е визуелен приказ на поставувањето на балансерот на оптоварување:

Поставување HTTP акцелератор (Кеширање обратен прокси)

Забрзувач на HTTP или обратен прокси за кеширање на HTTP, може да се користи за да се намали времето потребно за сервирање содржина на корисникот преку различни техники. Главната техника што се користи со забрзувачот на HTTP е кеширање на одговорите од веб или сервер на апликации во меморијата, така што идните барања за истата содржина може да се сервираат брзо, со помалку непотребна интеракција со веб-серверите или апликациите. Неколку примери на софтвер способен за HTTP забрзување се Varnish, Squid, Nginx. Пример за употреба е во средина со динамични веб-апликации со голема содржина или многу датотеки до кои најчесто се пристапува.

Забрзувањето на HTTP може да ги зголеми перформансите на страницата со намалување на оптоварувањето на процесорот на веб-серверот, преку кеширање и компресија, а со тоа да го зголеми капацитетот на корисникот. Може да се користи и како обратен баланс на оптоварување на прокси, а некои софтвери за кеширање можат дури и да заштитат од DDOS напади. За жал, може да ги намали перформансите ако стапката на удари во кешот е ниска и бара подесување за да се извлечат најдобри перформанси. Следното е визуелна претстава за поставување на забрзувач на HTTP:

Поставување на репликација на база на податоци со примарна реплика

Еден начин да се подобрат перформансите за систем на бази на податоци што врши многу читања во споредба со запишување, како што е CMS, е да се користи репликација на базата на податоци со примарна реплика. Репликацијата бара еден примарен јазол и еден или повеќе реплика јазли. Во ова поставување, сите ажурирања се испраќаат до примарниот јазол и читањата може да се дистрибуираат низ сите јазли. Примерен случај на употреба е зголемување на перформансите за читање на нивото на базата на податоци на апликацијата. Поставувањето на репликација на базата на податоци со примарна реплика ги подобрува перформансите за читање на базата на податоци со ширење на читањата низ репликите и ги подобрува перформансите за пишување со користење исклучиво за ажурирања, без потрошено време за опслужување барања за читање.

Некои од лошите страни за репликација на базата на податоци со примарна реплика се тоа што апликацијата што пристапува до базата мора да има механизам за одредување на кои јазли на базата на податоци треба да испраќа барања за ажурирање и читање. Исто така, ако примарниот не успее, не може да се вршат ажурирања на базата на податоци додека не се поправи проблемот. Исто така, нема вградено откажување во случај на дефект на примарниот јазол. Следното е визуелен приказ на поставување на репликација на примарна реплика, со еден јазол на реплика:

Комбинирање на концептите

Можно е да се вчитаат рамнотежа на серверите за кеширање, покрај серверите за апликации, и да се користи репликација на базата на податоци во една средина. Целта на комбинирањето на овие техники е да се искористат придобивките од секоја од нив без да се воведат премногу прашања или сложеност. Еве еден пример дијаграм за поставување на овој тип серверска околина:

На пример, замислете сценарио каде што балансерот на оптоварување е конфигуриран да препознава статични барања (како слики, CSS, JavaScript, итн.) и да ги испраќа тие барања директно до серверите за кеширање и да испраќа други барања до серверите на апликациите.

Еве преглед на процесот кога корисникот испраќа барање за динамична содржина:

  1. Корисникот бара динамична содржина од http://example.com/ (баланс на оптоварување)
  2. Баланс на оптоварување го испраќа барањето до задниот дел на апликацијата
  3. Бекндот на апликацијата чита од базата на податоци и ја враќа бараната содржина за да се вчита балансерот
  4. Баланс на оптоварување ги враќа бараните податоци на корисникот

Кога корисникот бара статична содржина, се применува следниот процес:

  1. Балансерот на оптоварување го проверува кешот за да потврди дали бараната содржина е кеширана (погодена кеш) или не (кеш-промашување)
  2. Ако содржината е погодена од кеш, тоа значи дека ќе ја врати бараната содржина во балансерот на оптоварување и ќе скокне до последниот чекор во процесот и ќе ги врати податоците на корисникот. Ако содржината е пропуштена во кешот, кеш-серверот го препраќа барањето до задниот дел на апликацијата преку балансерот на оптоварување
  3. Балансерот на оптоварување го проследува барањето до задниот дел на апликацијата
  4. Бекндот на апликацијата чита од базата на податоци и ја враќа бараната содржина во балансерот на оптоварување
  5. Балансерот на оптоварување го препраќа одговорот до кеш-заден дел
  6. Кеш-задниот дел ја кешира содржината и ја враќа во балансерот на оптоварување
  7. Баланс на оптоварување ги враќа бараните податоци на корисникот

Ова опкружување сè уште има две единечни точки на неуспех, балансерот на оптоварување и примарниот сервер за база на податоци, но ги обезбедува сите други придобивки за сигурност и перформанси кои беа опишани во претходните делови.

Заклучок

Сега кога сте запознаени со некои основни поставки на серверот, треба да имате добра идеја за тоа каков вид на поставување би користеле за вашите сопствени апликации. Ако работите на подобрување на сопственото опкружување, запомнете дека итеративен процес е најдобар за да избегнете пребрзо воведување премногу сложености.