Микросервисы (MSA)
Микросервисная архитектура = метод создания распределённых приложений в виде набора независимо разрабатываемых и развёртываемых в изолированном окружении небольших служб. Является частным случаем SOA.
Каждый микросервис включает в себя свой стек технологий, выбор которого осуществляется непосредственным разработчиком. Вместо единой базы данных в каждом микросервисе используется собственный инструмент хранения информации, причем выбор реляционной или нереляционной СУБД, способа организации данных, атрибутивного состава и программных интерфейсов для предоставления данных также ни с кем не согласуется.
Микросервисная архитектура изолирует сбои и повышает устойчивость системы. Монолитное приложение обрушается целиком, когда какой-нибудь несущественный отчёт, запускаемый раз в квартал, может стать причиной деградации системы массового обслуживания. Микросервисная архитектура снижает вероятность таких событий.
Поскольку асинхронное событийное взаимодействие — практически стандарт в микросервисной архитектуре, то надо разбираться в создании событийной архитектуры (Event Driven Architecture, см. статью https://habr.com/ru/company/dataart/blog/280083/), а сами микросервисы должны соответствовать требованиям Reactive.
скачать схему в формате diagrams.net (бывший draw.io)
Зачем в микросервисы?
Основные плюсы здесь — с точки зрения процессов:
- независимый деплой (проще тестировать и выкатывать/откатывать по кусочкам)
- гарантия того, что другие команды не сунутся туда, куда им соваться не нужно, и не будет конфликтов при мержах (изоляция)
- форсируется общение через чётко документированное API (нельзя взять и накостылять что-то в обход)
Когда над монолитом работают несколько команд, постоянно что-то отваливается/не собирается, нужно разруливать какие-то конфликты при мержах, другая команда залезла в твой код и накуролесила, поменяли общий класс-зависимость и поведение немного поменялось, но сломало твои кейсы и т.д. (это даже при DDD).
С микросервисами вообще в этом плане лепота — присутствует какая-то стабильность, при переходе от задачи к задаче и мержах старых задач есть уверенность, что оно с вероятностью 99.99% заведется без проблем и будет работать так же, как в прошлый раз оставил.
©
комментарий на habr
Что почитать на тему:
- Microservices (Martin Fowler, 2014) — с этого всё началось.
- Микросервисная архитектура в корпоративном ИТ-ландшафте. Вменяемая комплексная статья о микросервисах в сложном ИТ-ландшафте. Её одну можно рекомендовать взамен 10 стандартных громогласных буллщит-статей о микросервисах.
- Microservices. Как правильно делать и когда применять? ("DataArt", 2016)
- Микросервисная архитектура, подходы и технологии (Кирилл Ветчинкин, 2018). Плюсы, минусы, как проектировать, типовые ошибки/проблемы, способы решения. Да, в презентации есть некоторые ошибки и спорные моменты, но это одна из лучших о микросервисах на мой взгляд.
-
Организация бизнес-процессов при микросервисном подходе:
-
Тестирование:
Service mesh
Что почитать на тему:
- История service mesh в компании (Александр Лукьянченко, Авито, 2019). Об изначальных проблемах, о подходе к Service Mesh, о проблемах с эксплуатацией Istio, о создании собственного решения в виде sidecar-сервиса Netramesh (Golang + K8s / bare metal), о внедрении OpenTracing с инструментом Jaeger (что позволяет получать карты взаимодействия сервисов), о тестах и выделении критичных путей, о своего рода канареечных тестах с подменой роутинга для тестов.
- Что такое Service Mesh? (2020) — коротко о.
- Сценарии использования service mesh (2020)
- Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии (2019). Ангажировано Linkerd.
- Что такое service mesh, когда внедрять, альтернативы Istio и другие ответы экспертов с АМА-сессии (2021)
- Трассировка сервисов, OpenTracing и Jaeger
- Как мы в Dropbox перешли с Nginx на Envoy
Кто использует 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