# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА: + АРХИТЕКТУРА + Vision + Solution Design + ESB - Микросервисы и service mesh | Микросервисы (MSA) | Service mesh + HTTP/REST + RPC + DDD ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Микросервисы и service mesh
latest update of the page: 27-01-2024, 09:53 UTC
Микросервисы (MSA)

Микросервисная архитектура = метод создания распределённых приложений в виде набора независимо разрабатываемых и развёртываемых в изолированном окружении небольших служб. Является частным случаем SOA.

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

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

Поскольку асинхронное событийное взаимодействие — практически стандарт в микросервисной архитектуре, то надо разбираться в создании событийной архитектуры (Event Driven Architecture, см. статью https://habr.com/ru/company/dataart/blog/280083/), а сами микросервисы должны соответствовать требованиям Reactive.

скачать схему в формате diagrams.net (бывший draw.io)

Зачем в микросервисы?

Основные плюсы здесь — с точки зрения процессов:
  • независимый деплой (проще тестировать и выкатывать/откатывать по кусочкам)
  • гарантия того, что другие команды не сунутся туда, куда им соваться не нужно, и не будет конфликтов при мержах (изоляция)
  • форсируется общение через чётко документированное API (нельзя взять и накостылять что-то в обход)
Когда над монолитом работают несколько команд, постоянно что-то отваливается/не собирается, нужно разруливать какие-то конфликты при мержах, другая команда залезла в твой код и накуролесила, поменяли общий класс-зависимость и поведение немного поменялось, но сломало твои кейсы и т.д. (это даже при DDD).
С микросервисами вообще в этом плане лепота — присутствует какая-то стабильность, при переходе от задачи к задаче и мержах старых задач есть уверенность, что оно с вероятностью 99.99% заведется без проблем и будет работать так же, как в прошлый раз оставил.
© комментарий на habr

Что почитать на тему:
Service mesh
Что почитать на тему:

Кто использует service mesh

Крупные корпорации, банки и прочие предприятия, имеющие сотни (микро)сервисов с очень нагруженной коммуникацией между ними, а также те, кто является владельцем целых платформ.
Пионерами в микросервисной архитектуре и service mesh в ИТ являются Lyft, Netflix и Twitter.
В российских реалиях внедрение происходит в топ-банках и, например, Авито.

Ценность service mesh: предоставление функций, критически важных для работы современного серверного ПО, единообразным для всего стека и независимым от кода приложения образом.

Суть

Service mesh = архитектурный подход, который

  • в условиях наличия сотен (микро)сервисов + использования облаков с тысячами инстансов + использования контейнеризации + необходимости обработки больших объёмов межсервисных коммуникаций
  • за счёт добавления в инфраструктуру userspace-прокси (data plane), расположенных "рядом" с сервисами, и набора управляющих процессов (control plane)
  • позволяет реализовывать такие функции как service discovery + routing + balancing + tracing + authentication + authorization + encryption + circuitBreaking + autoscaling и другие

Data plane перехватывает вызовы между сервисами, производя над ними необходимые манипуляции.
Control plane координирует поведение прокси и обеспечивает доступ для оператора к API, позволяя манипулировать сетью, изменяя её как единое целое.

Service mesh занимается эксплуатационной логикой, а не смысловой. Занятие смысловой логикой было главным недостатком сервисной шины предприятия (ESB).
Сохранение этого разделения помогает service mesh избежать той же участи.

Некоторые технологии и инструменты из области Service mesh

  • Linkerd самый первый service mesh framework, активно развивается. Использует встроенный прокси, написанный на Rust
  • Istio service mesh framework, продвигаемый Google + IBM + LYFT. В качестве прокси использует Envoy.
  • gRPC — RPC фреймворк, использующий protobuf и HTTP/2
  • HTTP/2
  • TLS со взаимной аутентификацией.
  • protobuf (protocol buffers)
  • В качестве прокси: Nginx или Envoy
  • Jaeger как инструмент распределённой трассировки запросов
  • Prometheus cloud-native инструмент сбора метрик
  • Grafana дашборды для метрик
  • Kubernetes как фреймворк оркестрации контейнеров
  • Openshift и RHL