перевод статьи. Архитектурный подход к созданию облачного приложения для разрабо. N. M. Sajedul Alam1, Junaid Bin Kibria1, Al Hasib Mahamud1, Arnob Kumar Dey1, Hasan Muhammed Zahidul Amin1, Md Sabbir Hossain1, Annajiat Alim Rasel Краткий обзор
 Скачать 0.6 Mb.
|
|
Архитектурный подход к созданию облачного приложения для разработки микросервисов A. N. M. Sajedul Alam1, Junaid Bin Kibria1, Al Hasib Mahamud1, Arnob Kumar Dey1, Hasan Muhammed Zahidul Amin1, Md Sabbir Hossain1, Annajiat Alim Rasel Краткий обзор. Облако - это новая парадигма, которая прокладывает путь для новых подходов и стандартов. Архитектурные стили развиваются в соответствии с требованиями облака. В последние годы микросервисы стали предпочтительным архитектурным стилем для масштабируемых, быстро развивающихся облачных приложений. Внедрение микросервисов в ущерб монолитным структурам, от которых все чаще отказываются, является одним из наиболее значительных событий в бизнес-архитектуре. Облачные архитектуры делают развертывание систем микросервисов более производительным, адаптируемым и экономичным. Несмотря на это, многие фирмы начали переходить от одного типа архитектуры к другому, хотя это все еще находится на ранних стадиях. Основная цель этой статьи - получить лучшее представление о том, как проектировать микросервисы посредством разработки облачных приложений, а также о текущих тенденциях в области микросервисов, причинах исследования микросервисов, новых стандартах и перспективных пробелах в исследованиях. Исследователи и практики в области разработки программного обеспечения могут использовать эти данные, чтобы быть в курсе разработок SOA и облачных вычислений. Ключевые слова: Микросервисы, Архитектура, Облачное приложение 1 Вступление Поскольку монолитная архитектура больше не рассматривается для использования, микросервисная архитектура считается одной из актуальных тем в индустрии программного обеспечения. Очень важно иметь четкое представление о шаблоне проектирования микросервисной архитектуры. Недавно были внедрены микросервисные проекты для разделения архитектур на независимые службы, которые можно развертывать, и эти службы могут быть быстро развернуты на любом ресурсе по мере необходимости [1]. Микросервисная архитектура (MSA) считается подмножеством Сервис- ориентированной архитектуры (SOA), которая фокусируется на определенных элементах. SOA и MSA имеют много различий. Архитектура сервиса MSA основана на менталитете "не делись ничем" с точки зрения упрощения гибких методологий. Это поощряет изоляцию и автономию [2]. Вместо этого SOA способствует высокому уровню повторного использования, принимая философию "делитесь как можно больше". Ранее для создания приложений использовались монолитные методы. Это означает, что полная программа была выполнена из одной кодовой базы [3]. Хорошо известно, что разработать монолитную программу проще, чем распределенную. Напротив, приведение их в действие сопряжено с рядом трудностей. Отсутствие масштабируемости и адаптивности - два наиболее важных недостатка монолитных приложений, поскольку они построены как единое целое, монолитные приложения очень сложно изменять. Такие приложения имеют высокую степень подключения, что делает их проблематичными из-за их огромного размера, масштабирование монолитных программ является серьезной проблемой. Когда требуется масштабировать только часть монолитного приложения, оно должно быть масштабировано в целом. Такие проблемы, наряду с появлением инновационных технологий, побудили индустрию программного обеспечения искать альтернативы. Многие из этих проблем можно преодолеть, используя микросервисы. Микросервисы - это в основном набор взаимосвязанных сервисов, составляющих приложение. Каждая услуга предназначена для выполнения определенной функции. Развертывание, а также процессы замены упрощаются благодаря их уменьшенным размерам. В результате организации могут выполнять действия, которые было бы сложно или невозможно выполнить с помощью традиционного монолитного программного обеспечения. Микросервисы могут быть развернуты отдельно, как правило, с помощью платформы развертывания и оркестровки, например, в облаке, что позволяет им развертываться часто и по собственному расписанию [4]. Развертывание и оркестровка микросервисов в рассредоточенном и многоуровневом характере облака являются важными проблемами архитектуры. Для их изменяющихся графиков развертывания и требований к организации подготовки облака предоставляют платформу управления. В этой статье микросервис был создан с использованием различных технологий. Для некоторых конкретных услуг, которые требовались для другого распределенного проекта. Основная цель этой работы заключается в том, что для решения задач нашего проекта будет создан гибридный микросервис, с помощью которого мы сможем использовать его для экономии времени при работе с облачными сервисами. 2 Обзор литературы Дмитрий Намиот и др. [5] предложил обзор микросервисной архитектуры, включая плюсы и минусы подхода, и предоставил схему развертывания. Авторы также продемонстрировали разделение системы на микросервисы по вариантам использования, и для этой цели они использовали модель M2M ETSI. Набор К.Мендонк и др. [6] обсудил проблемы существующих и появляющихся микросервисных технологий на примере облачного интеллектуального устройства видеонаблюдения. При проектировании микросервисной архитектуры было показано взаимодействие между самоадаптивными системами и микросервисами. Ляньпин Чен и др. [7] предложил подход к решению проблем, которые могут возникнуть в микросервисной архитектуре. Указав области, которые необходимо изучить подробнее для построения микросервисной архитектуры, авторы также обсудили основные преимущества микросервисной архитектуры. Мухаммад Васим и др. [8] показал проблемы архитектуры микросервисного программного обеспечения с DevOps с определением архитектуры микросервиса проектирования, рефакторинга и эволюции архитектуры микросервисного программного обеспечения. Клаус Пал и др. [4] сравнил текущее состояние исследований микросервисной архитектуры и ее облачных приложений. Основываясь на изучении 21 статьи, связанной с микросервисной архитектурой, авторы предложили сравнение по выбранным статьям, где структура для характеристики является основной проблемой. Сравнение показало развивающиеся проблемы в архитектуре микросервиса. Нуха Альшукайран и др. [9] предложил реализацию на основе исследования, основанного на систематическом отображении в микросервисной архитектуре. Реализация в основном фокусируется на поиске архитектурных проблем, представлений об архитектуре и факторов качества, связанных с микросервисными системами. Авторы выбрали 33 публикации, из которых провели исследование. Согласно этому исследованию, наиболее распространенными категориями исследований были оценочные исследования, за которыми следовали рекомендации по решению. Согласно их исследованию, модульность, масштабируемость и ремонтопригодность, по-видимому, входят в число наиболее обсуждаемых характеристик. Далее они указывают на то, что наиболее недооцененным обсуждаемым атрибутом является безопасность. Согласно этому исследованию, подходы DevOps - это путь в будущее. Х.Вурал и др. [10]. провели обзор 37 работ по архитектуре микросервисов, чтобы составить список характеристик микросервисов. Предлагаемый подход этого исследования можно рассматривать как подходящую отправную точку для разработки общего определения микросервисов. Авторы предоставили список из нескольких новых технологий. REST был на первом месте в списке, за ним следовал swagger. Составлен список наиболее часто используемых технологий, где на первом месте стоит Docker, за которым следуют Node.js и MySQL. Дхармендра Шадиджа и др. [11] сравнили архитектуру микросервисов и SOA на основе нескольких статей, написанных о SOA и микросервисах. Процесс определения микросервисов также является важной темой в этой работе. В то время как аналогичные попытки предпринимались в других статьях, исследование выделяется широтой его обсуждения. 3 Методология Услуга-один и услуга-два - это две услуги, предлагаемые предлагаемым приложением. Каждая служба имеет свою собственную базу данных, такую как service-1-db и service-2-db. Во время запуска службы он сохраняет имя службы и UUID, который автоматически генерируется в зависимости от точки зрения базы данных, а затем передает информацию в обмен RabbitMQ, который показывает данные каждому потоку в зависимости от ключа для маршрутизации. Все микросервисы обслуживают очередь, предоставляемую RabbitMQ, и обновляют базу данных, как только поступают новые данные. 3.1 Регистрация услуги Есть серверы, а именно обнаружение и регистрация. Чтобы настроить его, сервис должен быть зарегистрирован на обоих серверах (в нашем случае это консул с именем HashiCorp), как показано на рис. 1. Рис 1 – Последовательность регистрации услуги 3.2 Обнаружение службы Как только сервис (например, шлюз API) позволяет ему обновлять определенный товар из другого сервиса (например, service one), ему нужно только запросить идентификацию и сервер регистрации (Consul) для одного экземпляра сведений о сервисе. Весь процесс образно описан на рис. 2. Рис 2 – Последовательность обнаружения службы 3.3 Архитектура Рис 3 – Архитектура Netflix Zuul - это обратный прокси-сервер, который служит шлюзом API для подключения микросервисов на задней панели того же шлюза, который направляет запросы к соответствующей службе. Микросервисы скрыты там за обратным прокси-сервером, и доступ к ним должен осуществляться через шлюз API. Вся архитектура показана в виде потока на рис. 3. 3.3.1 Настройка маршрутизации завершена в шлюзе API: Консул HashiCorp отвечает за регистрацию и обнаружение. Отдельные службы регистрируют свои данные в службе регистрации служб во время запуска, включая такое имя хоста, порт и т.д., Благодаря чему становится возможной доступность служб. Снова, когда регистрация услуги была завершена с помощью консула, консул проверил качество услуги, отправив сигнал для пути проверки качества и интервала проверки качества, который был указан. Запросы, связанные с микросервисами, должны маршрутизироваться с помощью шлюза API, который использует шлюз API для связи со службой обнаружения для сбора соответствующих данных, необходимых для отправки запроса в правильный микросервис. 3.3.2 Конфигурация микросервисов для регистрации Консула: 4 Результат анализов Начнем с того, что основное приложение расположено по адресу localhost:80. Три службы, "Служба-1", "Служба-2" и "Служба-3", легко видны в этом приложении, и, нажав на любую из них, пользователь направляется к шлюзу API, который определяет, куда должен быть отправлен запрос. Если вы выберете Service-1, с API- интерфейсами свяжутся по адресу localhost:8080, и вызов будет внутренне перенаправлен на localhost:8082, где находится наш Service-1. Услуга-2 доступна по адресу localhost:8084. Кроме того, последний, Service-3, доступен по адресу localhost:8086. По сути, когда кто-то нажимает на Service-1, он отправляет запрос на шлюз API на порту 8080, который затем определяет, где запущена Service-1, разговаривая с Consul. Consul фактически предоставляет сведения о портах подключаемых служб, и каждый раз, когда они вызываются API, API запрашивают у consul их информацию. Это одинаково для всех сервисов. Kibana была нашей консолидированной системой ведения журнала. Во-вторых, weave scope использовался для мониторинга и визуализации контейнеров, поскольку он обеспечивает обзор вашего приложения с высоты птичьего полета и всей его архитектуры, а также возможность обнаруживать любые проблемы с вашим распределенным контейнерным программным обеспечением в режиме реального времени во время его развертывания у облачного провайдера. Наконец, мы использовали ELK для централизованного ведения журнала. Когда Logback сопряжен с микросервисом Logstash, он генерирует журналы приложений и доставляет их на сервер ведения журнала. Используя Logstash-Elasticsearch, данные подготавливаются и передаются на сервер индексирования. Kibana может использоваться для визуального отображения данных с сервера elasticsearch. Кроме того, асинхронная связь микросервисов, которая по сути является взаимодействием между микросервисами, осуществляется асинхронно с использованием simply RabbitMQ. Рис 4 – Линейная диаграмма для отображения сравнения производительности между службами Из приведенного выше рис. 4. можно видеть, что для каждой службы в этом микросервисе мы наблюдали, что для генерации UUID каждый раз и сохранения его в их собственной базе данных расход времени варьируется. В приведенном выше примере мы выбрали определенный временной диапазон, который составляет 0-4 секунды, для каждой службы и взяли 20 выборок, чтобы проверить, сколько времени требуется каждой службе для генерации и сохранения UUID в их базе данных. Глядя на линейный график, мы можем сказать, что Сервис-1 работает лучше всего до конца, потому что он занимает меньше времени, чем два других сервиса, хотя вначале Сервис-2 был самым производительным, но после этого только Сервис-1 был вторым по производительности по сравнению с Сервисом-3, в середине. В конце концов, Сервис-1 оказался лучшим сервисом. Таблица 1 – 20 выборок для каждой услуги Эта таблица 1 была таблицей наших 20 образцов, все из которых были взяты в промежутке от 0 до 4 секунд. Время отклика подсчитывалось для каждой генерации UUID в этих 20 выборках для Сервиса-1, Сервиса-2 и Сервиса-3. Рис 5 – Соединения между службами Из рис. 5. мы видим, что Консул, Консул-2, Консул-3 - это три главных консула. Консул связан как с Консулом-2, так и с Консулом-3. Консул также подключен к входящим подключениям к Интернету. Kibana, веб-приложение, Rabbit-mg подключены к входящим подключениям к Интернету. Консул подключен к API- шлюзу. API-шлюз подключен к Service-One. Сервис-один связан с Consul и Rabbit- mg. Rabbit-mg внутренне связан сам с собой в виде петли, а также связан с service- one. Service-one-db связан с service-one. Кроме того, Сервис-один связан с long-stash. Длинный тайник связан с elasticsearch. Кроме того, elasticsearch связан с Kibana. Сервис-два связан с API-шлюзом. Service-two-db подключен к Service-two, Consul и Rabbit-mg. 5 Заключение Эта статья успешно продемонстрировала, как спроектировать архитектуру микросервисов путем создания облачных приложений. Мы также проливаем свет на некоторые тенденции развития микросервисов, цель и видение инвестирования в такие исследования. Обсудили некоторые технические пробелы, а также коснулись предстоящих стандартов проектирования стандартов. Будущая работа могла бы заключаться в разработке более надежной архитектуры и улучшении сервисов таким образом, чтобы затраты времени были меньше, чем раньше, а следовательно, и экономия времени. Ссылки на литературу 1. Lewis, J. and Fowler, M. (2014). Microservices. http://martinfowler.com/articles/microservices.html. 2. P. D. Francesco, I. Malavolta and P. Lago, "Research on Architecting Microservices: Trends, Focus, and Potential for Industrial Adoption," 2017 IEEE International Conference on Software Architecture (ICSA), 2017, pp. 21-30, DOI: 10.1109/ICSA.2017.24. 3. Hamzehloui, Mohammad Sadegh et al. “A Study on the Most Prominent Areas of Research in Microservices.” International Journal of Machine Learning and Computing (2019): n. pag. 4. Claus Pahl and Pooyan Jamshidi. 2016. Microservices: A Systematic Mapping Study. In Proceedings of the 6th International Conference on Cloud Computing and Services Science - Volume 1 and 2 (CLOSER 2016). SCITEPRESS - Science and Technology Publications, Lda, Setubal, PRT, 137–146. DOI:https://doi.org/10.5220/0005785501370146 5. Namiot, Dmitry, and Manfred Sneps-Sneppe. “On micro-service architecture” International Journal of Open Information Technologies 2, no. 9 (2014): 24-27. 6. N. Mendonca, P. Jamshidi, D. Garlan and C. Pahl, "Developing Self-Adaptive Microservice Systems: Challenges and Directions" in IEEE Software, vol. 38, no. 02, pp. 70-79, 2021.DOI: 10.1109/MS.2019.2955937 7. L. Chen, "Microservices: Architecting for Continuous Delivery and DevOps," 2018 IEEE International Conference on Software Architecture (ICSA), 2018, pp. 39-397, DOI: 10.1109/ICSA.2018.00013. 8. M. Waseem and P. Liang, "Microservices Architecture in DevOps," 2017 24th Asia-Pacific Software Engineering Conference Workshops (APSECW), 2017, pp. 13-14, DOI: 10.1109/APSECW.2017.18. 9. N. Alshuqayran, N. Ali and R. Evans, "A Systematic Mapping Study in Microservice Architecture," 2016 IEEE 9th International Conference on Service-Oriented Computing and Applications (SOCA), 2016, pp. 44-51, DOI: 10.1109/SOCA.2016.15. 10. Vural, Hulya et al. “A Systematic Literature Review on Microservices.” ICCSA (2017). 11. D. Shadija, M. Rezai and R. Hill, "Towards an understanding of microservices," 2017 23rd International Conference on Automation and Computing (ICAC), 2017, pp. 1-6, DOI: 10.23919/IConAC.2017.8082018. |