CC BY
35
УДК 004.41
Ольхов Д. А.
Магистрант, кафедра, прикладной математики и информатики институт математики, физики и информационных технологий Тольяттинский государственный университет, г. Тольятти
АНАЛИЗ ПОДХОДОВ К УПРАВЛЕНИЮ ПРИКЛАДНЫМ ПРОГРАММНЫМ ИНТЕРФЕЙСОМ
МИКРОСЕРВИСОВ В ОБЛАЧНОЙ СРЕДЕ
Аннотация
Статья рассматривает проблему и подходы к организации управления API в среде «облачных» технологий виртуализации и микросервисной архитектуры приложений.
Ключевые слова:
управление API, микросервисы, монолит, сетевая коммуникация, виртулизация.
Проблема управления API и разнообразные подходы к её решению получили свою актуальность и развитие с приходом технологий виртуализации и осознанием в потребности бизнеса в программных продуктах высокой надежности и доступности. Для разработчиков прикладного программного обеспечения эта проблема стала существовать вместе с развитием микросервисной архитектуры. Микросервисной архитектуре противопоставляется монолитная, и не просто так, ведь именно микросервисная архитектура пришла ей на смену, чтобы качественно решить возникшие потребности рынка ПО.
Чтобы лучше понять, чем являются микросервисы стоит рассмотреть архитектурные стили, используемые до появления микросервисов и то, как архитектура корпоративных приложений эволюционировала в микросервисную. Лучший способ понять ключевые моменты и характеристики микросервисов это детально рассмотреть эволюцию архитектур корпоративных систем из монолитных приложений в микросервисы.
Программные приложения уровня предприятия проектируются чтобы облегчить реализацию многочисленных бизнес требований. [3] В архитектуре монолита все бизнес функциональности собраны внутри одного монолитного приложения и упакованы в один единственный модуль. Чтобы улучшить понимание приведем реальный пример монолитного приложения, выберем в этом качестве интернет-магазин (см. Рисунок 1)
Onüitie F.tiaiJ Application
Рисунок 1 - Приложение интернет-магазина, разработанное в монолитной архитектуре
В целом интернет-магазин представляет собой набор нескольких компонентов, таких как управление заказами, платежи, управление продуктом и так далее. Каждый из этих компонентов предлагает широкий набор бизнес-функций. Добавление или модификация функциональных возможностей в компонент очень дорого из-за его монолитной природы. Также, чтобы покрыть все бизнес требования эти компоненты должны обмениваться между собой данными. Коммуникация между компонента часто строится на проприетарных протоколах и стандартах и основаны на схеме взаимодействия точка-точка. Поэтому изменение или замена данного компонента также связано с большими трудностями. Для примера если магазин хотел бы использовать другую систему управления заказами, то осуществление такого требования понесло за собой огромное количество изменений в нескольких существующих компонентах. Подытожим основные характеристики монолитных приложений:
проектируются, реализуются и разворачиваются как единственный модуль/пакет;
подавляющая сложность реализаций большинства реальных бизнес сценариев, что превращает обслуживание, обновление и добавление новых функций в ночной кошмар.
С трудом подходит для практики методологий гибкой разработки и доставки приложений заказчику. Так как приложение собирается в один большой модуль, то большинство бизнес-функций не имеет своего выделенного жизненного цикла.
С ростом монолитного приложения растет время его запуска и стоимость такого запуска.
Один нестабильный сервис может вывести из строя все приложение.
В случае необходимость может быть масштабирован только как полноценное приложение (нет возможности сделать это по частям), что сделать сложно в случаях неоднородного требования компонентов к ресурсам. Например, одна бизнес функциональность требует больше времени CPU, в то время как другой необходимо больше памяти. В таком случае очень сложно удовлетворить индивидуальные потребности каждого компонента.
—миграция на новые технологии и библиотеки затруднительна, так как монолитная структура подразумевает использование единой технологии.
В качестве решения некоторых из ограничений монолитной архитектуры приложений появилась «Сервисно-ориентированная архитектура» (Service Oriented Architecture, SOA) и «Сервисная шина предприятия» (Enterprise Service Bus, ESB)
Сервисно-ориентированная архитектура была создана чтобы справиться с проблемами монолитных приложений путем разделения функциональностей монолитного приложения на переиспользуемые и слабо связанные сущности, называемые сервисами. Доступ к каждому из сервисов осуществляется посредством вызовов через сеть.
Сервис - это автономная реализация четко описанного бизнес функционала, которая доступна по сети. Приложения в сервисно-ориентированной архитектуре основаны на сервисах.
Сервисы являются частью приложения с детерминированными интерфейсами, не зависящими от реализации. Четкое разделение интерфейсов сервисов от их реализации является важным аспектом сервисно-ориентированной архитектуры.
Потребителям важен только интерфейс сервиса, но не его реализация.
Сервисы автономны (и выполняют заранее определенные задачи) и слабо связаны.
Сервисы могут быть обнаружены динамически. Потребителям часто не нужно знать местоположение и другие детали о сервисе. Метаданные о сервисе могут быть обнаружены в специальном репозитории и реестре сервисов. Когда метаданные сервиса изменились, сервис может обновить свои данные в реестре сервисов.
Композитные сервисы могут быть построены из набора других сервисов.
С сервисно-ориентированной парадигмой каждая бизнес функциональность строится на сервисах, которые реализуют несколько под-функциональностей. Такие сервисы разворачиваются внутри сервера
приложений. Когда дело доходит до потребления бизнес функциональностей нам часто нужно интегрировать множество таких сервисов и других систем. Этой цели служит сервисная шина предприятия. Потребитель использует составные сервисы, открытые и доступные посредство слоя сервисной шины предприятия. Следовательно, она используется как централизованная шина, к которой подсоединены все эти сервисы и системы.
Рисунок 2 - Интернет-магазин, построенный на принципах SOA/ESB
Для примера вернемся назад к нашему интернет-магазину (см. Рисунок 2). На рисунке выше изображена схема реализации приложения интернет-магазин используя сервисно-ориентированную парадигму. Мы объявили множество веб-сервисов, которые обслуживают различные потребности бизнеса, такие как продукты, заказчики, портал продаж, заказы, платежи и т. д. На уровне шины ESB мы можем интегрировать эти бизнес-потребности и создавать объединенные сервисы, которые будут доступны потребителю. Или же ESB слой может быть использован чтобы открыть функциональные возможности пользователю как есть, с дополнительными функциями, например, такими как безопасность. Очевидно, что ESB слой также содержит значительную часть бизнес-логики всего приложения. Другие сопутствующие проблемы, такие как безопасность, мониторинг, аналитика могут быть также расположены на уровне шины. ESB слой является по своей сути монолитом, где все разработчики используют одну и туже среду выполнения для разработки и развертывания их сервисных интеграций.
Публикация бизнес функциональностей как сервисы, которыми можно управлять или внешних интерфейсов приложения является ключевым требованием современных архитектур корпоративных приложений. Тем не менее веб-сервисы, представленные выше, как и сервисно-ориентированная архитектура не являются идеальным решениями таких требований. Связано это с сложностью ориентированных на веб-сервисы технологий, таких как SOAP, WS-Security, WSDL и т. д.
Из-за этого большинство организаций помещают новый уровень управления API (Application programming interface) на вершине сервис-ориентированной схемы реализации. Этот слой также известен как API-фасад (API facade) или API Gateway. Он открывает простой интерфейс для потребителя и скрывает
всю внутреннюю сложность слоя ESB. Также API-фасад забирает на себя ответственность за безопасность, пропускную способность, кеширование и т. д.
Для примера на рисунке ниже представлен API фасад, расположенный перед ESB слоем. Все функциональные возможности нашего интернет-магазина теперь раскрыты потребителю через управляемый слой (см. Рисунок 3).
С ростом спроса на сложные бизнес возможности, монолитная архитектура больше не может обслуживать разработку современного корпоративного приложения. Ключевая суть монолитных приложений приводит к отсутствию возможности масштабировать приложения независимо, затруднению независимой разработки приложений, обнажает проблемы с надежностью. Чтобы преодолеть большинство из этих ограничений и удовлетворить современные, сложные и децентрализованные потребности приложений, должна быть придумана новая идеология.
Рисунок 3 - Раскрытие бизнес возможностей приложения как управляемое API через слой API Gateway
Микросервисная архитектура стала лучшей парадигмой, решивший недостатки подходов с использованием ESB и SOA архитектур, а также традиционных монолитных приложений.
Основой архитектуры микросервисов является разработка единого приложение как набор небольших и независимых сервисов, которые работают в отдельном процессе, а также разработаны и развернуты независимо от остальных.
Рисунок 4 - Схема интернет-магазина, построенного по принципам микросервисной архитектуры.
Рисунок выше иллюстрирует как интернет-магазин может быть переделан в микросервисную архитектуру посредством разрушения монолитного слоя приложения на отдельные независимые, ориентированные на потребности бизнеса сервисы (см. Рисунок 4). Также эта архитектура избавляет нас от центральной шины, таким образом сами сервисы заботятся о кросс-сервисном взаимодействии и композитной логике [6].
Каждый микросервис предлагает четко задекларированные функции для бизнеса, которые проектируются, разрабатываются, разворачиваются и администрируются независимо.
Уровень управления API остается во многом таким же, как и раньше не смотря на отсутствие шины и слоя ее коммуникации с сервисами. API gateway слой открывает потребителю задекларированные бизнес функции как управляемое API. Также открывается возможность разделить фасад API на отдельные и независимые среды исполнения, разделенные по какому-то признаку.
Любые разрабатываемые микросервисные приложения должны представить бизнес-возможности для потребителей таким образом, чтобы эти возможности можно было легко создавать, управлять ими, защищать, анализировать и масштабировать. Такие возможности предоставляются потребителям как API, которые регулируются процессом широко известный как управление API (API management). Аналогично, микросервисы могут использовать внешние API в процессе своей работы. В большинстве случае API представляют собой синхронный обмен сообщениями типа запрос-ответ.
Любые бизнес-возможности, которые предоставляются потребителю (внутренние или внешние) можно считать API. Раскрывать такие бизнес-возможностей стоит таким образом, чтобы была возможность создавать, управлять, защищать, анализировать и масштабировать это API. Эта возможность называется управлением API. Используя решение по управлению API, вы можно включить проверку политик и ключей, управление версиями сервисов, управление квотами, примитивные преобразования, авторизация и контроль доступа, наблюдаемость, возможности самообслуживания, рейтинги и т. д. для каждого микросервиса.
Когда дело доходит до управления API, есть несколько основных компонентов, которые должны быть частью любого решения по управлению API:
API Publisher
API Developer Portal / Store
API Gateway
API Analytics / Observability
API Monetization
API QoS (качество обслуживание, такие как безопасность, регулирование, кэширование и т. Д.)
Остановимся подробнее на описание сервиса публикации API (API Publisher) и так называемом шлюзе API (API Gateway). Сервис публикации может имеет большую зону ответственности чем просто расположения задекларированных API в шлюзе. Он может предоставлять все необходимые возможности разработчикам API для проектирования, разработки, публикации, версионирования, управления, мониторинга доступности и измерения производительности.
API-шлюз представляет собой единую точку вхождения для клиента, расположенную над сервис-ориентированным бэкендом. При публикации API помещается в API-шлюз. API-шлюз защищает, управляет и ответственен за масштабирование вызовов API. Все запросы, отправляемые пользователями, перехватываются шлюзом или направляются непосредственно в него. Это позволяет применять разные политики для целой группы API, такие как безопасность, фильтры, статистика использования API. Кроме того, в некоторых случаях есть возможность объединить множество бизнес-функций на уровне шлюза API.
Описанные выше принципы управления API открывают очень хорошо накладываются на методологию гибкой разработки и позволяют реализовывать конкретный бизнес функционал отдельно от остальных. Единственная проблема, которая стоит перед разработчиками на микросервисной архитектура
- это реализации этих шаблонов. Например, существует великолепная платформа для проектирования API
- Swagger, но она хороша развита именно для этого и не предоставляет открытой возможности или какой-либо интеграции с реализациями на API Gateway. Такие интеграции на данный момент разработаны только для облачных решений на Amazon. [9] Сама же платформа Swagger является коммерческим продуктом, это поднимает вопрос об о реальной полезности и выгоды продукта для конкретных случаев решения бизнес проблем. В реалиях новизны технологии готовые решения часто свежи и не могут точно соответствовать тем требованиям, которые стоят перед разработчиками из-за этого реализацию сервисов управлением API. Или же такие реализации существуют, но имеют свою специфику и совершенной другой взгляд разработчиков такого продукта на реализацию таких шаблонов и стоимость такой реализации очень дорого, как дорого и внедрение в свой продукт.
Каждый проект, разрабатывающий программный продукт с использованием микросервисных технологий, заботится о реализации API-Gateway и API-Publisher сервисах самостоятельно. У разработчиков есть выбор каким путем пойти, однако начало у этого пути начинается с дизайна API.
После дизайна API первый вариант - это сгенерировать код, на примере технологий Swagger, а также сгенерировать документацию. Однако, чтобы настроить публикацию API в сервисе API-gateway необходимо приложить усилия по интеграции Swagger решения. В этом подходе также есть проблемы с качеством генерируемого кода. Например, для Java, язык с сформировавшимся костяком пользователей и обширным количеством стандартов разработки, сгенерированный код будет очень хорошего качества, в то время как для языка Golang, относительно молодого, качество будет очень удовлетворительным.
Второй путь, это на основе спецификации дать разработчикам реализовать эту спецификацию самостоятельно, и на основе этого кода формировать документацию и публикацию API в сервисе API-gateway.
Для решения проблемы управления API (простоты публикации, поддержки актуальности) было решено пойти вторым путем и предоставить простой инструмент, позволяющий в режиме реального времени создавать и изменять API при помощи простых и понятных конфигурации. Также было решено не только такой инструмент предоставить, но и дать возможность расширения его функций и возможностей.
Список использованной литературы: 1. Brenda Jin, S. S. (2018). Designing Web APIs: Building APIs That Developers Love (1st ed.). O'Reilly Media.
2. Brendan Bums, J. B. (2019). Kubemetess Up & Running (2-e ed.). (K. Cofer, Ed.) USA: O'Reilly. Retrieved from http://oreilly.com/catalog/errata.csp?isbn=9781492046530
3. Bucchiarone, A. (2020). Microservices: Science and Engineering Hardcover (1st ed.). Springer.
4. Carnell, J. (2017). Spring Microservices in Action. Manning Publications.
5. Fowler, S. J. (2017). Production-Ready Microservices (1st ed.). O'Reilly Media.
6. Irakli Nadareishvili, R. M. (2016). Microservice Architecture: Aligning Principles, Practices, and Culture (1-e ed.). USA: O'Reilly.
7. Kasun Indrasiri, P. S. (2018). Microservices for the Enterprise (1 ed.). (L. Berendson, Ed.) San Jose, CA, USA: Apress Media LLC.
8. Kavis, M. J. (2014). Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS) (Wiley CIO) (1-e ed.). Canada: Jhon Wiley & Sons, Inc.
9. Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems Paperback. O'Reilly UK Ltd.
10. Morgan Bruce, P. A. (2019). Microservices in Action (1-e ed.). (M. Stephens, Ed.) NY, USA: Manning Publications Co.
11. Nayyar, D. A. (2019). Handbook of Cloud Computing: Basic to Advance research on the concepts and design of Cloud Computing (1-e ed.). USA: BPB Publications.
© OnbxoB fl. A., 2021
УДК 631.3.636
Попов Г.Г.
к.т.н., доцент
Волгоградский государственный аграрный университет ОЦЕНКА ЭФФЕКТИВНОСТИ И НАДЕЖНОСТИ КОРМОУБОРОЧНОЙ ТЕХНИКИ
Аннотация
Представлены результаты исследований фактического уровня эффективности и надежности кормоуборочной техники и проведен анализ существующей методики по их оценке.
Ключевые слова;
Эффективность, надежность, эксплуатация, кормоуборочная техника.
Любое изделие создают и эксплуатируют в определенных условиях окружающей среды; оно испытывает воздействие различных факторов - естественных (климатические, механические, биологические и др.), искусственных (преднамеренное воздействие извне), нагрузок (режим работы).
В зависимости от условий эксплуатации изменяются значения показателей эффективности и надежности кормоуборочных машин. Одно и тоже изделие, эксплуатируемое в лабораторных условиях или при воздействии высоких и низких температур, высокой влажности, ударов, вибраций, имеет существенно различные значения наработки на отказ, производительности за час эксплуатационного и основного времени. Поэтому весьма важным является достоверный и достаточный анализ эффективности и надежности сельскохозяйственной техники, используемой в реальных условиях эксплуатации, что обеспечивалось нами выбором достаточного количества изучаемых объектов и продолжительностью исследований.
В настоящее время довольно детально изучен вопрос, касающийся выбора количества объектов для обеспечения достоверности результатов исследований с заранее заданной точностью, разработаны соответствующие планы испытаний.
Наиболее часто применяется при исследовании надежности самоходных кормоуборочных машин план ^М (г,Т £ ]): одновременно испытываются N - объектов; после каждого отказа объект восстанавливают; испытания прекращают, когда суммарное по всем объектам число отказов достигает г
