Учебное пособие 2125

Асинхронный протокол - код клиента или отправитель сообщения обычно не ожидает ответа. В данном случае используются брокеры сообщений, например, RabbitMQ, ActiveMQ, Apache Kafka и другие. Асинхронный обмен сообщениями и взаимодействие, управляемое событиями, имеют важное значение при распространении изменений по многим микрослужбам и связанным с ними моделям доменов.

Рис. 2. Пример асинхронного взаимодействия

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

Преимущества MSA: 1) Модульность

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

2) Простота написания, отладки Писать и поддерживать небольшие сервисы всегда проще, чем большие.

Чем меньше кода, тем легче уместить его в голове. Упрощается тестирование, так как полностью покрыть тестами API одного сервиса не представляет большого труда. Можно с легкостью поставить заглушки на внешние сервисы.

3) Независимое развертывание Микросервисы позволяют по мере необходимости обновлять приложение

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

4) Доступность

130

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

5) Технологическое разнообразие С микросервисами легко смешивать языки программирования, среды

разработки и технологии хранения данных. 6) Горизонтальное масштабирование

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

Недостатки MSA: 1) Распределенность

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

2) Согласованность в конечном счете Для распределенной системы сложно поддерживать строгую

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

3) Сложность эксплуатации Для управления микросервисами, которые регулярно

переразвертываются, требуется зрелая группа эксплуатации/поддержки.

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

Литература

1. Sam Newman: Building Building Microservices // ИТ-архитектур. - 2016. - № 1. - С. 30-34.

ФГБОУ ВО «Воронежский государственный технический университет», Россия

131

УДК 004.89

Ю.В. Минаева

СТРУКТУРА ПОДСИСТЕМЫ ИНТЕЛЛЕКТУАЛИЗАЦИИ УПРАВЛЕНИЯ СЛОЖНЫМ МНОГОНОМЕНКЛАТУРНЫМ ПРОИЗВОДСТВОМ

Непрерывный рост количества и сложности изделий, выпускаемых производственными предприятиями, и регулярное появление продуктовых и технологических инноваций ведут к увеличению трудоемкости работ по конструкторско-технологическому обеспечению производства, что увеличивает объем инженерного труда и продолжительность работ по проектированию новых и модернизации функционирующих производственных систем. Существенное сокращение трудоемкости работ по конструкторскотехнологической подготовке производства и сроков постановки на производство новой и модернизированной продукции может быть достигнуто только за счет комплексного применения различных автоматизированных подсистем, входящих в состав автоматизированной системы управления предприятием (АСУП) [1].

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

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

Рассмотрим функции основных компонентов интеллектуальной подсистемы [1, 2].

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

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

-знания, содержащиеся в базе знаний;

-данные, поступающие из внешних подсистем;

-подсистема моделирования.

132

УДК 004.9:330

В.А. Алексютина, Ф.Ю. Лозбинев

АСПЕКТЫ АВТОМАТИЗАЦИИ ФУНКЦИОНИРОВАНИЯ МНОГОФУНКЦИОНАЛЬНЫХ ЦЕНТРОВ

ОКАЗАНИЯ ГОСУДАРСТВЕННЫХ И МУНИЦИПАЛЬНЫХ УСЛУГ НА ТЕРРИТОРИИ БРЯНСКОЙ ОБЛАСТИ

Многофункциональный центр предоставления государственных и муниципальных услуг – государственное или муниципальное учреждение, отвечающее требованиям, установленным Федеральным законодательством и Правительством Российской Федерации, уполномоченное на организацию предоставления государственных и муниципальных услуг по принципу «одного окна». По вопросу функционирования многофункциональных центров предоставления государственных и муниципальных услуг принято постановление Правительства Российской Федерации от 3 октября 2009 г. № 796 «О некоторых мерах по повышению качества предоставления государственных (муниципальных) услуг на базе многофункциональных центров предоставления государственных (муниципальных) услуг». До принятия федерального закона «Об общих принципах организации предоставления государственных и муниципальных услуг» организационноправовая форма, а также функции МФЦ установлены статьей 30 федерального закона от 15 декабря 2008 г. № 281-ФЗ. Основной идеей МФЦ является реализация принципа «одного окна», когда гражданин освобождается от необходимости получать справки, ходить по инстанциям или платить посредникам [2].

