Преглед садржаја
Шта је скалабилност?Скалабилност је пожељно својство система, мреже или процеса, што указује на његову способност да реагује и прилагоди се без губитка квалитета, или да се флуидно носи са сталним растом посла, да буде спреман за повећање без губитка квалитета у понуђеним услугама .
Могли бисте рећи која је способност нашег система да подржи веће оптерећење модификацијама или проширењима која су разумна у смислу трошкова, времена, времена и сложености.
Врсте скалабилности
Уопштено можемо говорити о вертикалном и хоризонталном скалирању или о комбинацији оба.
Вертикално скалирање
У основи се састоји од повећања капацитета једног или више специфичних елемената наше архитектуре, на примјер проширења меморије нашег централног сервера или замјене ЦПУ -а другим брзинама. Укратко, повећајте капацитете сервера, што је врло уобичајено када користимо виртуализацију и кажемо да ће тада сервер имати 30% РАМ -а на располагању.
Хоризонтално скалирање
То је онај који ћемо детаљно описати у водичу, заснива се на повећању броја чворова који извршавају исти задатак, користећи различите врсте планирања, на пример ако имамо засићен веб сервер, додајемо још један за уравнотежење оптерећења.
Врсте веб архитектуре засноване на нивоима.
Причаћемо о архитектурама које се могу применити на линук системима, користећи алате отвореног кода прећи ћемо од најосновнијих до неких прилично напредних који нуде хоризонталну скалабилност и отпорност на неуспех, све ове архитектуре се могу применити у било ком ПааС или са сопственом инфраструктуром.
1. Архитектура на једном нивоу
То је најосновније од свега где постоји само један сервер са Апацхе -ом и МиСКЛ -ом коме се може приступити даљински. Врло је уобичајен на страницама са малом маргином посета или тестним окружењима, не нуди никакву границу толеранције на неуспех и тешко га је користити за хоризонтални раст.
2. Двослојна архитектура
Овај пут смо одвојили базу података од веб сервера нудећи мало толеранције грешака. На овај начин, ако база података не успе, веб сервер може понудити садржај на статички начин који не зависи од базе података. У случају отказивања веб сервера, и даље можемо приступити информацијама тако што ћемо поново подићи нови веб сервер. Дизајн нуди неколико недостатака јер није баш скалабилан дизајн.
3. Трослојна архитектура
Овај пут почињемо да користимо балансирање оптерећења које ће примати све захтеве корисника. Овај пут нудимо скалабилнији дизајн тако да ако се наше оптерећење повећа можемо додати више веб сервера и скалу. Можемо чак применити и аутоматско скалирање тако да се веб сервери додају аутоматски на одређеном нивоу оптерећења или у часу највеће потрошње. Проблем са овим дизајном је што можемо заситити нашу базу података.
4. Четворостепена архитектура
Сада користимо баланс оптерећења и мемцацхед меморирање чиме систем постаје скалабилнији. Овим дизајном можемо додати онолико база података и веб сервера колико је потребно осим што нуде толеранцију грешака. Оптерећење између база података можемо поделити са ЦАССАНДРА нуди имплементацију са више чворова. Овај дизајн је много сложенији, али додајем много већу толеранцију грешака и могућност скалирања свих његових нивоа.
5. Петостепена архитектура
Садржај веб странице може се поделити на статички и динамички. На пример, веб слој делимо на Апацхе сервер и други са ЈАВА апликацијама које покрећу Јетти или ЈБосс. Апацхе пружа статички садржај, док сервер апликација управља динамичким садржајем или садржајем у ходу. Пример за ово може бити одељак Честа питања на веб локацији за подршку, јер је то само статички садржај, а њиме може руковати АПАЦХЕ / НГИНКС.
ЕНЛАРГЕ
6. Шестостепена архитектура
Можемо бити мало елегантнији и додати мрежу за испоруку садржаја (ЦДН), или оно што је у АВС -у познато као Амазон ЦлоудФронт ЦДННа пример, имамо веб локацију за е-учење и наши корисници преузимају Водиче у ПДФ-у или видео записима са наше веб странице. Можемо сачувати сву пропусност посвећену преузимању, нудећи је са ЦДН -а који се брине за то, остатак веба може да ради на нашој инфраструктури.
ЕНЛАРГЕ
