avlasov (avlasov) wrote,
avlasov
avlasov

Category:

Мини-учебнег по распределенным системам/протоколам. Распределенные веб-системы

Рассмотрим теперь особенности создания распределенных веб-систем. Как обычно, в данном случае, у распределенности могут быть три основных цели: повышение быстродействия, отказоустойчивость и распределение по нескольким дивайсам из каких-то других соображений. В качестве примера последнего, можно привести N-tier, впрочем, веб-приложения в своей основе содержат клиентскую часть, которая исполняется в браузере (обычно) на другом сетевом устройстве.

Рассмотрим сперва N-tier. Допустим мы разбиваем функциональность приложения по таким слоям: presentation layer, service layer, logic layer и data layer. Если мы presentation вынесем на клиента (Ajax и проч), то можем существенно снизить нагрузку на серверную составляющую, в частности, можем уменьшить кол-во веп-запросов, ибо какие-то функции можно реализовать на стороне клиента используя JavaScript. Иногда на клиент выносится и часть логики, или может быть даже какой-то аспект персистенса (т.е. часть инфы можно хранить на локальном диске клиента).
Точно так же, если мы выделим отдельный компьютер для базы данных (data layer), то она может исполнять больше запросов, чем ежели бы на ней еще гонялся веп-/апп-сервер(а).

Таким образом, N-tier, т.е. физическое разделение разных (логических) слоев есть весьма логичное направление в создании веб-систем. К тому же, обычно они пишутся на разных языках, так что все равно как-то надо пересекать границу процессов, ну а там уже и физически разместить по разным серверам не так сложно.

Понятно, что раз мы разнесли функционал по разным компам, то этим распределенным процессам нужно как-то коммуницировать. Опять-таки, тут все достаточно стандартно, ибо клиент к серверу ходит по стандартному протоколу - HTTP (точнее конечно протоколам, но не суть важно). Доступ к data layer так же часто идет через в парадигме клиент-сервер, т.е. вендор БД реализует тот или иной протокол доступа к серверу БД через сеть. Таким образом, некоторая распределенность в веп-приложение уже встроена по умолчанию. И нам в основном надо сконцентрироваться на том, что выходит за рамки этих стандартных протоколов. Например, если у нас логика физически разносится на две-три разных слоя серверов (ну типа там Proxy, Web Server, App Server), то им надо как-то коммуницировать и HTTP тут не совсем удобен. Обычно используется та или иная форма Remote Procedure Call.

Однако, цель моей серии постов является прояснение аспектов связанных с восстановлением после сбоев и репликацией состояния. К сожалению, стандартные реализации RPC и проч не сильно в этом помогают. Точнее всякие вендоры всяких систем дают какие-то затычки для решения части возникающих проблем, что с одной стороны неплохо, а с другой стороны затрудняет полноценное и последовательное решение проблемы (ибо надо согласовывать подход к репликации/восстановлению после сбоев с особенностями, заложенными в архитектуре того или иного вендора чего-то там). Соответственно, в последующих постах я буду разбирать эти проблемы и варианты их решения.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments