Семинар Web Application Arthitecture

Пару недель назад я прочитал на dev.by о семинаре для веб-архитекторов и сразу загорелся желанием его посетить – события подобного рода в нашей стране пока не проводилось. Семинар организовывался компанией, где я сейчас работаю, так что по ходу дела помогал организовывать сие действо на месте.

Семинар проходил в образовательном центре IBB, в котором я до этого ни разу не был и который мы с таксистом с трудом нашли :). Здание выглядит необычно, а внутри встречает приятной обстановкой и мягкими яркими диванами.

Заявленную аудиторию нашел быстро, хотя, как оказалось, ее заменили на соседнюю – чуть более просторную. Оставив вещи, пошел на вход встречать участников семинара и направлять их в нашу аудиторию. Первым пришел Володя – ведущий семинара, ну а за ним стали подтягиваться и остальные. Перед началом мероприятия каждый из участников получил бедж для распознавания друг друга и блокнот с ручкой для записывания умных мыслей. Блокнотами я обычно не пользуюсь, но в этот раз исписал его почти до половины – информационный поток просто зашкаливал!

Пару слов о Владимире Лешкевиче, ведущем семинара. У Володи за плечами 14 лет профессиональной разработки ПО; начав простым разработчиком, он прокачался до технического директора, попутно успев побыть и техлидом, и менеджером. Он занимается обучением и коучингом проектных команд по различным технологическим направлениям и процессам разработки. Проработав с Володей некоторое время на реальном проекте, я ожидал от семинара многого, и, конечно, мои надежды оправдались на все 200% - субъективно для меня это был лучший IT день за прошедшие несколько лет.

Все началось, как в первом классе – с представления себя и своего рода деятельности. Уровень участников был очень высокий – не припомню никого ниже senior software engineer. Что приятно удивило – среди участников было два человека из Могилева, специально приехавшие в Минск на семинар.

Выступления Володя проводил по четырем основным темам:

1. Архитектура веб-приложений;
2. Сервисно-ориентированные архитектуры;
3. Объекты-значения в DDD;
4. Производительность и масштабируемость веб-приложений.

Для каждой из тем была заготовлена презентация с основными моментами – но кто ходит на выступления читать презентации?! Володя это прекрасно понимал, потому самое вкусное рассказывал и рисовал на доске.

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

Первой рассмотренной темой была «Архитектура веб-приложений» - наверное, самое простое, что было обсуждено в этот день. Выступление началось с опроса – что интересует участников? Основные интересующие моменты таковы:

1. Как и где проводить границу между Model, View и Controller в паттерне MVC?
2. Как разделять серверную и клиентскую части приложения?
3. Как бороться с разрастанием веб-приложений?

Для начала Володя рассказал о возникновении паттерна MVC и о его первоначальном значении, которое было заложено в языке SmallTalk. Для наглядности был продемонстрирован маленький пример на том же SmallTalk, в котором изящно связывались данные с представлениями – лично меня эта кодинг-сессия приятно удивила и вызвала интерес к продемонстрированному языку. Как оказалось, большинство современных MVC фреймворков (ASP.NET MVC, Ruby on Rails, etc.) очень удалились от оригинальной концепции и выдают за MVC то ли MVP, то ли еще что другое.

Затем Володя представил основные проблемы веб-приложений, исходящие из модели Request-Response, заложенной в основу Веба. Существуют решения этих проблем, например, AJAX, но и они не всегда удовлетворяют требованиям и не до конца прячут низлежащий уровень от программиста и пользователя – во многом из-за проблем совместимости браузеров.

Далее была представлена эволюция паттерна MVC:

1. Оригинальная концепция
2. MVC model 1: Page = View + Controller, где были тесно связаны View и Controller
3. MVC model 2: архитектура с Front Controller, Filter Chain и кучей Actions для обработки запросов.
4. MVCS – MVC на сервисах

Для решения возникающих из-за модели Request-Response проблем стали создаваться различные фреймворки, такие как JSP, ASP. Для имитации десктопного программирования появились компонентные фреймворки ASP.NET, JSF, Tapestry, Wicket. Однако все эти фреймворки в полном соответствии с законом протекающих абстракций не давали полной изоляции и в случае проблем приводили к появлению непонятных ошибок с тяжелыми последствиями.

