
Highload-системы: от первых опытов до мейнстрима
Highload-системы: от первых опытов до мейнстрима
10.10.2024
#новости


Например, мы видели, как в конце нулевых-начале десятых активно развивают свои цифровые продукты телеком-компании и банки. В определенный момент такой гигант, как Сбербанк, провел ребрендинг и стал себя позиционировать как ИТ-компания, а не как банк. Параллельно с развитием таких крупных компаний менялся и их бизнес-подход. На начальных этапах они, чтобы не содержать в штате большие отделы, заказывали разработку конкретного продукта ИТ-аутсорсерам, специализирующимся на разработке ПО. Но в дальнейшем потребностей становилось все больше, и у таких компаний стали выделяться собственные, достаточно крупные ИТ-подразделения. Иногда внутренняя разработка даже выводилась из оргструктуры основной компании в отдельную дочернюю компанию. В то же время цифровизироваться начали и другие направления бизнеса: объявления из газет перенеслись на интернет-платформы, произошла цифровизация взаимоотношений гражданина и государства и появился всем известный портал Госуслуги, у Яндекса появились дополнительные популярные продукты – Карты, Такси и другие.
Это было время больших трансформаций и развития как с точки зрения бизнеса, так и с точки зрения технологий. Выше я привел примеры бизнес трансформаций, ниже сосредоточусь на примерах технических изменений, в которых мне самому приходилось участвовать.
В своей профессиональной деятельности с высокими нагрузками я столкнулся, работая в сфере телекома. Проект был связан с управлением маркетинговыми кампаниями. Он стартовал до моего прихода и показал себя эффективным с точки зрения бизнеса. Как результат, со временем у заказчика появлялось больше потребностей, и проект обрастал функционалом. Когда я начал им заниматься, это была классическая реляционная БД и веб-приложение, работающее на Java. На тот момент еще не было активного разделения на фронтенд и бекенд разработку. Через приложение можно было управлять маркетинговыми кампаниями, запускать нотификацию по ним. Но все это работало по расписанию на основе расчета профиля абонента.
В какой-то момент у заказчика появилось желание получить больше интерактива и перейти на событийное взаимодействие с абонентом. Например, если у абонента заканчивались деньги на счете, можно было послать ему SMS с предложением пополнить баланс или воспользоваться «обещанным платежом», если исчерпан лимит. Это выглядит как простой пример, но событий, которые генерируются абонентом, может быть достаточно много. И если помножить их на количество абонентов, в результате получалась достаточно высокая нагрузка. Обрабатывать такой поток данных в онлайн-режиме с использованием реляционной БД выглядело не реалистичным. Было решено кешировать данные в ОЗУ. На тот момент не было такого большого количества in-memory хранилищ и, недолго выбирая, мы пришли к Redis.
Подробнее по ссылке.