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

1. Эволюция архитектуры
многогранного Node.js
проекта

2. • Как жить в условиях работы с
большим количеством данных и
вычислений?
• Как можно организовать
самодокументацию и контракты?
• Важность выбора стека под задачу
• Как управлять техдолгом в условиях
миграции технологий
О чем поговорим?

3. Реалии типичного
стартапа
Высокий темп
разработки
Ограниченный бюджет
на поддержание
инфраструктуры
Маленькая команда
байдарки
мы работаем за еду,

4. А кто такой Koyfin, простите?

5. ПОЕХАЛИ!

6. MVP

7. ● MonoRepo архитектура
● База не справляется с
нагрузкой
● Блокировка Event Loop`a
● Server-side рендер

8. База данных
● Блокировка чтения записью из
множества источников
● Переполнение ОЗУ огромным
кол-вом индексов
● Нулевая отказоустойчивость

9. ● Вывести клиент в отдельное приложение
● Реплицировать базу данных (и станет хорошо)
● Наконец-то прикрутить eslint
● А что же с Event Loop?...
Sounds like a plan

10. Микросервисы

11. Просто разрежьте на логические
части
(для начала)

13. Как организовать?
1. Писать в БД может только один сервис
2. Поток записи данных должен быть
однонаправленный
3. Если кому-то нужны данные - выдаем права в БД
только на чтение

15. Новые проблемы...
● Большое количество микросервисов, которые общаются друг с другом
● Разный формат сообщений
● Нужно иметь возможность разрабатывать части системы параллельно
разными разработчиками

16. Необходимо договориться
Основная идея контрактного
программирования — это модель
взаимодействия элементов
программной системы, основывающаяся
на идее взаимных обязательств и
преимуществ. Как и в бизнесе, клиент и
поставщик действуют в соответствии с
определенным контрактом.
(Википедия)

17. «TypeScript - это JS для Jav’истов»
© Конфуций, 2018 год
Внедрение типизации

18. Тестирование идеи

19. Тестирование идеи
1. Пишем TypeScript интерфейсы для взаимодействия
между микросервисами

20. 1. Пишем TypeScript интерфейсы для взаимодействия
между микросервисами
1. Определяем типы переменных в функциях через
JSDoc блоки внутри JS кода
Тестирование идеи

22. 1. Пишем TypeScript интерфейсы для взаимодействия
между микросервисами
1. Определяем типы переменных через интерфейсы в
функциях через JSDoc блоки внутри JS кода
1. Ставим на precommit вызов TypeScript компилятора и
делаем его частью обязательных тестов для коммита
Тестирование идеи

24. Precommit Hook

25. Полный переход на TS

26. Полный переход на TS
1. Использование декораторов для краткости и
элегантности

27. Простая мемоизация

28. Простая мемоизация

29. Routing-controllers
● Декларативность
● Простота композиции
● Инъекция важных частей
запроса прямо в функцию
( User, Body, etc. )

30. Валидация

31. www.koyfin.com
if(usersSeesCapture() ===
){
alert(‘Похоже у
нас невалидные данные!’)
}
Первая версия валидации

32. Вторая версия валидации

34. JSON Schema:
83 строки

36. Полный переход на TS
• Использование декораторов для краткости и
элегантности
• Генерация схемы валидации (JSON schema) из TS
интерфейсов

37. TS Interface
20 строк
typescript-json-schema ./src/validation/tsconfig.json "*"
-o "./src/validation/validations.json"
--required=true
--strictNullChecks=true
--noExtraProps=true
--noExtraItems=true

38. ТЕХНИЧЕСКИЙ ДОЛГ?

39. 9999999
Давай, расскажи мне про миграцию на TS
MyCompany

40. Смешивание кода

41. “allowJs”: true - легкий путь к
“плавной” миграции

42. РАСЧЕТЫ

44. Подходы оптимизации
расчетов
● Precalculated data
● Мемоизация
● Логический кеш + Warm Up

45. ✚ Данные считаются на этапе записи в БД
Precalculated data

46. ✚ Данные считаются на этапе записи в БД
● процедуры + триггеры в БД
● логика при записи
● отдельные воркеры, которые по событию
или расписанию производят пересчет
Precalculated data

49. ✚ Данные считаются на этапе записи в БД
✚ Не нагружаем БД и мозг сложными запросами
✚ Отличная производительность
Precalculated data

50. ✖︎ При обнаружении ошибок в данных - нужно
проводить полный перерасчет производных
✖︎ Денормализация и дублирование
✖︎ Тяжело отслеживать место возникновения
ошибок в расчетах
Precalculated data

51. ✚ Данные считаются на лету
✚ При выявлении ошибок в расчетах или исходных
данных - достаточно просто сбросить кеш
✚ Неплохая производительность
Мемоизация

52. ✖︎ Все еще CPU-intensive задача
✖︎ Плохо работает для часто обновляемых данных
✖︎ Нужно думать о соблюдении порядка аргументов
Мемоизация

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

54. ✖︎ Занимает много места
✖︎ Нужно реализовывать логику под каждый кейс
✖︎ Нужно прогревать
Логический кеш

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

56. Рассмотрите типизированные языки для организации
контрактов обмена данными и написания более
самодокументированного кода
Выводы

57. Решайте проблемы на правильных уровнях.
Выводы

58. Техдолг не волк - в лес не убежит.
Используйте плавную миграцию и заботьтесь в
первую очередь о потребностях бизнеса.
Выводы

59. Всем крепких костылей!