begebot@yandex-team.ru

Денис Бугарчев

ШРИ 2013 Архитектура веб-приложений

Архитектура веб-приложений

Что такое архитектура?

Что такое приложение?

Что такое веб-приложение?

Архитектура

Как процесс

создание, проектирование и планирование

Как предмет

проект = архитектура + код

Приложение

Решаем некоторую (произвольную) задачу. Какую?

Приложение

Приложение

Приложение

Решаем некоторую задачу

+

Некий исполняемый код

Структура приложений

Отображение

Логика (бизнес-логика)

Данные (доступ)

Веб

Какие особенности?

Много клиентов

HTTP

Веб-приложение

Суммируем:

Решаем задачу исполняемым кодом с определенной структурой для множества клиентов.

Структура веб-приложений

Отображение

Бизнес-логика

Данные

Какая простейшая структура веб-приложения?

Структура веб-приложений

Клиент (ы) <======> Сервер

Двухзвенная архитектура

В простейшем случае – сервер один

Двухзвенная архитектура

Клиент:

Отображение

Сервер:

Данные

Куда бизнес-логику?

Двухзвенная архитектура

Клиент:

Отображение

Бизнес-логика

Сервер:

Данные

Двухзвенная архитектура

Клиент:

Отображение

Сервер:

Данные

Бизнес-логика

Двухзвенная архитектура

Клиент:

Отображение

Бизнес-логика

Сервер:

Данные

Минусы?

Двухзвенная архитектура

"Толстый" клиент

высокие требования к производительности клиента

работа в разных окружениях

высокие требования к серверу (если он один), как следствие плохая масштабируемость

Двухзвенная архитектура

Клиент:

Отображение

Сервер:

Данные

Бизнес-логика

Минусы?

Двухзвенная архитектура

"Тонкий" клиент

еще выше требования к серверу

нагрузка на канал связи

масштабируемость остается общей проблемой

Двухзвенная архитектура

Исторически двухзвенная возникла первой

По мере роста требований понадобилось придумывать другую архитектуру

Требования

Возникла большая нагрузка, понадобилось делать кеширование

Возникла сложная логика урлов, утяжеляющая БД

Понадобилось заменить клиент или добавить другой с отличающимся функционалом (к сайту добавить мобильное приложение)

Трехзвенная архитектура

Тонкий(?) клиент (браузер):

Отображение

Сервер приложений (frontend):

Бизнес-логика

Сервер (backend):

Данные

Разделение на звенья

Основной принцип - каждое отдельное звено можно заменить не меняя другие

Например:

замена или добавление клиента

замена БД

изменение фронтенда (например замена шаблонизатора)

Трехзвенная архитектура

Клиент (стрелочка вниз)

Frontend (стрелочка вниз)

Backend

Подробнее про стрелочки

Трехзвенная архитектура

Клиент<=>Frontend

В качестве транспорта – http (в т.ч. ajax)

Что передаем, что получаем?

Формат запросов

Клиент<=>Frontend

Формат запросов

Две важные парадигмы

• REST

• RPC

REST

Representational state transfer

У ресурсов есть уникальный идентификатор (в нашем случае URL)

/book/173

/books-by-author/pushkin?type=poem

REST

Универсальный интерфейс доступа к ресурсам и их изменения. В случае веба HTTP методы запроса указывают на тип взаимодействия.

GET /book/117 – получение ресурса

POST /create/book?title=...&... – создание ресурса

DELETE /book/117 – удаление ресурса

UPDATE /book/117?title=... – редактирование ресурса

REST

Важные особенности

• кеширование (на уровне протокола или сервера)

• stateless (нет промежуточной информации на сервере)

• возможность использования между любыми двумя звеньями (клиент-фронтенд-бэкенд)

RPC

Remote Procedure Call

Удаленный вызов процедур

/gate?action=getBooksList

RPC

Отличительные черты

• протокол, включающий унифицированную передачу параметров запроса

• сериализация ответа

• бОльшая провязка между клиентом и сервером

Клиент<=>Frontend

Формат ответов

JSON (на клиенте js)

XML (на клиенте что-то еще или просто-так)

HTML

Различие между 1-2 и 1-3

Frontend<=>Backend

Формат запросов

И REST и RPC (CORBA, SOAP, etc)

Формат ответов

Очень вариативно, как правило data-ориентированный, нет смысла в передаче HTML

Семантика запросов

Существуют разные подходы к предмету запросов

вызов больших методов ("ручек"), которые хорошо знают конечную структуру страниц

вызов более мелких методов API со стороны бэкенда

Большие методы

Знают что надо, например getIndexPage

Плюсы - скорость

В чем выигрыш по скорости?

Большие методы

Знают что надо, например getIndexPage

Плюсы - скорость

экономия на общении фронтенд-бэкенд (по сути это двухзвенная архитектура)

меньше нагрузка на базу данных

Большие методы

Минусы

Теряется гибкость разработки, при любом изменении требуется работа специалиста бэкенд и фронтенд

Упомянутые недостатки двухзвенной архитектуры -

если добавится (изменится клиент) надо делать новые ручки

Backend API

Делаем небольшие ручки на каждый тип ресурсов (REST или RPC)

Теряется скорость, добавляется гибкость.

Итоги: выбор архитектуры

Все исходит из задачи

По сути звеньев можно выделить сильно больше

клиент - http-сервер - фронтенд - управление базой данных - база данных

плюс балансеры для распределения нагрузки

Выбор архитектуры

Важно, что разделение на части позволяет специализировать людей, проводить независимые изменения, масштабировать команду

Выбор архитектуры

Важно, что разделение на части позволяет специализировать людей, проводить независимые изменения, масштабировать команду

Скорость разработки важна, по сути это эффективность нашей работы

Выбор архитектуры

Важно, что разделение на части позволяет специализировать людей, проводить независимые изменения, масштабировать команду

Скорость разработки важна, по сути это эффективность нашей работы

Но иногда задача диктует требования, решение которых приводит к усложнению жизни разработчиков

Вопросы?