Предоставление услуг, предусматривающих межведомственное взаимодействие или обращение граждан в несколько ведомств, из-за отсутствия взаимодействия между соответствующими ведомственными информационными системами связано с большой потерей времени и длительными задержками, что создает значительные неудобства для граждан. Проблемы, препятствующие повышению эффективности использования инфокоммуникационных технологий в деятельности органов государственной власти, носят комплексный межведомственный характер и не могут быть решены на уровне отдельных органов государственной власти. Предполагалось, что МФЦ упростит процедуру получения всевозможных справок, жилищнокоммунальных субсидий, социальную помощь, возможность зарегистрировать приобретение и продажу квартиры можно будет в одном месте [3].

Споявлением МФЦ в регионах РФ существенно упростилась процедура,

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

134

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

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

Автоматизация работы МФЦ и получения госуслуг позволяет региональным органам государственной власти перейти на качественно новый уровень цифрового взаимодействия государства и граждан. Повышается качество предоставления госуслуг в электронном виде за счет исключения бумажного и существенного сокращения объемов электронного документооборота, а так же предоставления специалистам МФЦ автоматизированного доступа к необходимой информации [1].

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

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

Так же повышается оперативность и качество предоставления государственных и муниципальных услуг сотрудниками многофункциональных центров, следовательно, вместо прежних 30 минут, выделяемых для одного заявителя, время ожидание может сократиться до трех раз.

Стоит обратить внимание и на вид организационной модели многофункциональных центров. Нужно отметить, что централизованная модель является более совершенной, чем децентрализованная. Необходимо заниматься совершенствованием деятельности МФЦ, в том числе и путем перехода к централизованной модели. На данный момент в 28 субъектах Российской Федерации многофункциональные центры имеют децентрализованную модель, однако в соответствии с нормативными документами Минэкономразвития к 1 января 2020 года все они должны будут перейти к централизованной модели.

При создании и функционировании МФЦ на основе децентрализованной модели отдельные многофункциональные центры на территории субъекта Российской Федерации являются самостоятельными организациями. Каждый муниципальный район рассматривается отдельно, следовательно, могут существовать значимые различия МФЦ по организации предоставления и качеству услуг.

135

При переходе на централизованную модель головной МФЦ занимается координацией деятельности остальных центров и контролирует их деятельность. Тем самым создаются единые стандарты и требования для всех МФЦ региона.

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

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

Литература

1.Сафонов А.А. Теория экономического анализа: учеб. пособие / А.А. Сафонов. - Владивосток: Изд-во ВГУЭС, 2000. – С. 63.

2.Постановление Правительства РФ от 22.12.2012 г. № 1376 «Об утверждении Правил организации деятельности многофункциональных центров предоставления государственных и муниципальных услуг».

3.Постановление Правительства РФ от 28.01.2002 г. №65 «О федеральной целевой программе «Электронная Россия (2002-2010 годы)».

4.Электронный ресурс: Мои документы: http://gaumfc.ru/

5.Электронный ресурс: Госуслуги: https://www.gosuslugi.ru/

ФГБОУ ВО «Российская академия народного хозяйства и государственной службы при Президенте Российской Федерации», Брянский филиал, Россия

УДК 681.3

Е.Н. Королев, С.И. Короткевич, А.С. Богданова

ИСПОЛЬЗОВАНИЕ ETL СРЕДСТВ В РЕШЕНИИ ВОПРОСОВ ПО ВЫГРУЗКЕ ДАННЫХ В КОНЕЧНУЮ СИСТЕМУ

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

136

В данной научно-исследовательской работе рассматриваются такие вопросы: что такое ЕTLсредства, зачем они нужны, какими бывают и приведем примеры, где они используются.

Для начала, ответим на первый вопрос списка и разберем основные понятия, ETL – аббревиатура от Extract, Transform, Load (англ. Извлечь, Преобразовать, Загрузить). Это системы корпоративного класса, которые применяются, чтобы привести к одним справочникам и загрузить в DWH и EPM данные из нескольких разных учетных систем. DWH (англ. Data Warehouse - хранилище данных) – это специальная аналитическая база данных, предназначенная для подготовки аналитических отчетов или построения дальнейшей бизнес-аналитики. EPM (англ. Enterprise Performance Management -

Управление Производительностью Предприятия) – набор методов управления эффективностью компании. Из выше перечисленных определений можно вывести ответ, на второй вопрос данной работы: для чего нужны средства ETL.

