Архитектура информационных систем КЭДО: просто о сложном

Основные виды архитектуры информационных систем

В погоне за нужным уровнем производительности системы эволюционировали.

Первые ИС представляли из себя монолитные приложения. В них вычисления выполнялись в один поток. Такой системе можно выделить только один процессор: насколько он быстрый и насколько много памяти в одном компьютере, настолько быстрой будет и система. Ускорять процессор и бесконечно добавлять память в одну машину не получится — достигается «потолок».

Когда поддерживается многопоточность вычислений в рамках одного приложения, можно использовать несколько процессоров одной вычислительной машины (компьютера). Но не несколько машин, ведь память всё равно будет одна. Много ресурсов приложение на сможет утилизировать, ограничение остается. Такими системы стали чуть позже.

Понятно, что с точки зрения оптимизации кадровых процессов, мало что получится сделать с помощью одной программы, которая «живет» в одном конкретном компьютере. Для исполнения сложных процессов потребовался переход на следующий этап —компьютерные сети.

Что если программу разделить на части и разные ее компоненты выполнять на нескольких компьютерах? Когда одной машины для системы мало, то уже сама структура ПО должна давать возможность работать на разных компьютерах. Части взаимодействуют между собой, вызывая функции друг друга и передавая данные. Действовать при этом они должны согласованно, иначе ничего не получится. Именно по такому принципу строятся современные информационные системы. При этом они также делятся на несколько видов.

Клиент-серверная архитектура

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

Сервер несет всю тяжесть вычислительной нагрузки, клиентам остается только получать ввод от пользователя и показывать ему результаты, полученные от сервера. «Общаются» сервер и клиенты, как правило, через компьютерные сети.

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

Трехзвенная архитектура

В трехзвенной архитектуре части системы разделяются на уровни:

• уровень хранения;
• средний, где обычно располагаются основные вычисления (бизнес-логика);
• верхний — прикладной уровень или уровень представления.

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

Трехзвенная архитектура оптимальна в плане соответствия требованиям безопасности. Уровень хранения (база данных) может находиться в самой защищенной части сети, доступ людей к ней сильно ограничен. Средний слой с бизнес-логикой реализует разграничение доступа, например по ролям, изолируя данные слоя хранения. Каждый пользователь имеет доступ только в пределах своей роли, а значит, никто не имеет доступа к данным полностью. Наконец, слой представления — это просто отображение того, что отфильтровал средний уровень.

Получается, в системах с трехзвенной архитектурой одни сотрудники отдела кадров могут заниматься отпусками, другие — командировками. За этим проследит сервер-приложение. Ответственность за конкретные задачи можно разделить между кадровыми специалистами по орг. структуре. Данные защищены, производительность системы растет.

Вертикальное и горизонтальное масштабирование

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

Например, в большой корпорации есть ОЦО, обслуживающий HR-процессы сотен подразделений со штатом в десятки тысяч сотрудников. Здесь производительность системы будет играть самую важную роль (особенно в «горячие» периоды, скажем, в ходе планирования отпусков). Цель ИТ-департамента — обеспечить непрерывность бизнес-процессов. Нужно подобрать подходящую архитектуру, которая даст возможность справиться с нагрузкой.

Самый простой вариант — добавить в сервер процессоров, памяти, быстрых дисков. Такой способ называется вертикальным масштабированием. Естественно, он имеет ограничения.

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

Здесь нужен «балансировщик» — диспетчер, который отправляет нагрузку на свободные (одинаковые) части по какому-то правилу. В качестве балансировщика может быть выделен один конкретный узел, либо в этой роли выступает какой-то из узлов.

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

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

Монолит обладает противоположными достоинствами и недостатками. Для настольного или мобильного приложения, которое будет использовать один человек, он вполне подходит, но таких приложений уже мало (калькулятор, офисный пакет, медиаплеер, простая несетевая игра). Большие многопользовательские системы (ERP, ECM, КЭДО), как правило, имеют сложные архитектуры.

Очевидно, чем современнее архитектура, тем более производительной будет система. Чему еще способствует распределенная структура и отлаженная взаимосвязь частей ИС?

1. Надежность информационных систем

Представим, что в системе что-то пошло не так — например, вышел из строя процессор.

Если перед нами приложение-монолит, всё просто: сломалось — система не работает. В случае с вертикальной архитектурой дела тоже обстоят не лучшим образом: выбыло звено в цепочке — система не может нормально функционировать.

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

Как правило, для надежности добавляют избыточность. Например, N — количество узлов, которое требуется в обычной ситуации для приемлемой производительности, N+1 — это один избыточный узел, 2N — двукратное дублирование. Бывает, что в системе 2N+1 узлов.

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

2. Простая разработка и поддержка

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

Таких правил довольно много: ESB, CORBA и другие. Распространен сервисный подход: каждая часть системы предоставляет другим частям какую-то услугу (сервис), например аутентифицирует пользователя, распознает и преобразует текстовые документы в разные форматы и так далее.

Архитектура может быть микросервисной: в этом случае каждый сервис выполняет только одну функцию. Его легко разрабатывать и модифицировать, не задевая другие сервисы: сделать это быстро, меньше вероятность допустить ошибки.

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

Если использовать микросервисы в больших системах, появляется «зоопарк» подчас разнородных частичек, которыми становится сложно управлять. Поэтому чаще разработчики придерживаются разумного подхода: отступают от правила «один сервис — одна функция» и объединяют реализацию нескольких взаимосвязанных функций в один сервис.

Если правила взаимодействия частей хорошо продуманы, то система, как программный продукт, быстро развивается, улучшается. Это большой плюс для пользователей.

3. Безопасность информационной системы

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

Золотой стандарт — трехзвенная архитектура. Уровень хранения — самый нижний и защищенный, средний уровень — обработки или бизнес-логики, и только клиентский уровень (пользовательского интерфейса) доступен пользователю. Отдельные части можно выносить в отдельные сегменты сети. Чтобы не допустить проникновения злоумышленника, между сегментами дополнительно можно поставить шлюзы безопасности — межсетевые экраны.

Еще одна дополнительная мера — организация «демилитаризованных зон». DMZ — это сегмент сети, который одним концом «смотрит» в открытую сеть, а другим — в закрытую.

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

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

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

Архитектура системы Directum HR Pro

Все лучшие наработки нашли свое отражение в комплексной системе для управления кадровыми процессами и документами в электронном формате Directum HR Pro. Она построена по принципу классической трехзвенной архитектуры с веб-приложением. База данных отделена от клиента слоем бизнес-логики, который регулирует доступ в зависимости от ролей или других условий. Также в структуру входят микросервисы для специфичной функциональности.

Особенность системы в том, что для кандидатов и работников организован «доступ снаружи» — с личных устройств. При этом интерфейс личного кабинета для работника максимально прост и понятен.

Дело в том, что если классический документооборот можно разместить в закрытый контур, то кадровый целесообразно предоставить работникам снаружи. А если стоит задача удаленного приема, то внешний доступ попросту обязателен. При этом необходима усиленная защита, поэтому в Directum HR Pro сервисы личного кабинета работника вынесены в отдельную платформу, которая находится в DMZ — для большей защищенности.