CC BY
216
должны осуществляется постановка целей и задач управления рисками для каждого подразделения компании; оценка рисков; системная классификация рисков; формирование профиля рисков; разработка способов воздействия на риск; разработка программы управления рисками компании; координация деятельности подразделений по управлению рисками; контроль выполнения антирисковых программ; оценка эффективности управления рисками; корректирующие мероприятия; оперативные решения по отклонениям, формирование отчетности по рискам по всей компании в целом; мониторинг эффективности системы управления рисками; предложения по усовершенствованию системы. На третьем уровне (для функциональных подразделений кроме ОУР) проводится идентификация рисков; оценка рисков; разработка средств и приемов управления рисками в рамках ответственности; организация выполнения программы действий по снижению риска; оценка эффективности управления рисками на уровне подразделения; формирование отчетности по управлению рисками в рамках ответственности [2].
Организация интегрированной системы управления рисками на предприятии позволит вовремя идентифицировать риски, присущие специфике его деятельности, анализировать их природу и механизм реализации, производить оценку и ранжирование по группам, определяя соответствующие масштабу угрозы способы воздействия на риск; разрабатывать средства и приемы управления рисками, действия которых заранее программируются и кодифицируются в правилах и процедурах риск-менеджмента, а их эффективность оценивать и принимать решения о реализации риска либо вносить корректирующие изменения как в программу управления рисками, так и в систему управления рисками в целом.
Эксперты проанализировали эффективность ИСУР. В ходе обсуждения эксперты еще раз оценили удельный вес рисков и вероятность их проявления с учетом информации о предлагаемых изменениях в деятельности Компании. В результате уменьшилась суммарная балльная оценка приоритетности рисков, характеризующая риск-профиль исследуемого предприятия: в абсолютном выражении показатель совокупного риска снизился с 35,018 до 26,768 балла; в относительном выражении - на 23,6%.
Таким образом, предложен подход к практической реализации интегрированной системы риск-менеджмента с целью улучшения организации управления рисками на предприятии, который позволит снизить уровень колебаний финансовых показателей деятельности, повысит их определенность и эффективность корпоративного управления.
Список литературы / References
1. Говорова Е.С., Первушина Т.Л. Управление финансовыми рисками в нефтяной отрасли // Молодежь Сибири - науке России: материалы Междунар. науч.-практ. конф. Красноярск: СИБУП, 2011. С. 171-175.
2. Первушина Т.Л. Риски менеджмента: монография. Красноярск: Сиб-ГТУ, 2002.
3. Первушина Т.Л. Анализ рисков предприятий химико-лесного комплекса // Экономика и управление в современных условиях: материалы Междунар. науч.-практ. конф. Красноярск: СИБУП, 2013. С. 242-244.
4. Первушина Т.Л. Стратегия развития предприятия с учетом рисков // Экономика и управление народным хозяйством: сборник статей. Пенза: Приволжский Дом Знаний, 2016. С. 103-107.
5. Thompson А.А. Readings in strategic management. 3rd ed. Homewood. Boston. M.A.: BPI/Irvin, 1990.
ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С ПОМОЩЬЮ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ Осипов Д.Б. Email: Osipov641@scientifictext.ru
Осипов Дмитрий Борисович — бакалавр, кафедра вычислительной техники, Университет информационных технологий механики и оптики, г. Санкт-Петербург
Аннотация: микросервисная архитектура - это подход к созданию приложения, подразумевающий отказ от единой, монолитной структуры. То есть вместо того, чтобы исполнять все ограниченные контексты приложения на сервере с помощью внутрипроцессных взаимодействий, используется несколько небольших приложений, каждое из которых соответствует какому-то ограниченному контексту. В статье исследованы различные типы микросервисной архитектуры и способы их связи. Детально рассмотрены ключевые особенности применения микросервисной архитектуры, а также сформулированы рекомендации по использованию микросервисов при разработке программного обеспечения.
Ключевые слова: микросервисы, микросервисная архитектура, монолитная архитектура, разработка программного обеспечения, децентрализация данных.
DESIGNING SOFTWARE USING A MICRO-SERVICE ARCHITECTURE
Osipov D.B.
Osipov Dmitry Borisovich - Bachelor, DEPARTMENT OF COMPUTER ENGINEERING,
UNIVERSITY OF INFORMATION TECHNOLOGIES, MECHANICS AND OPTICS, SAINT-PETERSBURG
Abstract: microservice architecture is an approach to creating applications, meaning the rejection of a single, monolithic structure. That is, instead of executing all the limited contexts, using several small applications, each of which corresponds to some limited context. In the article various types of microservice architecture and ways of their connection are investigated. Interaction with the microservice in the development of software.
Keywords: micro services, micro service architecture, monolithic architecture, software development, data decentralization.
УДК 004.422.81
Введение.
С ростом объема кода и функциональности программного продукта, возникает необходимость управления сложностью приложения. Хорошо продуманная архитектура и правильное разбиение приложения на модули помогают справляться с поставленной задачей. Вариантом реализации архитектуры может быть монолитное приложение, когда вся или большая часть бизнес-задач имеет одну кодовую базу. Актуальным решением в настоящее время является построенное на микросервисах приложение, в котором общая бизнес-задача разбита на отдельные части, каждая из которых имеет отдельное приложение (микросервис) со своей кодовой базой.
Приложения с монолитной архитектурой.
При классическом подходе к разработке ПО, как правило, используется монолитная архитектура приложения, когда оно разрабатывается как единый блок. При разработке промышленных приложений, как правило, используется трехуровневая клиент-серверная архитектура. При таком подходе приложение состоит из трех основных частей: клиентская часть (тонкий клиент, предоставляющий весь функционал посредствам HTML страниц в браузере, написанных с использованием различных javascript библиотек или фреймворков), базы данных (БД), состоящей из множества таблиц в единой, как правило, реляционной системе управления базами данных (СУБД), и серверной части. Серверная часть приложения обрабатывает HTTP-запросы, выполняет бизнес-логику, получает и изменяет данные в БД, а также выбирает необходимые HTML страницы и данные для отображения и отправляет их в качестве HTTP-ответа клиенту (браузеру). Это серверная часть приложение представляет собой монолитную структуру, и любые изменения в ней требуют создание и развертывание новой версии данного приложения.
Монолитные сервера является естественным подходом к построению такого рода систем. На рисунке один представлена структурная схема монолитного блока.
Монолитный блок
Функиональный Блок №1 Функиональный Блок №2
Функиональный Блок №3 Функиональный Блок N94
Рис. 1. Структурная схема монолитного блока
Вся логика запроса обрабатывается в одном процессе [2, с. 164], позволяя разработчику использовать основные особенности языка, на котором разрабатывается данное приложение, а именно классы, функции, пространства имен и т.д. С некоторой осторожностью, такие приложения могут быть запущены и протестированы на рабочей машине разработчика, развернуты с
использованием конвейеров развертывания (deployment pipelines), чтобы гарантировать, что изменения должным образом протестированы и развернуты на «боевых» серверах. Горизонтальное масштабирование (рис. 2) монолитных приложений осуществляется с помощью запуска нескольких его экземпляров с использованием балансировщиков нагрузки.
Рис. 2. Структурная схема горизонтального приложения с монолитной архитектурой
Приложения с микросервисной архитектурой
Эти три главных недостатка привели к появлению микросервисного подхода при проектировании ПО. Микросервисы - это небольшие, автономные, совместно работающие сервисы [1, с. 23]. Микро-сервисная архитектура - это подход к разработке единого приложения, как набор небольших сервисов, каждый из которых запущен в собственном процессе (рис. 3), в то время как коммуникация с другими сервисами осуществляется с помощью каких-либо «легковесных» механизмов, например, с помощью HTTP. Эти сервисы разрабатываются с учетом бизнес-требований и независимо развертываются с помощью полностью автоматизированных механизмов развертывания.
Функиональный Функиональный
Блок №1 Блок №2
Функиональный Функиональный
Блок №3 Блок №4
Рис. 3. Структурная схема сервисов в приложении с микросервисной архитектурой
Помимо того, что сервисы независимо развертываются и масштабируются (рис. 4), каждый сервис также обеспечивает жесткую границу модуля, делая при этом возможным разработку сервисов с использованием разных языков программирования разными командами разработчиков [1, с. 27].
Рис. 4. Структурная схема горизонтального масштабирования приложения с микросервисной
архитектурой
Нельзя сказать, что существуют какие-либо формально определенные правила для разработки приложений с микросервисной архитектурой, однако далее будут рассмотрены наиболее важные, на мой взгляд, из них.
Создание компонентов через сервисы
Под компонентом подразумевается единица ПО, которая может быть независимо обновлена или заменена. Одной из основных причин использования сервисов как компонентов является то, что сервисы можно развертывать независимо. Это значит, что если имеется приложение, состоящее из нескольких компонентов (функциональных блоков) в одном процессе, то изменение любого отдельного компонента приводит к необходимости повторного развертывания всего приложения. Но если приложение декомпозировано на сколько сервисов, каждый из которых содержит один компонент (функциональный блок), то изменение одного из них не приводит к необходимости повторного развертывания всего приложения, а требует лишь развертывания измененного сервиса. Изменения сервиса могут изменить его интерфейсы, что затронет механизмы его взаимодействия с другими сервисами, однако цель хорошей архитектуры микросервиса - минимизировать такие кардинальные изменения [3].
Другим следствием использования микросервисов как компонентов является более явный компонентный интерфейс. Так как большинство языков программирования поддерживают определение публичного интерфейса только на уровне документирования, то инкапсуляция у компонента может быть нарушена, что приводит к слишком высокой связанности компонентов. Микросервисы позволяют избежать это посредствам использования удаленных вызовов, что в свою очередь также имеет свои недостатки, главным из которых является то, что такие вызовы являются более дорогостоящими, чем вызовы внутри процесса, что требует более тщательной проработке API у микросервисов.
Кроме того, как было отмечено ранее, поскольку при разработке микросервисов могут использоваться кардинально разные технологии, это снимает ограничение, накладываемые на классические команды разработчиков, участвующих в разработке приложений с монолитной архитектурой, позволяя балансировать человеческие ресурсы в зависимости от востребованности того или иного микросервиса.
Децентрализация
При разработке приложения с микросервисной архитектурой, все данные должны управляться децентрализованно. На абстрактном уровне это означает, что концептуальная модель хранения данных в разных развернутых вариантах системы не должна быть одинакова.
Помимо децентрализации функциональных блоков, микросервисы также децентрализуют решения в области хранения данных [5]. На рисунке 5 представлена структурная схема хранения данных в приложении с монолитной архитектурой.
Рис. 5. Структурная схема модели хранения данных в приложении с монолитной архитектурой
В то время, как в приложениях с монолитной архитектурой используют единую СУБД для целого приложения, в приложениях с микросервисной архитектурой предпочтительно, чтобы каждый микросервис взаимодействовал со своей собственной СУБД либо разные экземпляры сервиса использовали одинаковую СУБД (рис. 6).
Рис. 6. Структурная схема модели хранения данных в приложении с микросервисной архитектурой
Децентрализация ответственности за данные в рамках микросервисов имеет последствия при управлении обновлениями данных. Общий подход при работе с обновлениями заключается в использовании транзакций для того, чтобы гарантировать консистентность при обновлении нескольких ресурсов, однако такой подход налагает дополнительные временные связи, которые проблематично поддерживать для нескольких микросервисов, поэтому выбор средств для управления консистентностью является отдельной задачей для команд разработчиков.
Заключение
Активно развивающееся в последнее направление в разработке программного обеспечения, а именно разработка с применением микросервисной архитектуры, является очень перспективным для внедрения. Главными преимуществами такого решения, по сравнению с монолитной архитектурой, является экономия ресурсов, как человеческих и материальных - в процессе разработки, так и вычислительных - в процессе масштабирования. Однако стоит также учитывать сложности, которые возникают при применении микросервисов, главным образом связанные с усложнением механизмов транзакций, а также необходимостью внедрения систем для автоматизированного мониторинга и логирования работы приложения.
Список литературы / References
1. Ньюмен Сэм. Создание микросервисов. СПб.: Питер, 2016. 304 с.: ил. (Серия «Бестселлеры O'Reilly»).
2. Таненбаум Э., Стеен М. ван. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003. 877 с.: ил. (Серия «Классика computer science»).
3. Martinfowler. [Электронный ресурс]: Microservices. a definition of this new architectural term. Режим доступа: https://martinfowler.com/articles/microservices.html/ (дата обращения: 22.05.2018).
4. Хабрахабр. [Электронный ресурс]: Microsoft Azure - Azure Service Fabric и архитектура микросервисов. Режим доступа: https://habrahabr.ru/company/mailru/blog/320962/ (дата обращения: 06.05.2016).
5. MSDN Magazine Blog. [Электронный ресурс]: Архитектура микросервисов. Режим доступа: https://msdn.microsoft.com/ru-ru/magazine/mt595752.aspx/ (дата обращения: 22.05.2018).
СОВРЕМЕННЫЕ ИНТЕРАКТИВНЫЕ ВЕБ-ПРИЛОЖЕНИЯ -ПОСТРОЕНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА С REACT Бондаренко С.О. Email: Bondarenko641@scientifictext.ru
Бондаренко Сергей Олегович — студент, кафедра автоматизации обработки информации, Томский государственный университет радиоэлектроники и систем управления, г. Томск
Аннотация: обзор веб-технологии React от крупнейшей социальной сети в мире и одноименной компании Facebook. Мир Java Script в настоящее время находится в большой беспорядочности. Новые фреймворки всплывают ежедневно, разработчики не могут решить, какие инструменты лучше использовать, а создание пользовательских интерфейсов испытывает значительные изменения. К счастью, на помощь приходит «React от Facebook», обещающий новый подход к созданию пользовательских интерфейсов. Основная концепция React-а отдельные компоненты и их состояния. Разработка пользовательского интерфейса по этому принципу — это настоящее и будущее уровня, отвечающего за представление данных, и вы должны начать осваивать и применять это уже сейчас вместе с React. Ключевые слова: пользовательский интерфейс, веб-технологии, React.
MODERN INTERACTIVE WEB APPLICATIONS - BUILDING A USER INTERFACE USING THE REACT Bondarenko S.O.
Bondarenko Sergei Olegovich — Student, DEPARTMENT OF DATA PROCESSING AUTOMATION, TOMSK STATE UNIVERSITY OF CONTROL SYSTEMS AND RADIOELECTRONICS, TOMSK
Abstract: review of web technologies React from the largest social network in the world and the Facebook company of the same name. The world of Java Script is currently in great disorder. New frameworks pop up daily, developers can not decide which tools to use better, creating user interfaces is experiencing a change. Fortunately, "React from Facebook" comes to the rescue, promising a new approach to creating user interfaces. The main concept of the React is the individual components and their states. The development of a user interface by this principle is the present and future levels that are responsible for viewing data and you must begin to master and apply it now together. Keywords: user interface, web technology, React.
УДК 004.428.4
Мир Java Script в настоящее время находится в большой беспорядочности. Новые фреймворки всплывают ежедневно, разработчики не могут решить, какие инструменты лучше использовать, а создание пользовательских интерфейсов испытывает значительные изменения.
К счастью, на помощь приходит «React от Facebook», обещающий новый подход к созданию пользовательских интерфейсов.
React — эффективная и гибкая библиотека JavaScript для генерации динамических пользовательских интерфейсов. С марта 2013-го, React разработан и поддерживается Facebook-ом, который и сам использует React-компоненты на своих страницах. React также используют в
