Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Эволюция архитектуры
многогранного Node.js
проекта
• Как жить в условиях работы с
большим количеством данных и
вычислений?
• Как можно организовать
самодокументацию и контра...
Реалии типичного
стартапа
Высокий темп
разработки
Ограниченный бюджет
на поддержание
инфраструктуры
Маленькая команда
байд...
А кто такой Koyfin, простите?
ПОЕХАЛИ!
MVP
● MonoRepo архитектура
● База не справляется с
нагрузкой
● Блокировка Event Loop`a
● Server-side рендер
База данных
● Блокировка чтения записью из
множества источников
● Переполнение ОЗУ огромным
кол-вом индексов
● Нулевая отк...
● Вывести клиент в отдельное приложение
● Реплицировать базу данных (и станет хорошо)
● Наконец-то прикрутить eslint
● А ч...
Микросервисы
Просто разрежьте на логические
части
(для начала)
Как организовать?
1. Писать в БД может только один сервис
2. Поток записи данных должен быть
однонаправленный
3. Если кому...
Новые проблемы...
● Большое количество микросервисов, которые общаются друг с другом
● Разный формат сообщений
● Нужно име...
Необходимо договориться
Основная идея контрактного
программирования — это модель
взаимодействия элементов
программной сист...
«TypeScript - это JS для Jav’истов»
© Конфуций, 2018 год
Внедрение типизации
Тестирование идеи
Тестирование идеи
1. Пишем TypeScript интерфейсы для взаимодействия
между микросервисами
1. Пишем TypeScript интерфейсы для взаимодействия
между микросервисами
1. Определяем типы переменных в функциях через
JSDo...
1. Пишем TypeScript интерфейсы для взаимодействия
между микросервисами
1. Определяем типы переменных через интерфейсы в
фу...
Precommit Hook
Полный переход на TS
Полный переход на TS
1. Использование декораторов для краткости и
элегантности
Простая мемоизация
Простая мемоизация
Routing-controllers
● Декларативность
● Простота композиции
● Инъекция важных частей
запроса прямо в функцию
( User, Body,...
Валидация
www.koyfin.com
if(usersSeesCapture() ===
){
alert(‘Похоже у
нас невалидные данные!’)
}
Первая версия валидации
Вторая версия валидации
JSON Schema:
83 строки
Полный переход на TS
• Использование декораторов для краткости и
элегантности
• Генерация схемы валидации (JSON schema) из...
TS Interface
20 строк
typescript-json-schema ./src/validation/tsconfig.json "*"
-o "./src/validation/validations.json"
--r...
ТЕХНИЧЕСКИЙ ДОЛГ?
9999999
Давай, расскажи мне про миграцию на TS
MyCompany
Смешивание кода
“allowJs”: true - легкий путь к
“плавной” миграции
РАСЧЕТЫ
Подходы оптимизации
расчетов
● Precalculated data
● Мемоизация
● Логический кеш + Warm Up
✚ Данные считаются на этапе записи в БД
Precalculated data
✚ Данные считаются на этапе записи в БД
● процедуры + триггеры в БД
● логика при записи
● отдельные воркеры, которые по со...
✚ Данные считаются на этапе записи в БД
✚ Не нагружаем БД и мозг сложными запросами
✚ Отличная производительность
Precalcu...
✖︎ При обнаружении ошибок в данных - нужно
проводить полный перерасчет производных
✖︎ Денормализация и дублирование
✖︎ Тяж...
✚ Данные считаются на лету
✚ При выявлении ошибок в расчетах или исходных
данных - достаточно просто сбросить кеш
✚ Неплох...
✖︎ Все еще CPU-intensive задача
✖︎ Плохо работает для часто обновляемых данных
✖︎ Нужно думать о соблюдении порядка аргуме...
✚ Данные считаются на лету
✚ Кеш проще переиспользовать, чем при
мемоизации
✚ Простая инвалидация при обновлении исходных
...
✖︎ Занимает много места
✖︎ Нужно реализовывать логику под каждый кейс
✖︎ Нужно прогревать
Логический кеш
В условиях работы с большим количеством данных вы
можете разделять логику вычислений по разным слоям
инфраструктуры и испо...
Рассмотрите типизированные языки для организации
контрактов обмена данными и написания более
самодокументированного кода
В...
Решайте проблемы на правильных уровнях.
Выводы
Техдолг не волк - в лес не убежит.
Используйте плавную миграцию и заботьтесь в
первую очередь о потребностях бизнеса.
Выво...
Всем крепких костылей!
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта
Upcoming SlideShare
Loading in …5
×

JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта

39 views

Published on

За 3 года существования, “Koyfin” претерпел множество изменений.
Проект прошел путь от MVP до сложной системы сбора и обработки большого количества финансовых данных с десятками микросервисов и тоннами логики. Как жить, когда проект содержит огромное количество репозиториев, микросервисы отправляют и читают из шины тысячи разношерстных сообщений в минуту и кажется, что от попыток за всем уследить скоро взорвется голова? Как поддерживать консистентность, скорость, отказоустойчивость и при этом сохранять гибкость?
Мы рассмотрим с Вами основные проблемы, с которыми мы столкнулись, и поделимся результатами творческих мук в поиске их решения. Расскажем об инструментах и техниках, которые помогают нам каждый день

Published in: Education
  • Be the first to comment

  • Be the first to like this

JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогранного Node.js проекта

  1. 1. Эволюция архитектуры многогранного Node.js проекта
  2. 2. • Как жить в условиях работы с большим количеством данных и вычислений? • Как можно организовать самодокументацию и контракты? • Важность выбора стека под задачу • Как управлять техдолгом в условиях миграции технологий О чем поговорим?
  3. 3. Реалии типичного стартапа Высокий темп разработки Ограниченный бюджет на поддержание инфраструктуры Маленькая команда байдарки мы работаем за еду,
  4. 4. А кто такой Koyfin, простите?
  5. 5. ПОЕХАЛИ!
  6. 6. MVP
  7. 7. ● MonoRepo архитектура ● База не справляется с нагрузкой ● Блокировка Event Loop`a ● Server-side рендер
  8. 8. База данных ● Блокировка чтения записью из множества источников ● Переполнение ОЗУ огромным кол-вом индексов ● Нулевая отказоустойчивость
  9. 9. ● Вывести клиент в отдельное приложение ● Реплицировать базу данных (и станет хорошо) ● Наконец-то прикрутить eslint ● А что же с Event Loop?... Sounds like a plan
  10. 10. Микросервисы
  11. 11. Просто разрежьте на логические части (для начала)
  12. 12. Как организовать? 1. Писать в БД может только один сервис 2. Поток записи данных должен быть однонаправленный 3. Если кому-то нужны данные - выдаем права в БД только на чтение
  13. 13. Новые проблемы... ● Большое количество микросервисов, которые общаются друг с другом ● Разный формат сообщений ● Нужно иметь возможность разрабатывать части системы параллельно разными разработчиками
  14. 14. Необходимо договориться Основная идея контрактного программирования — это модель взаимодействия элементов программной системы, основывающаяся на идее взаимных обязательств и преимуществ. Как и в бизнесе, клиент и поставщик действуют в соответствии с определенным контрактом. (Википедия)
  15. 15. «TypeScript - это JS для Jav’истов» © Конфуций, 2018 год Внедрение типизации
  16. 16. Тестирование идеи
  17. 17. Тестирование идеи 1. Пишем TypeScript интерфейсы для взаимодействия между микросервисами
  18. 18. 1. Пишем TypeScript интерфейсы для взаимодействия между микросервисами 1. Определяем типы переменных в функциях через JSDoc блоки внутри JS кода Тестирование идеи
  19. 19. 1. Пишем TypeScript интерфейсы для взаимодействия между микросервисами 1. Определяем типы переменных через интерфейсы в функциях через JSDoc блоки внутри JS кода 1. Ставим на precommit вызов TypeScript компилятора и делаем его частью обязательных тестов для коммита Тестирование идеи
  20. 20. Precommit Hook
  21. 21. Полный переход на TS
  22. 22. Полный переход на TS 1. Использование декораторов для краткости и элегантности
  23. 23. Простая мемоизация
  24. 24. Простая мемоизация
  25. 25. Routing-controllers ● Декларативность ● Простота композиции ● Инъекция важных частей запроса прямо в функцию ( User, Body, etc. )
  26. 26. Валидация
  27. 27. www.koyfin.com if(usersSeesCapture() === ){ alert(‘Похоже у нас невалидные данные!’) } Первая версия валидации
  28. 28. Вторая версия валидации
  29. 29. JSON Schema: 83 строки
  30. 30. Полный переход на TS • Использование декораторов для краткости и элегантности • Генерация схемы валидации (JSON schema) из TS интерфейсов
  31. 31. TS Interface 20 строк typescript-json-schema ./src/validation/tsconfig.json "*" -o "./src/validation/validations.json" --required=true --strictNullChecks=true --noExtraProps=true --noExtraItems=true
  32. 32. ТЕХНИЧЕСКИЙ ДОЛГ?
  33. 33. 9999999 Давай, расскажи мне про миграцию на TS MyCompany
  34. 34. Смешивание кода
  35. 35. “allowJs”: true - легкий путь к “плавной” миграции
  36. 36. РАСЧЕТЫ
  37. 37. Подходы оптимизации расчетов ● Precalculated data ● Мемоизация ● Логический кеш + Warm Up
  38. 38. ✚ Данные считаются на этапе записи в БД Precalculated data
  39. 39. ✚ Данные считаются на этапе записи в БД ● процедуры + триггеры в БД ● логика при записи ● отдельные воркеры, которые по событию или расписанию производят пересчет Precalculated data
  40. 40. ✚ Данные считаются на этапе записи в БД ✚ Не нагружаем БД и мозг сложными запросами ✚ Отличная производительность Precalculated data
  41. 41. ✖︎ При обнаружении ошибок в данных - нужно проводить полный перерасчет производных ✖︎ Денормализация и дублирование ✖︎ Тяжело отслеживать место возникновения ошибок в расчетах Precalculated data
  42. 42. ✚ Данные считаются на лету ✚ При выявлении ошибок в расчетах или исходных данных - достаточно просто сбросить кеш ✚ Неплохая производительность Мемоизация
  43. 43. ✖︎ Все еще CPU-intensive задача ✖︎ Плохо работает для часто обновляемых данных ✖︎ Нужно думать о соблюдении порядка аргументов Мемоизация
  44. 44. ✚ Данные считаются на лету ✚ Кеш проще переиспользовать, чем при мемоизации ✚ Простая инвалидация при обновлении исходных данных ✚ Отлично подходит для постоянно обновляемых данных Логический кеш
  45. 45. ✖︎ Занимает много места ✖︎ Нужно реализовывать логику под каждый кейс ✖︎ Нужно прогревать Логический кеш
  46. 46. В условиях работы с большим количеством данных вы можете разделять логику вычислений по разным слоям инфраструктуры и использовать приемы мемоизации и кеширования результатов. Выводы
  47. 47. Рассмотрите типизированные языки для организации контрактов обмена данными и написания более самодокументированного кода Выводы
  48. 48. Решайте проблемы на правильных уровнях. Выводы
  49. 49. Техдолг не волк - в лес не убежит. Используйте плавную миграцию и заботьтесь в первую очередь о потребностях бизнеса. Выводы
  50. 50. Всем крепких костылей!

×