Каков наилучший способ беспроблемного увеличения параллелизма в Node.js-сервисе, который используется в продакшне? Это — вопрос, на который моей команде понадобилось ответить пару месяцев назад.
У нас запущено 4000 контейнеров Node (или «воркеров»), обеспечивающих работу нашего сервиса интеграции с банками. Сервис изначально был спроектирован так, что каждый воркер был рассчитан на обработку только одного запроса за раз. Это снижало воздействие на систему тех операций, которые могли неожиданно
заблокировать цикл событий и позволяло нам игнорировать различия в использовании ресурсов различными подобными операциями. Но, так как наши мощности были ограничены одновременным выполнением лишь 4000 запросов, система не могла достойно масштабироваться. Скорость выдачи ответов на большинство запросов зависела не от мощности оборудования, а от возможностей сети. Поэтому мы могли бы улучшить систему и снизить стоимость её поддержки в том случае, если бы нашли способ надёжной параллельной обработки запросов.
Занявшись исследованием этого вопроса, мы не смогли найти хорошего руководства, в котором речь шла бы о переходе от «отсутствия параллелизма» в сервисе Node.js к «высокому уровню параллелизма». В результате мы разработали собственную стратегию перехода, которая была основана на тщательном планировании, на хороших инструментах, на средствах мониторинга и на здоровой дозе отладки. В итоге нам удалось повысить уровень параллелизма нашей системы в 30 раз. Это эквивалентно снижению затрат на поддержку системы примерно на 300 тысяч долларов в год.
Данный материал посвящён рассказу о том, как мы увеличили производительность и эффективность наших Node.js-воркеров, и о том, что мы узнали, пройдя этот путь.
Управление состоянием — одна из важнейших задач, решаемых в разработке на React. Было создано множество инструментов в помощь разработчикам для решения этой задачи. Наиболее популярным инструментом является Redux — небольшая библиотека, созданная Дэном Абрамовым, и предназначенная помочь разработчикам использовать паттерн проектирования Flux в их приложениях. В этой статье мы разберем, действительно ли нам нужен Redux, и посмотрим, как мы можем заменить его более простым подходом, в основе которого лежат Observable и React Hooks. 
