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

Микросервисы сегодня являются достаточно «насмотренным» и «наслышанным подходом» среди корпоративных архитекторов. Возникает разумный вопрос: для рынка ERP — это модный тренд или необходимость? Попробуем вместе разобраться.

В данной статье я бы хотел поделиться наиболее значимыми аспектами использования микросервисов в контексте высоконагруженных распределенных тиражных систем управления ресурсами. Эти выводы сделаны на основе моего личного опыта работы с различными зарубежными и отечественными ERP, а также многолетней практики команды ТУРБО, в которой я возглавляю разработку решения ТУРБО ERP (входит в портфель ИТ-холдинга LANSOFT). Поговорим про подходы к созданию решений, эксплуатацию и работу с нагрузкой.

Большие нагрузки. Почему критична цельность ядра процессов?

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

Часть современных ERP возникла в 1990-е — начале 2000-х годов. Они имеют монолитную трехзвенную архитектуру. За счет применения различных решений с балансировкой нагрузки, с параллельными вычислениями эти системы справляются со всеми требованиями по производительности, стоящими перед программным обеспечением этого класса. Когда мы говорим про производительность, надо понимать, что есть два измерения: это количество пользователей, одновременно обращающихся к одним и тем же данным в системе, и задачи, требующие серьезных вычислений. Возможность горизонтального масштабирования, которой характеризуется трехзвенная архитектура, при наличии балансировщика нагрузки, а также применение распараллеливания вычислений позволяет достаточно неплохо масштабировать нагрузку по горизонтали, не имея ограничений на конкретный сервер приложений. Что же касается возможности параллельной работы большого количества пользователей, то эти требования в крупных ERP-системах решены как за счет достаточно хорошо продуманных механизмов взаимодействия с серверами СУБД, так и за счет выполнения большого числа одновременных операций с одними и теми же таблицами в базе данных.

Необходимо принять во внимание суть задач, решаемых ERP-системой. Она по определению управляет ресурсами предприятия. Это производственное оборудование, здания и сооружения, ТМЦ, денежные средства предприятия, рабочее время персонала и информация о продуктах и технологии их производства.

Именно применяя эти ресурсы в рамках цепочки основных процессов, компания создает добавленную стоимость. Следовательно, для решения задач управления ресурсами, необходимо автоматизировать учет, планирование, анализ отклонений. В случае с типичным производственным предприятием речь идет о цепочке процессов от создания заказа клиента через планирование потребностей в ресурсах к исполнению планов. Это включает закупки, производство как в целом на уровне предприятия, межцеховых планов, так и до уровня формирования цеховых заданий.

Так как мы решаем задачу управления, то важно как наличие планирования, так и точного оперативного учета потребления ресурсов в ходе выполнения этих планов. Как правило, данные задачи решаются в ERP-системах в блоках, на уровне которых происходит отражение перечисленных планов использования ресурсов и факта их потребления. Отсюда уже формируются все применяемые на предприятии виды учетов: управленческий, бухгалтерский, налоговый и прочие. Иными словами, потоки информации между различными модулями в рамках этого «ядра» основных процессов на предприятии будут максимальны. При этом стоит отметить и то, что так как управление возможно только здесь и сейчас (нельзя эффективно принимать решения по происходящим процессом выполнения заказа клиента, ориентируясь только на позавчерашние данные о его состоянии), то регистрируемые данные должны быть целостны и взаимно синхронизированы между различными процессами (и модулями ERP-системы их поддерживающими).

Таким образом, сама суть задач управления ресурсами требует очень тесного и быстрого взаимодействия и интеграции между основными видами регистрируемой информации по ресурсам предприятия. К такой информации относятся таблицы:

- движения запасов ТМЦ,
- отвечающие за отслеживание и выполнение заказов на производство, закупку или продажу,
- связанные с выполнением планов, то есть с расстановкой заказов и потреблением ресурсов, необходимых для выполнения этих заказов.

Монолитная система, функционирующая в единой СУБД, будет обеспечивать требуемую целостность именно благодаря своей архитектуре. В микросервисной концепции за данную целостность придется побороться, применяя различные, часто достаточно сложные, решения для ее поддержания. Стоит отметить, что в программном обеспечении с монолитной архитектурой эти максимально интенсивные потоки данных будут проходить между таблицами в одной СУБД. В системе же с микросервисной архитектурой они будут проходить между разными блоками и в общем случае между разными СУБД. При этом неизбежны сетевые задержки при передаче информации. Ошибки, вызванные рассинхронизацией данных, будут требовать ресурсов на их коррекцию. Все это приводит к уменьшению производительности системы, построенной на микросервисах, при работе на данных участках основных процессов предприятия.

Таким образом, когда мы говорим о задаче управления ресурсами предприятия, надо понимать, что целесообразно, чтобы значительная часть таблиц находилась в одном ядре и одной СУБД. Либо же мы должны будем смириться с временной рассинхронизацией данных или должны будем использовать иные методы для достижения синхронизации между соответствующими таблицами. Именно поэтому производители ERP-систем, несмотря на развитие микросервисных архитектур в последнее время, не отказываются от имеющейся архитектуры «ядра» своих систем.

Современные ERP-системы умеют работать с использованием множества одновременно работающих серверов предложений, их балансировщики умеют грамотно балансировать нагрузку между этими серверами, добиваясь того, что система может масштабироваться по горизонтали. Что же касается возможных ограничений производительности, связанных с блокировками на уровне таблиц СУБД, то здесь ситуация будет всегда одинаковая для всех микросервисных и монолитных архитектур. И там, и там наиболее простейшим и эффективным решением по поддержанию синхронизации данных в учетном ядре является размещение наиболее тесно связанных данных в таблицах одной СУБД. Таким образом, если СУБД сумеет справиться с этими нагрузками для микросервисной архитектуры, то для монолитной архитектуры она также сумеет поддержать необходимые требования системы.

Далее разберем эксплуатацию ERP и узнаем, какая модель может быть более выгодной.

Полную версию статьи можно получить по ссылке.

Автор: Михаил Аксенов, Директор по продукту ТУРБО ERP, «Консист Бизнес Групп».

Источник: TAdviser.

Больше новостей читайте в телеграм-канале SAPLAND: Новости экосистемы.