Embed Size (px)
Citation preview
Архитектура веб-приложений
Что такое архитектура?
Что такое приложение?
Что такое веб-приложение?
Архитектура
Как процесс
создание, проектирование и планирование
Как предмет
проект = архитектура + код
Приложение
Решаем некоторую (произвольную) задачу. Какую?
Приложение
Приложение
Приложение
Решаем некоторую задачу
+
Некий исполняемый код
Структура приложений
Отображение
Логика (бизнес-логика)
Данные (доступ)
Веб
Какие особенности?
Много клиентов
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-сервер - фронтенд - управление базой данных - база данных
плюс балансеры для распределения нагрузки
Выбор архитектуры
Важно, что разделение на части позволяет специализировать людей, проводить независимые изменения, масштабировать команду
Выбор архитектуры
Важно, что разделение на части позволяет специализировать людей, проводить независимые изменения, масштабировать команду
Скорость разработки важна, по сути это эффективность нашей работы
Выбор архитектуры
Важно, что разделение на части позволяет специализировать людей, проводить независимые изменения, масштабировать команду
Скорость разработки важна, по сути это эффективность нашей работы
Но иногда задача диктует требования, решение которых приводит к усложнению жизни разработчиков
Вопросы?