Проблему модели Request/Response попытались решить созданием отдельного класса приложений с «тяжелым» клиентом – Rich Internet Applications. Модель Request/Response была явно выделена в качестве отдельного компонента для связи с сервером и облегчения создания пользовательских интерфейсов. (Кстати, следует отметить один из принципов Володи – “Be Explicit!”. По нему любая неявно выраженная логика/абстракция/понятие скорее всего приведет к проблеме, которой можно было бы избежать, явно выделяя неявную концепцию.)

На данный момент популярными являются следующие RIA фреймворки:

1. Flex/Flash
2. Silverlight
3. Java FX
4. GWT – здесь, кстати, опять выскакивает закон протекающих абстракций: Java код компилируется в JavaScript, что может привести к необычным ошибкам, которые Java сама по себе вызвать не могла.

Одним из важнейших критериев качества UI фреймворков Володя считает testability – возможность тестирования написанного кода. Чаще всего для тестирования систем используются unit тесты и интеграционные тесты. На стороне unit тестов стоят скорость выполнения, простота написания и покрытия. На стороне интеграционных тестов – польза тестирования нескольких компонентов сразу, за что, правда, приходится расплачиваться значительно возрастающей сложностью тестов. Эту сложность можно преодолеть с помощью инструментов интеграционного тестирования:

1. Selenium
2. Fit
3. HttpUnit

(Было интересно узнать, что некоторые участники используют эти инструменты ежедневно для автоматического тестирования новых версий приложений.)

Как оказалось, и в стане RIA фреймворков не все так просто – вышеупомянутый оригинальный MVC нигде не встречается, везде идут лишь местные замены. К чему это приводит программиста? К необходимости постоянно дописывать свои каркасы на основе базовых классов фреймворков. Часто в качестве замены MVC используется паттерн MVP (Model – View – Presenter) – главное его отличие от MVC заключается в том, что в MVP презентер может давать команды View, а не передавать команды лишь через модель, как в оригинальном MVC.

Далее Володя продемонстрировал очередную кодинг-сессию. На этот раз мы увидели реализацию паттерна MVP на языке Java: маленькое консольное приложение действительно отлично работало и исправно конвертировало переданные ей на вход валюты :)

Кофе-пауза

Сразу после первого выступления мы устроили себе перерыв и разбились по кучкам с чашками свежего кофе и вкусным печеньем. Что порадовало – люди легко шли на контакт и с удовольствием обсуждали архитектурные проблемы и их решения. И надо сказать, момент такой неформальной коммуникации между специалистами различных компаний очень приятен и вызывает желание провести подобный семинар хотя бы ради него.

Сервисно-ориентированная архитектура

Второй темой выступления была «Сервисно-ориентированная архитектура». Для старта мы рассмотрели основные критерии сервиса:

1. Автономный;
2. Имеет явные границы;
3. Имеет явный контракт для взаимодействия;

Исторически наши приложения работают с базами данных, причем в большинстве случаев с монолитным куском данных. Сервисы же позволяют разбить этот кусок на несколько зон с различными ответственностями и зависимостями.

Сервисы, как и паттерн MVC, оказались богаты на историю:

1. RPC – Remote Procedure Call – наверное, первое, что использовалось для подобных целей
2. XML-RPC – формализация RPC, использующая XML в качестве основного формата передачи данных
3. Web Services – SOAP формат на основе XML.
4. REST – Representational State Transfer
5. SOA – сервисно-ориентированные архитектуры

Далее Володя представил плюсы и минусы SOAP Web Services. Плюсы:

1. Открытые стандарты и протоколы
2. Четко выверенный и разделенный интерфейс
3. Service discovery
4. Богатый набор инструментов

Минусы:

1. Сложность и протекающие абстракции
2. Несовместимость
3. Производительность

Альтернативой SOAP WS являются REST WS:

