"Scala in Goozy", Alexey Zlobin
•Download as PPT, PDF•
0 likes•397 views
This document summarizes the architecture and design of Goozy, a social networking application built using Scala. Key points include: 1. Goozy uses the Scala programming language and is built around a RESTful API server with functionality for storage, background tasks, and email sending. 2. The application was originally developed using some features of the Lift web framework but encountered various issues related to performance, code style, and complexity. 3. The developers refactored to use the "cake pattern" which separates functionality into components with explicit dependencies to improve modularity, testability, and code quality.
![Scala in Goozy Alexey Zlobin, e-Legion [email_address] @CheatEx](https://image.slidesharecdn.com/scalaingoozy-120225015748-phpapp02/85/Scala-in-Goozy-Alexey-Zlobin-1-320.jpg)
![Index ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to "Scala in Goozy", Alexey Zlobin
Similar to "Scala in Goozy", Alexey Zlobin (20)
More from Vasil Remeniuk
More from Vasil Remeniuk (20)
Recently uploaded
Recently uploaded (20)
"Scala in Goozy", Alexey Zlobin
- 1. Scala in Goozy Alexey Zlobin, e-Legion [email_address] @CheatEx
- 27. Error handling: big picture
Editor's Notes
- Данном докладе я расскажу о нашем с Юрой опыте использования Scala в живом проекте. Я не буду пытаться давать обзоры использованных технологий, в место этого доклад будет сконцентрирован на встреченных и найденных решениях.
- Мой доклад будет проходить по следующему плану: 1. Сначала я кратко расскажу о сервисе который мы собственно разрабатываем. 2. Потом я рассмотрю место которое занимает Scala, точнее написанные на ней компоненты в проекте. И расскажу почему именно она была выбрана для их реализации. 3. Далее расскажу о том как в проекте используется известный фреймворк lift. 4. В четвёртой части я дам обзор логического устройства и того как на его становление повлиял широко разрекламированный cake pattern. 5. В пятой части будет рассказано про использовани библиотеки Scalaz в проекте. Закончу я тем, что расскажу про основные усвоенные из этого проекта уроки.
- Итак, наш проект Goozy - социальная сеть, построенная вокруг концепции стикеров дял интернет-страниц. Основаня идея в том, что пользователь может оставлять в сети заметки с помощью браузерных плагинов и делиться имим со своими друзьями. Тут важно заметить, что помимо собственно оставления и просмотра стикера центральной концепцией интерфейса сервиса является так называемая "лента" - поток стикеров и комментариев от друзей данного пользователя. Проект уже достаточно пожилой и пережил несколько итераций разработки. Текущая итерация началась зимой с амбициозной целью построения бэкэнда для этого сервиса, способного обслуживать до миллиона активных пользователей. Современная архитектура проета выглядит так:...
- Хранение данных доверено популярной ныне MongoDB. Это документоориентированаая БД, со встроенной поддержкой шардинга и репликации. Непосредственно с ней общаются так анзываемые сервера API. Они экспортируют REST интервейсы доступа к данным. Кроме того они отвечают за взаимодействие с внешними сервисами, такими как S3 и системы полнотекстового поиска. Несколько серверов подключаются к балансировщику нагрузки. К нему же подключаютс сервера с развернутым порталом проекта. Портал не общается напряму с БД и делегирует большинство взаимодействий с внешними сервисами API. Во внешний мир смотрит специально настроенный интерфейс балансера, открывающий доступ к порталу и предназначенным для этого методам API. Клиентские приложения прозрачно общаются с API и порталом по протоколу HTTP.
- Основные функции, которые он на себя берёт это: 1. Управление доступом к хранилищам данных. 2. Выполнение части задач обработки данных в фоне. 3. Отсылка писем. 4. Направление необходимых данных в текстовые индексы. Тут встаёт вопрос: почему же для его реализации был выбран язык Scala? У меня есть следующие ответы...
- Во-первых программы на нём быстры. Плохой алгоритм он не выправит, но написанный хорошо скорее всего будет работать со скоростью не очень далёкой от максимальной. Во-вторых он краток. Он не выедает время на ввод текста и поиск по нему. Более менее целостный компонент приложения обычно умещается на одном экране. Это очень положительно влияет на скорость работы. Он выразиетен. Если на нём нужно что-то сказать можно взять и сказать именно это. С ним нужда в ритуалах, не связанных с решаемой проблемой, минимальна. В есть целый ряд инструментов отсутствующих в других ОО-языках. Многие из них радикально упрощают решение архитектурных проблем. В первую очередь это traits (Кстати где-то видел их перевод как "типажи". Кто-нибудь им пользуется?). Кроме того более глубокая поддержка обобщённых типов положительно влияет ан стандартную библиотеку и соответственно почти на весь код. В ней есть развитая поддержка функционального программирования. В первую очередь это простая работа с константами. Как следствие значительно проще, чем в Java пистаь корректный многопоточный код. Ну и наконец нам доступен весь огромный арсенах библиотек, написанных на Java. Прежде чем углубиться в технические моменты пара слов о том, что вызывает наибольшие страхи перед переходом на Scala. Это люди, которые ан ней должны писать...
- Итак, команда наша состояла из 2 человек. Все имели заметный опыт работы с Java в самых разнообразных направлениях. Ну и что важно все фанаты своего дела и любят новые технологические игрушки. Как следствие вопросы вроде разобраться с новой штукой или продраться через трёхэтажную ругань компилятора на несходящиеся типы никогда не превращались в проблемы. Теперь можно переходить и к технической стороне вопроса. Первое о чём хочется рассказать - это опыт применения Lift'а для создания REST-сервиса.
- В связи с узостью решаемой задачи из всего огромного вреймворка импользуется буквально два модуля. Это поддержка REST сервисов и автоматическая сериализация case классов в JSON. Несмотря на скромность используемого функционала мы натолкнулись на несколько проблем.
- Две связаны с производительностью и одна эстетического плана. Во первых мы столкнулись с очень низкой производительностью встроенного механизма интернационализации. Большие критические секции в его коде привели к тому, что на топовом EC2 инстансе мы могли обрабатывать порядка 20 запросов в секунду. Надо сказать, что это был очень грустный момент. Крутая модная БД, быстрый язык, ооочень много ядер и 20 запросов :( Но проблема нашлась быстро, код был переведён на на стандартные ResourceBundles, что увиличило пропускную способность в 4 раза. Вторая проблема выявленная, но не решённая - это потребление памяти при сериализации в JSON. Если не вдаваться в детали, то одни и те-же данные там переупаковываются 3 раза,, что накладывает определённые ограничения на производительность... Ну и последнее это сложный исходный код самого Lift. Местами просто сборник худших стереотипов о Scala. На этапе освоения невозможность быстро читать исходный код сильно тормозила разработку.
- Теперь давайте немного рассмотрим архитектуру нашего API сервера. Логически она разнесена на честные (кстати впервые в моей практике) три уровня. Контролер - это код непосредственно связанный с лифтом и осуществляющий преобразование данных из HTTP во внутренние модели данных и обратно. Сервисы это фасады для операций, реализуемых сервером. Ещё целостные в терминах API (одна экспортируемая наружу операция - один метод), но уже оперирующие внутренними моделями данных. Внутри себя они координируют работу нескольких служб более низкого уровня, таких как рассылка почты,текстовый поиск, взаимодействие с внешними сервисами. Сложные операции с данными делегируются третьему уровню. Он отвечает за сохранение моделей данных в БД и их загрузку оттуда. Каждый уровень состоит из нескольких компонентов, образованных операциями над близкими классами моделей: пользователями, стикерами, лентой и т.д. Обеспечение поддерживаемости всего этого хозяйства имеет определённые трудности...
- Во-первых компоненты каждого уровня обычно зависят друг от друга. Скажем загрузка объекта стикера требует загрузки объекта пользователя, который его оставил и т.п. Вторая проблема сотоит в том, и от предыдущего уровня компоненты имеют несколько зависимостей. Кроме того внутри одного уровня обычно имеется большое количество разделяемых данных и объектов. Например сконфигурированный пул соединений с БД или сервисом поиска.
- Решение этих труднойстей мы попробовали найти в популярном в сообществе cake pattern. (Уточнить нужны ли пояснения) Я попробую сформулировать основные результаты этого решения...
- Из положительного мы имеем: 1. Архитектура приложения выражена непосредственно в коде объёмом около 100 строк. Имеется в виду собственно конструирование рантайм компонентом и описанием всех зависимостей между ними. 2. Корректность описания зависимостей проверяется компилятором. 3. Сами компоненты получились сравнительно компактными. Размер отдельных классов в основном не превышает 100 строк. Основные проблемы которые при этом наблюдаются: 1. Длинные (иногда очень длинные) списки зависимостей у отдельных компонентов. Видимо это проблема нашего дизайна, но при использовании например Spring её можно спрятать подальше. 2. Неявная зависимость от порядка перечисления примесей в описании рантайм конфигурации. Случайное изменение этого порядка рефакторинг связанный с переносом функционала между компонентами часто видёт к падению приложения при старте. К счастью этот класс ошибок гарантированно отлавливается простейшим тестом. 3. Не понятно что делать, если у нас есть несколько одинаковых по типу зависимостей, которые однако должны иметь разные имплементации в рантайме. Например у нас есть две очереди сообщений и компонент должен уметь обращаться к обоим. Создание отдельного класса для каждого назначения одного и того же интерфейса не кажется хорошей идеей. Теперь пора рассказать про нашу любимую игрушку в проекте:
- Одной из проблем вставшей на ранней стадии разработки проекта был корректные ответы клиенту при ошибках. То есть ответ должен был содержать краткое её описание, например "входной параметр вне допустимого диапазона" и правильный http-код. Естественно если у нас обнаруживалось несколько проблем доложить хотелось обо всех, что крайне осложняло использование исключений для этой цели. В то время я как раз наткнулся на пост известного скала-блоггера Дебашиша Гоша. И однажды я бросил Юре ссылку на блогпост с описанием обработки ошибок с помощью апликативных функторов. День спокойно проработал над какой-то фичёй, а уже следующим утром при обновлении и общего репозитария получил код из того поста...
- Как собственно осуществлялся переход. В начале у нас был набор наших исключений которые при случае выбрасывались. И некоторые из них преобразовывались в ответы клиенту. Выглядели они так.
- Собственно первым шагом для использования валидаций всегда должно становится определение типа ошибки. Так как конечной целью всей этой затеи было отправлять корректные ответы по http, то были созданы вот такие вот классы (их естественно было много больше) которые несли в себе данные об ошибке и нужный http-код. Всё было хорошо мы начали использоать вот такие вот структуры для сообщений об ошибках в параметрах запросов. Потихоньку распространяли это вглубь, на логику работы с БД... Но тут до нас дошло
- В JVM бывают исключения. Они бывают по разным причинам, именно их используют многие замечательные библиотеки вроде casbah. И оборачивать каждое обращение к ним в try/catch абсолютно нереально. Мало того, кода бросающего наши исключения уже было немало.
- Для решения проблемы была выбрана следующая стратегия: определить функцию конвертер из всех исключений в наши ошибки. Написать небольшую бибилотеку которая упростила бы обращение к этой функции из нашего кода.
- В первую очередь мы добавили ещё одну унверсальную ошибку. Полагая что непредвиденное и не имеющее соответствующего маппинга исключение - это наш косяк и его надо рапортавать 500 кодом.
- Написали такой вот простой конвертер.
- И маленький набор утилит. Свой алиас для валидаций с подставленным типом ошибки. Обратите внимание что это очень удобно делать в любом проекте, так как мы получаем kind с 1 параметром, что в силу особенностей scala радикально упрощает написание некоторых сигнатур. Посмотрите на пример использования sequence - 80% этого ужаса уходит если есть такой алиас. Здесь я использовал очень интересную и очень малоизвестную часть стандартной библиотеки scala.control.Exceptions. Она демонстрирует интересный подход к проблеме функциональной обработки исключений, советую посмотреть.
- Ещё была написана куча утилит для безопасного парсинга разных типов данных, работы с mongo объектами и ещё чем-то... Я их сюда не вставлял, так как перед новым годом накатал изрядный текст не тему как их писать, они достаточно тривиальны.
- Имея весть этот арсенал мы начали плавно двигать валидации глбже и глубже в наш код... Получилось вполне себе мило, была куча вот такого вот симпатичного кода. Хаскелисты должны прослезится...
- Но в процессе появлялся и другой код...
- Вот такой вот... Возможно причина его появления в моём низком мастерстве использования этого аппарата. Но мне кажется что это фундаментальная проблема: есть класс кода который значительно читабельнее в старой доброй императивной форме с исключениями.
- Так это или нет, нов итоге сформировался такой подход. Нов итоге сформировался такой подход: там где это проще мы пользуемся исключениями. Но стараемся переходить на валидации как можно раньше (на более низких уровнях логики) для того чтобы высокоуровневая логика могла следовать букве ФП.
- Итак, код, совершающий много всякого ввода-вывода из сображений производительности и читабельности живёт с исключениями. интерфейсные методы небезопасных компонентов заворачиваются в специальные обёртки. Они перехватывают исключения и преобразуют их по определённым правилам в ошибки валидации. Правила задаются в одном месте глобально для всего приложения. Кстати при этом использовался стандартный пакет control.exceptions. Уровень сервисов и контроллеры оперируют более менее надёжными значениями, однако и они не застрахованы от выброса исключений. Для того чтобы обеспечить надёжную обработки и репортинг об ошибках не уровне лифта встроен дополнительный обработчик исключений, который делегирует всё к тому-же методу преобразования. На переходе между контроллерами и лифтом встроен код, который знает как из ошибок строить корректные с точки зрения HTTP ответы. В общем данная схема показала свою работоспособность. И более того устойчивость к отдельным нарушениям описанных соглашений (в том смысле, что отчёты об ошибках становятся менее точны, но не сводятся к метаю в пользователя стэктрейсами).
- Итак, каков наш опыт использования валидаций. Во-первых положительные моменты: 1. Более менее понятный способ аггрегации ошибок валидации. 2. Мало того это практически единственный способ который может работать в условиях нескольких десятков параметров с 2-3 ограничениями на каждый. 3. Также нам удолась выстроить достаточно унифицированный подход к рапортам об ошибках как во входящих параметрах, так и об ошибках времени выполнения. 4. Ну и корректность обработки ошибок проверяется автоматически компилятором. Из проблемных моментов можно выделить: 1. Монады и функторы требуют долгой медитации, которая не проходит бесследно для сознания. 2. Иногда бывает сложно найти общий язык с компилятором. 3. Ну и наиболее сложная для преодоления проблема...