Архитектура микросервисов - вариант сервиса Структурный стиль -ориентированная архитектура (SOA) - упорядочивает приложение как набор слабо связанных сервисов. В архитектуре микросервисов сервисы детализированы, а протоколы легковесны.
Единого определения микросервисов не существует. Со временем в отрасли сформировалось консенсусное мнение. Некоторые из определяющих характеристик, которые часто упоминаются, включают:
Микрослужба не является слоем внутри монолитного приложения (например, веб-контроллера или серверной части для внешнего интерфейса). Скорее, это автономная часть бизнес-функциональности с понятными интерфейсами, которая может через свои внутренние компоненты реализовывать многоуровневую архитектуру. С точки зрения стратегии, архитектура микросервисов по существу следует философии Unix «Делай одно и делай это хорошо». Мартин Фаулер описывает архитектуру, основанную на микросервисах, как обладающую следующими свойствами:
Архитектура микросервисов обычно используется для облачных приложений, бессерверных вычисления и приложения, использующие облегченное развертывание контейнера. По словам Фаулера, из-за большого количества (по сравнению с реализациями монолитных приложений) сервисов, децентрализованной непрерывной доставки и DevOps с целостным сервисом Мониторинг необходим для эффективной разработки, сопровождения и эксплуатации таких приложений. Следствием (и обоснованием) использования этого подхода является то, что отдельные микросервисы можно масштабировать индивидуально. При монолитном подходе необходимо масштабировать приложение, поддерживающее три функции. целиком, даже если только одна из этих функций имела ограничение ресурсов. При использовании микросервисов необходимо масштабировать только микросервис, поддерживающий функцию с ограничениями ресурсов, что обеспечивает преимущества оптимизации ресурсов и затрат.
Еще в 2005 году Питер Роджерс ввел термин « Micro- Web-Services "во время презентации на конференции Web Services Edge. Вопреки общепринятому мышлению и на пике шумихи вокруг архитектуры SOAP SOA он выступал за «REST-сервисы» и на слайде № 4 презентации конференции он обсуждает «Программные компоненты - это Micro-Web-Services».. Далее он говорит: «Микрослужбы состоят из Unix-подобных конвейеров (Web соответствует Unix = true слабой связи ). Службы могут вызывать службы (+ многоязычная среда выполнения). Сложные сервисные сборки абстрагируются за простыми интерфейсами URI. Любой сервис, с любой степенью детализации, может быть представлен ». Он описал, как хорошо спроектированная платформа микросервисов «применяет основные архитектурные принципы Web и REST-сервисов вместе с Unix-подобным планированием и конвейерами, чтобы обеспечить радикальную гибкость и повышенную простоту сервис-ориентированных архитектур <18.>
Работа Роджерса началась в 1999 году с исследовательского проекта Декстера в Hewlett Packard Labs, цель которого заключалась в том, чтобы сделать код менее уязвимым и сделать крупномасштабные сложные программные системы надежными <87 В конечном итоге этот путь исследований привел к развитию ресурсо-ориентированных вычислений (ROC), обобщенной абстракции вычислений, в которой REST является особым подмножеством.
В 2007 году Juval Леви в своих письмах и выступлениях призывал к созданию систем, в которых каждый класс был бы сервисом. Леви понял, что для этого требуется использование технологии, которая может поддерживать такое детальное использование сервисов, и он расширил Windows Communication Foundation (WCF) для этого, принимая каждый класс d рассматривать его как услугу, сохраняя при этом обычную модель программирования классов.
На семинаре архитекторов программного обеспечения, проходившем недалеко от Венеции в мае 2011 года, термин «микросервис» использовался для описания того, что участники считали общим архитектурным стилем, который многие из них недавно изучали. В мае 2012 года та же группа выбрала «микросервисы» как наиболее подходящее название. Джеймс Льюис представил некоторые из этих идей в виде тематического исследования в марте 2012 года на 33-й конференции в Кракове по микросервисам - Java, Unix Way, как и Фред Джордж примерно в то же время. Адриан Кокрофт, бывший директор по облачным системам в Netflix, охарактеризовал этот подход как «мелкозернистую SOA», впервые применил стиль в веб-масштабе, как и многие другие, упомянутые в этой статье - Джо Уолнес, Дэн Норт, Эван Ботчер и Грэхем Тэкли.
Микросервисы - это специализация подхода к реализации для сервисно-ориентированных архитектур (SOA), используемых для создания гибких, независимо развертываемых программных систем. Подход с использованием микросервисов - это первая реализация SOA, которая последовала за введением DevOps и становится все более популярной для создания постоянно развертываемых систем.
В феврале 2020 года облако В отчете об исследовании рынка микросервисов прогнозировалось, что размер мирового рынка микросервисных архитектур увеличится на CAGR на 21,37% с 2019 по 2026 год и достигнет 3,1 миллиарда долларов к 2026 году.
Ключевым шагом в определении архитектуры микросервиса является определение размера отдельного микросервиса. Для этого не существует консенсуса или лакмусовой бумажки, поскольку правильный ответ зависит от бизнеса и организационного контекста. Например, Amazon, как известно, использует сервис-ориентированную архитектуру, где сервис часто отображает 1: 1 с командой из 3-10 инженеров.
Это считается плохим Практика, чтобы сделать сервис слишком маленьким, так как тогда накладные расходы времени выполнения и операционная сложность могут подавить преимущества подхода. Когда все становится слишком детализированным, необходимо рассмотреть альтернативные подходы, такие как упаковка функции в виде библиотеки, перенос функции в другие микросервисы.
Если используется доменное проектирование при моделировании домена, для которого создается система, микросервис может быть таким маленьким, как Агрегат, или таким большим, как Ограниченный контекст.
Преимущество декомпозиции приложения на существует множество различных более мелких сервисов:
Подход микросервисов подвергается критике по ряду вопросов:
Архитектура привносит дополнительную сложность и новые проблемы, с которыми приходится иметь дело, например, задержка сети, формат сообщения дизайн, резервное копирование / доступность / согласованность (BAC), балансировка нагрузки и отказоустойчивость. Все эти проблемы необходимо решать масштабно. Сложность монолитного приложения не исчезнет, если оно будет повторно реализовано как набор приложений микросервисов. Некоторая сложность превращается в сложность эксплуатации. Другие места, где проявляется сложность, - это увеличение сетевого трафика и, как следствие, снижение производительности. Кроме того, приложение, состоящее из любого количества микросервисов, имеет большее количество точек интерфейса для доступа к соответствующей экосистеме , что увеличивает сложность архитектуры. Различные принципы организации (такие как HATEOAS, документация по интерфейсу и модели данных, полученная с помощью Swagger и т. Д.) Были применены, чтобы уменьшить влияние такой дополнительной сложности.
Компьютерные микросервисы могут быть реализованы на разных языках программирования и могут использовать разные инфраструктуры. Следовательно, наиболее важными технологическими решениями являются способ взаимодействия микросервисов друг с другом (синхронный, асинхронный, интеграция пользовательского интерфейса) и протоколы, используемые для взаимодействия (RESTful HTTP, обмен сообщениями, GraphQL...). В традиционной системе большинство технологических решений, таких как язык программирования, влияют на всю систему. Поэтому подход к выбору технологий совершенно иной.
Eclipse Foundation опубликовал спецификацию для разработки микросервисов Eclipse MicroProfile.
В служебной сети каждый экземпляр службы сопряжен с экземпляром обратного прокси-сервера, который называется служебным прокси, дополнительным прокси или дополнительным сервером. Экземпляр службы и дополнительный прокси-сервер совместно используют контейнер, а контейнеры управляются инструментом оркестрации контейнеров, например Kubernetes, Docker Swarm или DC / OS. Прокси-серверы службы отвечают за связь с другими экземплярами службы и могут поддерживать такие возможности, как обнаружение службы (экземпляра), балансировка нагрузки, аутентификация и авторизация, безопасная связь и другие.
В сети служб экземпляры службы и их вспомогательные прокси-серверы составляют плоскость данных, которая включает не только управление данными, но также обработку запросов и ответ. Сетка служб также включает в себя плоскость управления для управления взаимодействием между службами, опосредованным их побочными прокси. Существует несколько вариантов архитектуры служебной сети: Open Service Mesh (совместный проект Google, IBM и Lyft), Linkerd (возглавляемый проектом CNCF by), Consul (продукт HashiCorp ) и многие другие в ландшафте service mesh. Плоскость управления служебной сеткой, Meshery, обеспечивает управление жизненным циклом, конфигурацией и производительностью для развертываний служебной сети.
Реализация архитектуры микросервисов очень сложна. Существует множество проблем (см. Таблицу ниже), которые необходимо решить любой микросервисной архитектуре. Netflix разработала платформу микросервисов для поддержки своих внутренних приложений, а затем открыла исходный код многих частей этой платформы. Многие из этих инструментов были популяризированы через Spring Framework - они были повторно реализованы как инструменты на основе Spring под эгидой проекта Spring Cloud. В таблице ниже показано сравнение функции реализации из экосистемы Kubernetes с эквивалентом из мира Spring Cloud. Одним из примечательных аспектов экосистемы Spring Cloud является то, что все они являются технологиями на основе Java, тогда как Kubernetes представляет собой платформу времени выполнения многоязычных приложений.
Проблема микросервисов | Spring Cloud Netflix OSS | Kubernetes |
---|---|---|
Управление конфигурацией: конфигурация для приложения микросервисов должна быть извлечена из кода и извлечена с помощью простого вызова службы. | Spring Config Server и Netflix Archaius поддерживают расположение для конфигурации на основе репозитория Git. Archaius поддерживает типизацию данных конфигурации. | Kubernetes ConfigMaps предоставляет конфигурацию, хранящуюся в etcd, через службы. Kubernetes Secrets поддерживает безопасное развертывание на основе служб и использование конфиденциальной информации о конфигурации (такой как пароли, сертификаты и т. Д.). |
Обнаружение службы : ведение списка экземпляров службы, доступных для работы в домене микросервисов. | Spring Cloud Eureka позволяет клиентам регистрироваться в нем, поддерживает тактовый сигнал с зарегистрированными клиентами и сопоставляет имена служб с именами хостов для клиентов, которые ищут службы по имени службы. | Kubernetes Services обеспечивает регистрацию во время развертывания экземпляров сервисов, которые доступны внутри кластера. Ingress - это механизм, с помощью которого сервис может быть доступен клиентам за пределами кластера. |
Балансировка нагрузки: ключом к масштабированию распределенной системы является возможность запускать более одного экземпляра компонента. Затем нагрузка должна быть распределена между этими экземплярами с помощью балансировщика нагрузки. | Spring Cloud Ribbon позволяет клиентам службы балансировать нагрузку между экземплярами службы. | Служба Kubernetes обеспечивает возможность балансировки нагрузки между экземплярами службы. Это не эквивалент того, что предоставляет Ribbon. |
Шлюз API: детализация API, предоставляемых микросервисами, часто отличается от того, что нужно клиенту службы. Шлюзы API реализуют фасады и предоставляют дополнительные услуги, такие как прокси, трансляция протоколов и другие функции управления. | Spring Cloud Zuul предоставляет фасады API на основе конфигурации | Kubernetes Service и Ingress ресурсы, Istio, Ambassador - это решения, которые обеспечивают как север-юг (трафик в центр обработки данных и из него), так и восток – запад (трафик через центры обработки данных, облака или регионы) Функции шлюза API. |
Проблемы безопасности: Многие проблемы безопасности возложены на реализацию шлюза API. С распределенными приложениями микросервисов имеет смысл не изобретать колесо безопасности и разрешить определение и реализацию политик в компонентах, которые являются общими для всех служб. | Spring Cloud Security решает многие проблемы безопасности с помощью Spring Cloud Zuul | Экосистема Kubernetes предоставляет сервисные сети, такие как Istio, которые способны обеспечивать безопасность через свои механизмы шлюза API. |
Централизованное ведение журнала: важно иметь централизованную инфраструктуру сбора и анализа журналов для управления множеством служб, многие из которых работают в распределенном режиме. | ELK Stack (Elasticsearch, LogStash, Kibana ) | EFK Stack (Elasticsearch, Fluentd, Kibana ) |
Централизованные показатели: централизованная область, в которой можно отслеживать работоспособность и производительность отдельных сервисов и системы в целом, необходима для правильной работы. | Spring Spectator Atlas | Heapster, Prometheus, Grafana |
Распределенная трассировка: ведение журналов по процессам и мониторинг показателей имеют свое место, но ни один из них не может реконструировать сложные пути, по которым транзакции распространяются по распределенной системе. Распределенная трассировка - важный инструмент для платформы микросервисов. | Spring Cloud Sleuth | Hawkular, Jaeger |
Устойчивость и отказоустойчивость: распределенные системы должны иметь возможность автоматической маршрутизации при сбоях и маршрутизации запросов к службе. экземпляр, который обеспечит оптимальный отклик. | Spring Hystrix, Turbine, Ribbon | Проверка работоспособности, сервисные сетки (пример: Istio) |
Автомасштабирование и самовосстановление: распределенные системы реагируют на более высокую нагрузку путем горизонтального масштабирования: платформа должна обнаруживать такие условия и автоматически реагировать на них. Кроме того, системе необходимо обнаруживать сбои и предпринимать попытки автоматического перезапуска без вмешательства оператора. | - | Проверка работоспособности, самовосстановление и автоматическое масштабирование |
Упаковка, развертывание и планирование. Для крупномасштабных систем требуется надежное управление пакетами, а также системы развертывания для управления скользящим или сине-зеленым развертыванием и откатом при необходимости. Планировщик помогает определить, на каком конкретном исполнительном узле может быть развернут новый набор служб, исходя из текущих условий. | Spring Boot, Apache Maven. В системе Spring Cloud нет настоящего планировщика. | Docker, Rkt, Kubernetes Scheduler Deployment, Helm |
Управление заданиями: запланированные вычисления отключены от любых индивидуальных запросов пользователей. | Spring Batch | Задания и запланированные задания Kubernetes |
Одноэлементное приложение: ограничьте выполнение конкретной службы как единственного экземпляра этой службы во всей системе. | Spring Cloud Cluster | Kubernetes Pods |