1. У каждого ресурса есть свой URI, по которому они доступны
2. Представления – то, что идет вовне и видно всем
3. Переходы состояний:
• GET – получить
• POST – создать
• PUT – обновить
• DELETE – удалить
4. Плюсы:
• Простота запросов и действий
• Малый порог вхождения – все очень просто
• Масштабируемость простым копированием
5. Минусы:
• Oчень узкий интерфейс для всего многообразия действий
• Не очень легко настроить

Затем Володя представил сформулированные своими коллегами принципы фронт-енд архитектур для сервисно-ориентированных систем (SOFEA – Service Oriented Front-End Architecture). Следует отметить, что этот вопрос не очень хорошо проработан и что эти принципы действительно чуть ли не в первый раз показывались публике.

Для начала – минусы традиционного «тонкого клиента»:

1. Обмен неструктурированными данными
2. Связь presentation flow и обмена данными
• Проблема с кнопкой Back (о нет, не напоминайте...)
3. Request/Response цикл
• Нет прямого взаимодействия двух клиентов

Принципы SOFEA:

1. Разделение Application Download, Presentation Flow, Data Interchange
2. Различные варианты Application Download (тонкий/толстый клиенты)
3. Presentation Flow определяется только клиентом, не должно проходить никаких Request/Response циклов для смены экрана
4. Обмен данными не должен быть слабым звеном
5. B Presentation должен использоваться MVC

Технологии, которые можно использовать для SOFEA:

1. DHTML/AJAX:
• JS
• GWT
2. XML-based
• XAML
• MXML
3. Java
• JavaFX
• Java WebStart
4. Adobe Flex

Кофе-брейк

На этом кофе-брейке образовательный центр IBB порадовал нас не только печеньем, но и бутербродами :) Опять все те же группки, уже более активные обсуждения – людям явно нравилось все происходящее.

Value objects in DDD

Тема DDD очень обширная, поэтому в данном выступлении Володя лишь провел обзор DDD и углубился именно в объекты-значения.

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

DDD характеризуется:

1. Связью с бизнес-доменом
2. Явно выделенной доменной моделью приложения
3. Ubiquitous language – четко определенный язык
4. Model-Driven Design – MDD – развитие приложения «от модели»

Особенности реализации DDD:

• ООП – нативное представление естественных концепций
• Многослойная архитектура
• Entities – сущности
• Value Objects – объекты-значения
• Доменные сервисы
• Bounding contexts - граничные контексты

В DDD сущности несут в себе несколько основных концепций, в частности, роли в системе, ответственности в системе и identity – способность быть распознанной среди других сущностей. Объекты-значения отличаются от сущностей отсутствующей identity. Доменные сервисы объединяют ту логику, которую нельзя явно отнести ни к одной сущности. Bounding contexts используется для деления домена на поддомены.

Мы затронули очень часто встречающийся антипаттерн – Anemic Domain Model. Этот антипаттерн характеризует такое состояние доменной модели, когда:

1. Действие делает не модель, а его делают над моделью
2. Primitive Obsession – одержимость простыми типами (в противовес грамотному определению объектов-значений)
3. Сущности просто несут данные без какой-либо логики

Володя показал несколько примеров Anemic Domain Model, для каждого из которых привел пример рефакторингов, которые оживили ее и придали ей смысл.

Основной причиной для введения объектов-значений является необходимость представлять какие-либо данные и при этом явно держать свой контекст. В качестве примера можно привести SocialSecurityNumber вместо простого String или Identifier вместо привычного Integer. Подобный подход напоминает нам про подход «Be Explicit!», который решает многие проблемы.

Особенности объектов-значений:

1. Явное представление контекста домена
2. Центры гравитации для поведения – концентрируют логику
3. Явно определяют свой интерфейс
4. Они всегда корректны – валидация происходит в момент создания объекта-значения и уже созданный объект-значение всегда корректен
5. Тестируемость
6. Локальность
7. Когерентность – обладают высоким уровнем внутренней согласованности, как FirstName и LastName, а не FirstName и CarBestseller

Объекты значения это не объекты для хранения данных! VO = DO + поведение. Data objects нужны только для передачи данных между различными bounding contexts, внутри доменного контекства использовать data objects нельзя. Еще одной отличительной особенностью объектов для хранения данных является полная несогласованность хранящихся в них данных. В качестве техник для активизации объектов-значений на проекте Володя привел рефакторинг и инкапсуляцию.