Рассмотрим на примере работы условного предприятия, банка. В день банковская система обрабатывает колоссальный объем информации, такой как, денежные проводки, сверка и пересчет балансовых данных, сбор контрольной информации, составление контрольной отчетности. Весь ежедневный поток в банке оценивается терабайтами памяти. Огромное количество ресурсов тратится на накопление ресурсов в базе, на преобразование данных к единой системе хранения, отсеивание избыточных или дублирующихся записей и составление итоговой отчетности по свежему срезу данных для Центрального Банка. Безусловно, такие объемы работы не могут изначально находиться в едином виде, пригодном для дальнейшей трансформации, так как таким потоком внутри банка управляет далеко не одно подразделение. Ни одна система в мире не способна поддержать единообразие данных в такой системе от самого начала и до конца. Такой круговорот информации связан не только с банками, но и с любыми масштабными предприятиями, которым на помощь и приходят ETL средства, главной целью которых является привести все это разнообразие данных в однотипную систему. Кроме того, ETL средства решают такие вопросы, как нахождение ошибок в потоках информации, которые есть всегда по одной из двух причин:

1.Случайные ошибки, возникшие на уровне ввода, переноса данных, или из-за багов;

2.Различия в справочниках и детализации данных между смежными ИТ-системами;

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

1.Приведение всех данных к единой системе значений и детализации

иобеспечив их качество и надежность;

137

2. Обеспечить аудиторский след при преобразовании (Transform) данных, чтобы после преобразования можно было понять, из каких именно исходных данных и сумм собралась каждая строчка преобразованных данных;

Структура работы ETLсистем приведена на рисунке.

Процесс работы ETL систем

Кратко опишем каждый из подпроцессов:

1.Процесс загрузки – затянуть в ETL данные произвольного качества для дальнейшей обработки, на этом этапе важно сверить суммы пришедших строк, если в исходной системе больше строк, чем в контрольном срезе, то значит — загрузка прошла с ошибкой;

2.Процесс валидации данных – на этом этапе данные последовательно проверяются на корректность и полноту, составляется отчет об ошибках для исправления;

3.Процесс мэппинга данных с целевой моделью – на этом этапе к валидированной таблице пристраивается еще n-столбцов по количеству справочников целевой модели данных, а потом по таблицам мэппингов в каждой пристроенной ячейке, в каждой строке проставляются значения целевых справочников. Значения могут проставляться как 1:1, так и *:1, так и 1:* и *:*, для настройки последних двух вариантов используют формулы и скрипты мэппинга, реализованные в ETL-инструменте;

138

4.Процесс агрегации данных – этот процесс нужен из-за разности детализации данных в OLTP и OLAP системах. OLAP-системы — это, по сути, полностью денормализованная таблица фактов и окружающие ее таблицы справочников, максимальная детализация сумм OLAP – это количество перестановок всех элементов всех справочников. А OLTP система может содержать несколько сумм для одного и того же набора элементов справочников. Можно было-бы убивать OLTP-детализацию еще на входе в ETL, но тогда мы потеряли бы «аудиторский след». Этот след нужен для организации последнего под-процесса.

5.Процесс построения отчета по контрольному срезу данных, который показывает — из каких строк OLTP, сформировалась сумма в ячейке OLAP-системы. Поэтому сначала делается мэппинг на детализации OLTP, а потом в отдельной таблице данные «схлопывают» для загрузки в OLAP;

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

1.Объект загружается только из одной системы-источника;

2.Объект загружается из нескольких систем-источников, больше двух различных видов;

Для начала рассмотрим первый вариант загрузки: только из одной системы-источника. Этот случай является самым простым и наименее распространенным. Характеризуется полным соответствием между RKключами и внешними идентификаторами. Данный случай не вызывает конфликтов в использовании, так как чаще всего источниками такой загрузки являются внутренние таблицы БД (Базы Данных). А вот второй вариант вызывает множество сложностей в реализации.

При загрузке объекта из нескольких систем существует несколько вариантов, различных по сложности.

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

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

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

Для решения такой задачи устанавливается сложный дополнительный модуль дедупликации объектов.

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

139