Спецкурс Разработка серверов и серверных приложений лекция №1Eugeniy Tyumentcev
В 70-годах прошлого века в ИТ-отрасли сложилось стойкое убеждение, что будущее будет за многопроцессорными системами. Активно разрабатывались методы написания параллельных программ, в том числе и модель акторов Карла Хьюита. Однако все попытки создать многопроцессорную систему завершились провалом - полученные системы оказались дорогими и существенно не превосходили однопроцессорные системы. Самым известным провалом стал японский проект по разработке вычислительных машин 5-го поколения, на который было потрачено 500 млн. долларов. Причина заключается в законе Амдала, который устанавливает ограничения на увеличение производительности при распараллеливании программ. Кроме того, на рынке появилась компания Intel, которая сумела создать успешный однопоточный процессор и постепенно наращивать производительность своих процессоров. Это было время, когда программистам для ускорения своих программ не надо было делать ничего - достаточно дождаться более мощной версии процессора. Только спустя 30 лет, когда Intel уперлась в технологические проблемы наращивания производительности процессоров в лоб, интерес к параллельным технологиям опять возрос. Возникает резонный вопрос: этот интерес надолго или опять повторится история 70-х? В статье Герба Саттера 2005 года Бесплатного супа больше не будет: фундаментальный поворот к параллельности в программном обеспечении утверждается, что нет - больше не возврата к однопоточным программам, и программисты теперь будут вынуждены заботиться о параллельности...
Большие данные: как могут навредить и ка могут помочь?etyumentcev
Большие данные — модная и быстро распространяющаяся концепция, которая позволяет нам извлекать разные полезные факты из окружающей нас информации. На конкретных примерах покажу как можно большие данные использовать, а также к каким проблемам может привести неверная интерпретация полученных результатов.
Об опыте применения jsonb в реальных проектах. Выступление на PgConf.Russia 2016etyumentcev
В докладе описан опыт построения нагруженной отказоустойчивой системы, использующей jsonb для хранения данных. В частности рассказываются механизмы, которые заменили join, транзакции, в том числе распределенные, репликации обычных SQL баз данных.
От заката до рассвета | Максим Безуглый | Zlit TechZlit
Светлое будущее.
Карго-культ.
Деловые отношения между бизнесом и разработчиками.
Человеческие и профессиональные отношения между фронт и бек разработчиками
Спецкурс Разработка серверов и серверных приложений лекция №1Eugeniy Tyumentcev
В 70-годах прошлого века в ИТ-отрасли сложилось стойкое убеждение, что будущее будет за многопроцессорными системами. Активно разрабатывались методы написания параллельных программ, в том числе и модель акторов Карла Хьюита. Однако все попытки создать многопроцессорную систему завершились провалом - полученные системы оказались дорогими и существенно не превосходили однопроцессорные системы. Самым известным провалом стал японский проект по разработке вычислительных машин 5-го поколения, на который было потрачено 500 млн. долларов. Причина заключается в законе Амдала, который устанавливает ограничения на увеличение производительности при распараллеливании программ. Кроме того, на рынке появилась компания Intel, которая сумела создать успешный однопоточный процессор и постепенно наращивать производительность своих процессоров. Это было время, когда программистам для ускорения своих программ не надо было делать ничего - достаточно дождаться более мощной версии процессора. Только спустя 30 лет, когда Intel уперлась в технологические проблемы наращивания производительности процессоров в лоб, интерес к параллельным технологиям опять возрос. Возникает резонный вопрос: этот интерес надолго или опять повторится история 70-х? В статье Герба Саттера 2005 года Бесплатного супа больше не будет: фундаментальный поворот к параллельности в программном обеспечении утверждается, что нет - больше не возврата к однопоточным программам, и программисты теперь будут вынуждены заботиться о параллельности...
Большие данные: как могут навредить и ка могут помочь?etyumentcev
Большие данные — модная и быстро распространяющаяся концепция, которая позволяет нам извлекать разные полезные факты из окружающей нас информации. На конкретных примерах покажу как можно большие данные использовать, а также к каким проблемам может привести неверная интерпретация полученных результатов.
Об опыте применения jsonb в реальных проектах. Выступление на PgConf.Russia 2016etyumentcev
В докладе описан опыт построения нагруженной отказоустойчивой системы, использующей jsonb для хранения данных. В частности рассказываются механизмы, которые заменили join, транзакции, в том числе распределенные, репликации обычных SQL баз данных.
От заката до рассвета | Максим Безуглый | Zlit TechZlit
Светлое будущее.
Карго-культ.
Деловые отношения между бизнесом и разработчиками.
Человеческие и профессиональные отношения между фронт и бек разработчиками
SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенны...SECON
Набор практических приемов, которые позволяют создавать сложные многопоточные, параллельные, распределенные серверные приложения программистам без опыта сетевого и многопоточного программирования, работы с базами данных.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения ба...Badoo Development
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Javascript-фреймворки: должен остаться только один / Аверин Сергей (Acronis)Ontico
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенны...SECON
Набор практических приемов, которые позволяют создавать сложные многопоточные, параллельные, распределенные серверные приложения программистам без опыта сетевого и многопоточного программирования, работы с базами данных.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения ба...Badoo Development
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Javascript-фреймворки: должен остаться только один / Аверин Сергей (Acronis)Ontico
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Mobile Monday Kiev#1 - How to save time in Mobile Apps DevelopmentIntersog
Intersog acted as a general partner of relaunched Mobile Monday (MoMo) event in Ukraine that took place in Kyiv on June 25, 2015. See the top moments from Mobile Monday Kyiv #1!
MoMo is a global platform for IT knowledge sharing and professional networking that is currently being active in 140+ cities worldwide. MoMo offers different networking formats aimed to enhance public knowledge of the most trending mobility topics and innovation. Read more and join Mobile Monday: http://intersog.com/news/intersog-helps-relaunch-mobile-monday-ukraine/
Разработка портируемой инфраструктуры New Relic — контейнеры, CoreOS и прочие...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/2897.html
Нашей группе было поручено создать новый самостоятельный “регион” для всех продуктов New Relic, предназначенный для обслуживания европейских клиентов, подпадающих под ограничения GDPR. Здесь следует отметить, что так как наша компания предоставляла свои услуги исключительно через “облако” (SaaS), то хорошо выработанных процессов для настройки всей инфраструктуры “с нуля” у нас не было.
...
Юрий Василевский «Автоматизация в XCode»
Yandex Mobile Camp в Санкт-Петербурге 2012
http://events.yandex.ru/events/yamobcamp/spb-may-2012/
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач. Мы обсудим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
Yandex Mobile Camp в Санкт-Петербурге, 30 мая 2012
Юрий Василевский, ведущий разработчик EPAM Systems, Mobile Solutions
Тема: Автоматизация в XCode
Тезисы:
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач.
Мы рассмотрим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
Методики управления развитием ис на базе 1сHelen Kopteva
Данная презентация была представлена в ходе вебинара "Методики управления развитием ИС на базе 1С. СППР как возможный инструмент поддержки данных методик". Ведущий - Олег Демиденко, руководитель отдела внедрения, руководитель проектов компания "Кодерлайн".
В данном докладе мы рассмотрим пять основных принципов дизайна классов в объектно-ориентированном проектировании, которые известны, как принципы SOLID. А также как обеспечить достаточный уровень гибкости, связанности, управляемости, стабильности и понятности кода.
Лучшие практики корпоративной разработки. Лекция 0: обзор курса.Vadim Martynov
Это настоящий курс молодого бойца по коммерческой разработке ПО в компаниях и распределённых командах.В рамках курса слушатели приобретут навыки по участию в командной разработке, взаимодействию с аналитиками, заказчиком, менеджером и отделом тестирования, совместной работой с кодом, пониманию особенностей построения высоконагруженных систем, анализу качества продукта и автоматизации тестирования.
В докладе описываются основные проблемы, которые возникают при разработке проектов, и демонстрируется, что эти проблемы можно предсказать и решать с помощью математической теории, лежащей в основе языков программирования.
Дается математическое обоснование S.O.L.I.D принципов с помощью логики Хоара, из которого следует, что S.O.L.I.D верны не только для ООП, но и для статического полиморфизма, но и для императивного программирования вообще.
разработка серверов и серверных приложений лекция №4etyumentcev
В данной лекции рассмотрена минимальная реализация акторной модели, включающая
- отправку сообщений,
- создание новых акторов и смену поведения для приема следующего сообщения.
Исходный код реализации выложен на https://github.com/hwdtech/HWdTech.DS. Код на C#.
При разработке использовались библиотеки: Autofac, NuUnit, Moq
разработка серверов и серверных приложений лекция №3etyumentcev
В третьей главе рассматриваются базовые свойства акторов, описанные в PhD диссертации Gul Agha: каждый актор имеет адрес, большой почтовый ящик, куда доставляются сообщения, адресованные актору и поведение. В ответ на входящее сообщение актор может отправить конечный набор сообщений другим акторам и/или создать конечное число новых акторов и/или поменять свое поведение для обработки следующего сообщения.
В рамках данного курса будет разработана библиотека для разработки параллельных приложений на платформе .NET, построенная по модели акторов.
Исходные коды библиотеки будут выкладываться на GitHub: https://github.com/hwdtech/HWdTech.DS
Код библиотеки будет разработан с использованием следующих принципов, приемов и методик:
S.O.L.I.D. - принципы
Unit-tests
Mock
IoC контейнеры
Для удобства слушателей курса краткий обзор данных практик приведен в Главе 4.
разработка серверов и серверных приложений лекция №2etyumentcev
Причины потерь процессорного времени при организации последовательности вычислений внутри потока: 1. Ожидание ответа на запрос (поток спит). 2. Выполнение дополнительных "лишних" действий. Как способ устранения этих потерь - паттерн Пул потоков. Анализ императивного и функционального подхода к борьбе с "жадными" операциями. Эволюция методов организации параллельных вычислений на основе пула потоков.
высокопроизводиетльные системы без доп затратetyumentcev
Нами был разработана библиотека HWdTech.DS для разработки многопоточных и распределенных приложений на платформе .Net. Эта библиотека использует модель акторов и позволяет существенно снизить требования к квалификации программистов при построении высоконагруженных приложений.
Приводится объяснение, почему для программистов не подходят системы тайм-менеджмента. Презентация шла как сопровождение к устному выступлению, поэтому сама по себе без записи доклада, возможно, будет непонятна.
1. Как жить в согласии с SOLID?
Евгений Тюменцев
HWdTech, LLC
hwdtech.ru
11-я конференция .NET разработчиков
31 октября 2015
dotnetconf.ru
2. 2
Особенности разработки ПО
Чем больше размер проекта, тем
медленнее работают
программисты.
На графике пунктирная линия –
трудозатраты, если бы скорость
работы была постоянной, а
сплошная – реальные
трудозатраты.
Фредерик Брукс, «Мифический человеко-месяц»
3. 3
Если сравнить программиста и каменщика
Предположим, что
каменщик кладет один
кирпич за 5 минут. Тогда он
первый и тысячный
кирпичи уложит за 5 минут.
Программист же первый
кирпич кладет за 5 минут, а
тысячный почему-то за 100
часов!
4. 4
Почему так получается у программистов?
Программисты перед тем, как
сделать что-то новое, вносят
изменения в уже написанный
код, структуру базы данных.
Во-первых, нужно еще найти это
место, куда внести изменения, а,
во-вторых, убедиться, что новые
правки не сломали то, что уже
работало.
Это как, если бы строители,
перед тем как построить
очередной этаж, сначала ломали
и перестраивали все
предыдущие.
5. 5
• Сроки нарушаются
• Требуется все больше разработчиков
• Быстрее переписать, чем продолжать
6. 6
Логика Хоара
1969 г. An Axiomatic Basis for
Computer Programming
1971 г. Procedures and Parameters:
An Axiomatic Approach
1980 г. премия Тьюринга
1990 г. Медаль “Пионер
компьютерной техники”
2000 г. рыцарский титул за заслуги
в области образования и
компьютерной техники, премия
Киото
Чарльз Хоар
7. 7
Факты о логике Хоара
Система аксиом, содержащая if и while
полна
При добавлении новой конструкции в язык,
существующие аксиомы для goto делают
логику противоречивой.
8. 8
Факты о логике Хоара
Если использовать
1. статическое связывание
2. Рекурсию
3. Вложенные процедуры
4. Процедуры, принимающие в качестве
параметров процедуры.
5. Глобальные переменные
то не существует полной системы аксиом.
9. 9
Логика Хоара часто противоречива
⊢ 𝐿 𝞿 и ⊢ 𝐿 `𝞿
Значит, что любое изменение в коде надо
тестировать!
14. 14
Что делать?
Итерации
Низкая степень связности
Небольшая вложенность процедур
Модульное тестирование
Рефакторинг
Planning poker
Agile
Хорошо определенные требования
17. 17
Если SOLID, то, скорее всего, нельзя
switch
enum
Приведение типов
new
18. 18
Процессоры уже не те!
• Рост производительности одного
ядра процессора остановился!
• Рост производительности
приложений теперь должен
обеспечиваться за счет активного
использования многоядерности.
Herb Sutter, 2005 The Free Lunch Is Over A
Fundamental Turn Toward Concurrency in Software
“The bad news is that, at least in the short term, the
growth will come mostly in directions that do not take
most current applications along for their customary
free ride.
21. 21
Один формат для всех данных
• Все данные хранятся в виде JSON в реляционной БД (не NoSQL
база). Почему реляционная – есть транзакции.
• Структура базы очень проста – всего 6 (!) запросов к БД.
• Всегда известно среднее время выполнения любого запроса (в том
числе полнотекстовых поисковых запросов). Поскольку запросы
фиксированы, то время их выполнения не зависит от квалификации
разработчика.
• Не нужно миграций вообще – одновременно можно хранить сразу
несколько версий одних данных (система будет корректно работать
со всеми версиями)
• Базу легко масштабировать и поддерживать скорость выполнения
запросов – достаточно выделить нужные записи в отдельную
коллекцию. Например, если у Вас объявления о продаже
автомобилей и из них половина – это Toyota, то их можно выделить в
отдельную коллекцию, или, наоборот, из-за ухода General Motors
количество продаваемых Chevrolet, Opel снизилось, то их можно
собрать в одну коллекцию. Это делается однажды написанными
процедурами и хорошо отлаженными слияния и разделения
коллекций, то есть участие программиста для этих операций не
требуется.
{
‘фамилия’: ‘Иванов’,
‘заказы’: [
{
‘дата’: ’01.09.2015’,
‘стоимость’: 2000
},
{
‘дата’: ’01.10.2015’,
‘стоимость’: 2000
}
]
}
22. 22
Интерфейс работы с данными
interface IObject
{
object getValue(string name);
void setValue(string name, object val);
}
class Field<T>
{
public Field(string name) {…}
public abstract T this[IObject o]
{
get;
set;
}
}
Генерация строго типизированных
оберток для IObject по интерфейсам
interface MyObj
{
int A
{
get;
}
string B
{
get;
set;
}
}
23. 23
Унификация обработчиков
Каждый обработчик принимает на
вход IObject
Как организовать связи между
обработчиками?
Нужно использовать оператор
расширения (см. доклад с 10
конференции DotNetConf)
Лучше всего подходит отправка
сообщений, так как она не требует,
чтобы оба обработчика
находились в одном адресном
пространстве
24. 24
Акторы – альтернатива многопоточности
Carl Hewitt,
Peter Bishop,
Richard Steiger
A Universal Modular ACTOR
Formalism for Artificial Intelligence
1973
25. 25
Что такое актор?
Актор – вычислительная
сущность, которая может
за один шаг
• Отправить конечное число
сообщений другим акторам
• Создать конечное число
акторов
• Выбрать поведение для
приема следующего
сообщения
26. 26
Многопоточность vs Акторы
Многопоточность больше всего
похожа на телефонию. Доступ к
ресурсу – телефонный звонок.
Адресат может быть занят или не
брать трубку – живая и мертвая
блокировки. Чтобы одновременно
принимать много звонков, в
телефонии используют офисные
АТС – объекты синхронизации.
Акторы похожи на почтовую систему.
Чтобы выполнить какое-либо действие
актор посылает сообщение – письмо
адресату, и дальше занимается своими
делами. Не нужно никаких блокировок
вообще, можно послать много
сообщений за 1 раз, но нет гарантий,
что каждое сообщение будет
доставлено адресату.
27. 27
Почему своя реализация акторов, а не, например,
Erlang, Scala и т.д.?
• У нас низкий порог вхождения – разработчики
без опыта работы – надо знать только чистый
Java без Framework’ов.
• Erlang не подходит для длительных вычислений
(типичная ситуация, когда при решении
многопоточных задач Erlang проигрывает в
скорости – см., например, рис. справа 18,19 место
и проигрыш в ~20 раз!)
• Подход Scala (без инверсии зависимостей –
Philipp Haler, Martin Odersky, 2006 Event-Based
Programming Without Inversion Control)
заставляет разработчика самого задумываться о
распараллеливании задач в коде, то есть
требуется наличие хорошего опыта
• Мы предлагаем решения в акторах, которых нет
ни на одной платформе (речь пойдет далее)
28. 28
Архитектура
Каждый актор запущен внутри некоторого процесса – Node. Каждый актор
подключен к одному или нескольким каналам шины сообщений – MessageBus.
Чтобы отправить сообщение актору, надо его опубликовать в соответствующем
канале.
29. 29
Маршруты сообщений
• Акторную модель можно представить в
виде графа, где каждая вершина – это
актор, а стрелка показывает, что один
актор (основание стрелки) посылает
сообщение другому актору (конец
стрелки)
• Маршрут сообщения – это путь в графе,
которое проходит сообщение от
момента создания до завершения
обработки.
• Обычно, информация о том, кому
посылать сообщение зафиксирована в
исходном коде актора.
• Это требует модификации актора и,
соответственно, обновления сервера,
каждый раз, когда нам необходимо
внести изменения в соответствующий
алгоритм (например, в
запрограммированный бизнес-процесс)
30. 30
Управление маршрутами без программиста
• Наше решение предлагает вынести
информацию об адресатах сообщений
за пределы актора, так чтобы он ничего
не знал о следующих акторах
маршрута.
• В таком случае акторы можно легко
компоновать в любых сочетаниях для
реализации сложных операций.
• Маршруты формируются динамически,
так что их можно менять без
обновлений и перезагрузки сервера.
• Изменение маршрута может проходить
без участия программиста.
Программисты нужны только для
разработки новых акторов.
31. 31
Контрольные точки
• При поступлении запроса
(сообщение) от пользователя, при
прохождении через контрольную
точку сообщение сохраняется как
есть в базе данных.
• Дальше сообщение отправляется по
маршруту
• Если в результате сбоя в работе
какого-либо актора, запрос в данный
момент не может быть выполнен, то
благодаря тому, что все данные
сохранены в контрольной точке, мы
можем исправить ошибку и
повторить операцию без
дополнительных действий со
стороны пользователя.
Контрольная точка
сохраняет в БД входящее
сообщение как есть
Конечная точка маршрута
сообщения
32. 32
Преимущества контрольных точек
• Можно ответить пользователю раньше, чем
завершится обработка операции, что
уменьшает время отклика (ответ значит не
то, что операция завершена, а то, что
успешно принята заявка на выполнение
операции – в большинстве случаев этого
достаточно, как например, в платежном
терминале)
• Пользователь не видит, что внутри нашей
системы могут проблемы – для него система
всегда работает правильно – ошибка
выражается лишь в увеличении времени
обработки операции
• Можно использовать несколько
контрольных точек в одном маршруте,
чтобы уменьшить объем работы в случае
сбоя
• Не теряется информация от внешних систем,
например, платежных, в случае сбоя в
нашей системе – данные от внешних систем
сохранятся в некоторой контрольной точке
Контрольная точка сохраняет в
БД входящее сообщение как
естьвходящий
запрос
ответ
33. 33
Библиотека акторов
Актор имеет имя и версию. Чтобы система
стала использовать актор, разработчик обязан
опубликовать его в библиотеке акторов. Ни
один актор не потеряется, а библиотека будет
хранить информацию обо всех акторах,
которые когда либо были в нашей системе, а
также о тех, кто их опубликовал! Исключается
человеческий фактор при деплое на сервера,
обеспечивается безопасность.
34. 34
Библиотека конфигураций
• Структура каждого сервера описывается
JSON
• Все конфигурации с версиями хранятся в
библиотеке конфигураций
• Чтобы обновить конфигурацию на
сервере, ему посылается сообщение с
идентификатором конфигурации
• Сервер обращается в библиотеку
конфигураций и получает требуемую
конфигурацию
• При необходимости сервер сам
выкачивает из библиотеки акторов
требуемые конфигурацией акторы
{
‘actors’: [{
‘name’: ‘emailSender’,
‘smtp’: …,
},
{
‘name’: ‘dailyReport’,
…
}
‘messagePaths’: [{
‘name’: ‘newAd’,
…
}],
‘enpoints’: […]
}
35. 35
Преимущества библиотеки
конфигураций
• Быстро клонировать сервера – достаточно
установить нашу библиотеку (скопировать
файлы) и послать сообщение с необходимой
конфигурацией
• Автоматический деплой – надо только написать
конфигурационный файл
• Можно выставлять время обновления
• Автоматический откат – если возникают ошибки
при инициализации сервера, то автоматически
откатываемся до старой конфигурации
• Ни одна конфигурация не теряется
• Можно иметь одновременно сервера, которые
работают с разными версиями данных,
например, если часть клиентов, которые
работают с Вами по API еще не перешла на
новую версию
{
‘actors’: [{
‘name’: ‘emailSender’,
‘smtp’: …,
},
{
‘name’: ‘dailyReport’,
…
}
‘messagePaths’: [{
‘name’: ‘newAd’,
…
}],
‘enpoints’: […]
}
36. 36
Методы обнаружения разладки
Используем мат.
статистику для
обнаружения и
исправления
ошибок. Акторы-
датчики измеряют
поведение системы,
потом эта
передается на вход
специальных
алгоритмов,
позволяющих
обнаруживать
ошибки на
работающей
системе без
программистов и
тестировщиков.
37. 37
Как узнать, что изменения дали
положительный эффект
Карта количества сообщений в контрольной точке
Рост числа сообщений говорит о возникновении систематической
ошибки, резкий спад – о том, что ошибка была устранена.
38. 38
Все ли пользователи
одинаково полезны
Обмен сообщениями между пользователями
Анализ аномальной активности показал, что появился
пользователь, который стал активно предлагать другим
переходить на ресурс-конкурент.
39. 39
Если коллеги не идут на
сотрудничество
Аргумент при общении со сторонними разработчиками
Один из клиентов предъявлял претензии, потому что его
разработчики (компания-аутсорсер) говорили, что проблема в
нас.
41. 41
Преимущества решения
• Масштабируемые приложения могут
строить разработчики с небольшим
опытом работы или вообще без
опыта
• Нет проблем с миграциями данных
• Методы объективного контроля
работоспособности всей системы, не
зависящие от программистов и
тестировщиков
• Быстрое клонирование и
развертывание серверов по
необходимости
• Возможность адаптации или правки
автоматизируемых бизнес-
процессов без участия
программистов.
42. 42
Существующие внедрения – портал
бесплатных объявлений и новостей
• Команда – 5 студентов без опыта
работы и филолог
• Среднее время открытия страницы
уменьшено с 4,5 с до 400 мс
• Количество ошибок по сравнению с
предыдущей версией уменьшилось в
1000 раз!
• Количество серверов уменьшено с 15
до 3!
• Объявление можно подавать
простым текстом вместо длинной
формы: “Двушка в Советском округе,
проспект Мира, 64, в районе ост.
Политех, 50/34/8, 3/5п, не требует
ремонта, санузел раздельный, хрущевка.”
43. 43
Существующие внедрения – платформа
для контекстной рекламы
• Требование – время отклика строго меньше 100 мс
• Попытки задействовать ElasticSearch, MongoDb и т.д. дают
в некоторых случаях 200 мс и больше
• Был написан актор, который хранит все критерии
рекламных компаний сразу в памяти.
• Получили время отклика 7-46 мс (сам поиск по структуре
в памяти < 1 мс)
• Для масштабирования система поддерживает работу с
несколькими экземплярами серверов
44. 44
Существующие внедрения –
кроссплатформенное приложение
• Приложение считает время по
каждой задаче программиста,
снимает скриншоты, мониторит
активность клавиатуры и мыши
• Интерфейс написан на HTML5 и CSS3
• Бизнес-логика написана на нашей
библиотеке
• Приложение работает без
изменений под Mac, Window, Linux
(кроме методов снятия скриншота и
логирования активности – это малая часть
– до 40 ч работы – по сравнению со всем
приложением)