Исследование приложений и систем в микросервисе
Введение
За последнее десятилетие в контексте облачных вычислений одной из наиболее развитых и применимых архитектур для распределенных приложений стала микросервисная архитектура. Одним из ее преимуществ является независимость создания и развертывания отдельных элементов системы, а также высокий уровень декомпозиции всего проекта.Одни из крупнейших компаний индустрии, такие как Netflix (свыше 500 микросервисов [1]), Spotify (свыше 800 микросервисов [1]) и Uber (свыше 1000 микросервисов [1]), используют данную архитектуру для разработки своих продуктов. Более формально, микросервисы представляют собой архитектурный стиль, к настоящему моменту насчитывающий уже более 28 подходов к реализации [1]. При таком количестве одновременно существующих и динамически изменяющихся модулей программного кода ощущается острая необходимость в средствах визуализации [8, 19]. Вследствие этого к настоящему моменту было создано множество инструментов визуализации микросервисной архитектуры — классификация представлена на рисунке 1Компания Netflix столкнулась с трудностями при обработке информации от большого количества клиентов. Когда компания обнаружила, что ее рост превышает возможности монолитной архитектуры, микросервисы оказались подходящим решением для масштабирования. В среднем вечером в будни Netflix занимает почти третью часть всего интернета Северной Америки, а до полуночи - минимум. Микросервисные архитектуры стали спасением от того, что сервис падает в условиях такого нестабильной загруженности, позволяя разворачивать дополнительные серверы в пиковые часы.Pinterest в качестве одного из самых быстрых интернет-сайтов, для экспериментов с различными уровнями трафика используют микросервисы. При этом обладает невероятно малоенькой командой. Их интернет-сервис был разработан специально для генерации больших объемов данных, которые стали возможными благодаря использованию микросервиса.
Оглавление
Глава 1. Микросервисные архитекты 7
1. 1. Общий анализ архитектуры микросервиса 7
1.2 Характеристики микросервисов 9
1.3 Сильные и слабые стороны микросервисных и монолитных архитектур 10
1.4 Шаблоны дизайна приложений с архитектурой микросервиса 16
1. 5 Фреймворк gRPC 22
Глава 2. Визуализация приложений с использованием архитектуры микросервиса. 26
2.1 Проблемы и препятствия при переходе из монолитных архитектур в микросервисы 26
2. 2 Визуализация архитектуры микросервиса 39
2.3. Визуализация в зависимости от времени развертывания 41
2. 4. Автоматические декомпозиции монолитных архитектурных конструкций 45
3. Ограничения и требования 48
3. 1. Функциональное требование 48
3.2 Архитектура проекта 50
3.3 Особенности реализации. Поиск взаимодействий «HTTP/Websocket» 52
3.4 Поиск очереди сообщений 55
3.5 Тестирование и анализ результатов 58
Заключение 70
Литература 72
Список литературы
1. Microservices vs Monolith: which architecture is the best choice for your business? [Electronic resource] – Mode of access: https://www.n- ix.com/microservices-vs-monolith-which-architecture-best-choice- your-business/
2. SOA vs. microservices: What’s the difference [Electronic resource] – Mode of access: https://www.ibm.com/blogs/cloud-computing/2018/09/06/soa-versus-microservices/#:~:text=The%20main%20difference%20between %20SOA,architecture%20has%20an%20application%20scope.
3. Переход от монолита к микросервисам [Электронный ресурс] – Режим доступа: https://habr.com/ru/post/305826/
4. What are microservices? [Electronic resource] – Mode of access: https://microservices.io/
5. gRPC – A high-performance, open source universal RPC framework [Electronic resource] – Mode of access: https://grpc.io/
6. Основы Kubernetes [Электронный ресурс] – Режим доступа: https://habr.com/ru/post/258443/
7. Agones [Electronic resource] – Mode of access: https://agones.dev/site/
8. R. Chen, S. Li, and Z. Li, “From monolith to microservices: a dataflow- driven approach,” in 2017 24th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 2017, pp. 466–475.
9. D. Taibi, V. Lenarduzzi, and C. Pahl, “Processes, motivations, and issues for migrating to microservices architectures: An empirical investigation,” IEEE Cloud Computing, vol. 4, no. 5, pp. 22–32, 2017.
10. A. Bucchiarone, N. Dragoni, S. Dustdar, S. T. Larsen, and M. Mazzara, “From monolithic to microservices: an experience report from the banking domain,” Ieee Software, vol. 35, no. 3, pp. 50–55, 2018.
11. GCP: Разбор вычислительного стека Google Cloud Platform [Электронный ресурс] – Режим доступа: https://habr.com/ru/company/otus/blog/467749/
Другим важным решением является какие технологии использовать для исполнения среды. Многие предприятия, имеющие существующие приложения, работающие в стабильной виртуальной инфраструктуре, выбирают подход развертывания контейнеров на виртуальной машине, это позволяет им получить преимущества мониторинга и изолировании с быстрыми «DevOps» процессами. В отличие от контейнеров, работающих на обычных процессорах, они уменьшают производительность, габариты и издержки. И это, безусловно, правильный способ перехода [15].Микросервисная архитектура подходят для облачного приложения. Собственно облачные приложения определяются как приложения, созданные для архитектуры облачного вычисления. Это значит, что наши приложения являются нативными облаками, если спроектируем их так, будто они будут развернуты в распределенной, масштабируемой инфраструктуре.[16].Мониторинг – важная часть инфраструктуры микросервисов. Используя перечисленные ниже принципы, позволяющие организации устанавливать более эффективную мониторинговую деятельность. Это принцип позволит организации решать технологические и организационные изменения в микросервисах.
Миграцию устаревших монолитных программ в микросервисы быстро провести не получится. Очень важно знать о том, что существуют высокие общие затраты, связанные с передачей существующей системы микросервисов, и для этого может понадобиться множество итерации. Поскольку корпоративные приложения являются очень широкими терминами, не может быть сказано, что это лишь один хороший путь перехода от старого монолита в архитектуру микросервисов. Благодаря тому, что микросервисы представляют собой сравнительно новый архитектурный стиль и не имеют общепринятого метода перемещения, различные организации применяют различные методы и методики миграции.Ключевая проблема в данном контексте заключается в том, чтобы извлечь микросервис из существующих наследованных монолитных кодовых баз.