Как мы боролись за масштабируемость Docsvision (эпизод 1)

В предыдущей статье мы рассмотрели основные узкие места и способы масштабирования ECM систем. Сегодня я расскажу реальную историю развития платформы Docsvision — о проблемах, с которыми мы сталкивались, и о том, как мы их решали.

Эпизод 1 — Network Load Balancing, кластеризация сервера приложения и Stateless архитектура.

Когда мы начинали разработку системы в 1998 году, естественно, ни о каком масштабировании мы всерьез не задумывались. В 2001 году, когда стало понятно, что все, что мы написали за 3 года, нужно выкинуть в помойное ведро и начать писать заново — мы тоже не были особо озабочены вопросами масштабирования платформы, т.к. наш самый крупный проект тогда вряд ли насчитывал более 50 пользователей. Но, чтобы не переписывать все и второй раз, мы решили опираться на наиболее актуальные в то время тренды разработки приложений, а в тот момент это были технологии WEB-сервисов. Конечно, о полноценных WEB (HTML) клиентах для таких сложных бизнес-приложений тогда и мечтать не приходилось, но иметь возможность доступа к серверу из любой точки через Интернет, автоматически загружать приложения по URL-ссылке в браузер и иметь возможность пересылать URL ссылки на любой объект системы — будь это документ, задание, папка или конкретное представление — было весьма привлекательным. Для 2001 года это было революцией.

К счастью, к тому моменту Microsoft, платформа которой тогда стала стандартом разработки корпоративных решений, уже подготовил соответствующую инфраструктуру, которая включала несколько компонентов:

· возможность создания WEB-сервисов на сервере приложений, который был реализован в рамках IIS;

· SOAP Toolkit — инструментарий, упрощающий реализацию взаимодействия клиента и сервера XML сообщениями в процессе их взаимодействия.

В общем, с использованием этих инструментов реализовать поставленные выше задачи оказалось достаточно несложно, но также выяснилось, что архитектура WEB-сервисов позволяет реализовать механизм кластеризации сервера приложения. То есть IIS обеспечивает возможность распределения нагрузки между отдельными физическими серверами и возможность включения дополнительных серверов в пул по мере необходимости. Вы начинаете проект с подключения небольшого количества пользователей, покупаете не слишком производительный недорогой сервер — и вас все устраивает. Но по мере развития системы количество пользователей увеличивается, процессы становятся сложнее, сервер начинает захлебываться. Надо бы его заменить на более производительный и существенно более дорогой, но благодаря технологиям NLB (Network Loading Balancing) у вас появляется возможность не покупать более дорогой сервер на смену старому, а просто добавлять в пул еще один сервер необходимой мощности. Инфраструктура будет распределять между ними нагрузку в соответствии с их производительностью. Но это еще не все.

Особенность большего количества приложений СЭД/ECM в том, что пользователи обращаются к их функциям нерегулярно, например, по мере появления новых заданий, необходимости в согласовании, заполнении заявок или подготовки регулярной отчетности. И совершенно нет необходимости хранить контекст клиентской сессии на протяжении всего времени подключения пользователя к серверу. Если пользователь в течение какого-то времени не обращался к серверу, можно сохранить все его текущее окружение (состояние приложения) во временное хранилище и тем самым разгрузить сервер приложения, а в момент обращения восстановить контекст незаметно для пользователя, который продолжит работу с той точки, в которой он остановился какое-то время назад. Это позволяет существенно сократить требования к физическому оборудованию и соответственно обеспечить большую масштабируемость на тех же вычислительных мощностях.

Но для поддержки всех этих механизмов было необходимо реализовать сервер приложения Docsvision в так называемой Stateless архитектуре — реализации сервера без перманентного сохранения состояния окружения. К счастью, к тому моменту вся необходимая инфраструктура для реализации данных механизмов была готова, а наши разработчики обладали достаточной степенью креативности для того, чтобы реализовать такой на тот момент нетривиальный проект. И мы, первыми из Российских производителей систем данного класса, реализовали СЭД-систему как классический веб-сервис, обеспечивающий оптимальную кластеризацию слоя сервера приложения.

Кстати, этот способ разработки сегодня остается весьма актуальным — в частности, он используется в микро-сервисной архитектуре. Механизм поддерживается в Docsvision и сегодня, и не претерпел существенных изменений (а прошло уже почти 20 лет). Это избавило нас от проблем решения масштабирования слоя сервера приложения на протяжении всей истории коммерческого использования нашей платформы в решениях самого крупного масштаба.

К несчастью, сервер приложения — это не единственное место, где могут возникнуть проблемы с масштабированием. Но об этом в следующих эпизодах нашей саги..