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

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