Заключительный кофе-брейк

К моменту окончания третьего выступления мы уже вышли за ранее предполагавшиеся рамки мероприятия, однако никто не утратил запала и мы вышли на финишную прямую.

Web application performance. Scalability.

Для начала мы определились с терминологией:

• Производительность (performance) – количество действий в единицу времени
• Масштабируемость (scalability) – способность функционировать при увеличении доступных ресурсов
• Доступность (availability) – способность работать в заданных интервалах времени

Определив необходимые термины, Володя привел подходы к улучшению производительности:

1. Определить требования к производительности приложения
2. Обосновать выбор технологии
3. Тестировать репрезентативно в реальных условиях
4. Тестировать постоянно, чем раньше, тем лучше
5. Наблюдай и диагностируй
• Измеряй, не гадай
• Введи счетчики производительности
• Используй средства диагностики
6. Оптимизируй только то, что действительно надо оптимизировать
• Три правила оптимизации:
• Не оптимизируй
• Еще не оптимизируй
• Профайли и смотри, где надо оптимизировать
• Определи, изолируй, диагностируй, улучши, проверь
7. Разделяй ответственность за производительность со всей командой

Далее Володя подчеркнул основные моменты клиентской производительности:

1. Рендер страницы может быть медленным (до 80% времени загрузки страницы)
2. Правила:
• Минимизируй количество HTTP запросов
• Используй Content Delivery Networks
• Используй кеш браузера и прокси
• Используй GZip
• Размещай стили вверху, а скрипты внизу
• Минимизируй количество DNS lookups
• Вынеси JS и CSS из HTML
• Уменьшай JS & CSS
3. Инструменты
• YSlow
• Google PageSpeed

Основные аспекты доступности:

1. Выбор: доступность или масштабируемость
2. Измерение доступности – количество девяток. Идеал – компания Ericsson с их 99.999999% доступностью в году
3. Уровень доступности приложения, явно указанный в контракте – допустим, не меньше 99.9999%

Основные аспекты масштабируемости:

1. Типы:
• Горизонтальная – увеличиваем количество серверов
• Вертикальная – увеличиваем мощность серверов
2. Техники:
• Load balancing
• Кеширование
• Кластеризирование

Инфраструктура масштабируемости:

1. Load balancing
• Stateful
• Sticky sessions
2. Caching
• Write policy
• Appication caching
• Web caching
• Distributed caching (memcached)
3. Clustering
• Grid-схема
4. Database
• NOSQL подход – Not Only SQL
• In-memory – базы данных в памяти
• Distributed базы данных

Еще мы слегка затронули отдельные моменты систем cloud computing:

1. Распределенные вычисления на серверах другой компании
2. Типы cloud computing:
• Веб-сервисы: Saleforce.com, Google maps
• Сервисные платформы: Google App Engine, Amazon EC2, S3

Ну и напоследок Володя рассказал нам про принципы построения масштабируемых систем:

1. Четко определенные требования по масштабируемости
2. Анализ поведения пользователей – они больше сохраняют данные или просматривают их
3. Динамика контента – общий или персональный, часто или не часто меняется
4. Держать в уме устаревание данных – у вас всегда устаревшие данные! Следует учесть, что уровень устаревания данных определяется не вами, а вашим заказчиком и его бизнес-требованиями
5. Придерживаться принципа subscribe/publish вместо традиционного request/response – на такой подход недавно перешли такие многомиллионные сервисы, как Twitter и Facebook
6. Использовать Command-Query Separation
7. Использовать Actors – независимые асинхронные модули выполнения логики, изначально появились в языке Erlang и с тех пор обеспечивают компании Ericsson заветные 99.999999% доступности в году.

Впечатления от семинара остались чрезвычайно позитивные, лишние часы прошли незамеченными, а мелкие неудобства просто не замечались! Дух обсуждений, возможность пообщаться с коллегами поддерживали интерес к мероприятию на протяжении всего дня.

Громадное спасибо Владимиру Лешкевичу и компании Intetics, которые организовали этот праздник IT-счастья!