Микросервисы

редактировать
Набор слабо связанных сервисов, используемых для создания компьютерных приложений

Архитектура микросервисов - вариант сервиса Структурный стиль -ориентированная архитектура (SOA) - упорядочивает приложение как набор слабо связанных сервисов. В архитектуре микросервисов сервисы детализированы, а протоколы легковесны.

Содержание

  • 1 Введение
  • 2 История
  • 3 Детализация услуг
  • 4 Преимущества
  • 5 Критика и опасения
    • 5.1 Когнитивная нагрузка
  • 6 Технологии
    • 6.1 Сервисная сеть
    • 6.2 Сравнение платформ
  • 7 См. Также
  • 8 Ссылки
  • 9 Дополнительная литература

Введение

Единого определения микросервисов не существует. Со временем в отрасли сформировалось консенсусное мнение. Некоторые из определяющих характеристик, которые часто упоминаются, включают:

  • Сервисы в микросервисной архитектуре (MSA) часто являются процессами, которые обмениваются данными по сети для достижения цели, используя независимые технологии. протоколы, например HTTP.
  • Службы организованы вокруг бизнес-возможностей.
  • Службы могут быть реализованы с использованием различных языков программирования, баз данных, аппаратная и программная среда, в зависимости от того, что подходит лучше всего.
  • Услуги имеют небольшой размер, поддерживают обмен сообщениями, ограничены контекстами, разрабатываются автономно, независимо развертываются, децентрализованы и созданы и выпущен с автоматизированными процессами.

Микрослужба не является слоем внутри монолитного приложения (например, веб-контроллера или серверной части для внешнего интерфейса). Скорее, это автономная часть бизнес-функциональности с понятными интерфейсами, которая может через свои внутренние компоненты реализовывать многоуровневую архитектуру. С точки зрения стратегии, архитектура микросервисов по существу следует философии 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 инженеров.

Это считается плохим Практика, чтобы сделать сервис слишком маленьким, так как тогда накладные расходы времени выполнения и операционная сложность могут подавить преимущества подхода. Когда все становится слишком детализированным, необходимо рассмотреть альтернативные подходы, такие как упаковка функции в виде библиотеки, перенос функции в другие микросервисы.

Если используется доменное проектирование при моделировании домена, для которого создается система, микросервис может быть таким маленьким, как Агрегат, или таким большим, как Ограниченный контекст.

Преимущества

Преимущество декомпозиции приложения на существует множество различных более мелких сервисов:

  • Модульность : это упрощает понимание, разработку, тестирование приложения и делает его более устойчивым к эрозии архитектуры. Это преимущество часто сравнивают со сложностью монолитных архитектур.
  • Масштабируемость : поскольку микросервисы реализуются и развертываются независимо друг от друга, т. Е. Выполняются в рамках независимых процессов, их можно отслеживать и масштабировать независимо.
  • Интеграция разнородных и устаревших систем : микросервисы рассматриваются как жизнеспособное средство модернизации существующего монолитного программного обеспечения. Имеются отчеты об опыте нескольких компаний, которые успешно заменили (части) своего существующего программного обеспечения микросервисами или находятся в процессе этого. Процесс модернизации программного обеспечения унаследованных приложений выполняется с использованием поэтапного подхода.
  • Распределенная разработка: он распараллеливает разработку, позволяя разрабатывать небольшим автономным командам, развернуть и независимо масштабировать соответствующие службы. Это также позволяет создавать архитектуру отдельной службы посредством непрерывного рефакторинга. Архитектура на основе микросервисов облегчает непрерывную интеграцию, непрерывную доставку и развертывание.

Критика и опасения

Подход микросервисов подвергается критике по ряду вопросов:

  • Услуги образуют информационные барьеры.
  • Межсервисные вызовы по сети имеют более высокие затраты с точки зрения задержки сети и времени обработки сообщений, чем внутрипроцессные вызовы в пределах монолитный процесс обслуживания.
  • Тестирование и развертывание более сложны.
  • Сложнее переносить обязанности между сервисами. Это может включать в себя общение между разными командами, переписывание функциональности на другом языке или приспособление ее к другой инфраструктуре. Однако микросервисы могут быть развернуты независимо от остального приложения, в то время как группы, работающие над монолитами, должны синхронизироваться для совместного развертывания.
  • Просмотр размера сервисов как основного механизма структурирования может привести к слишком большому количеству сервисов, когда альтернатива внутренней модуляции может привести к упрощению конструкции. Это требует использования приложений, помогающих понять общую архитектуру приложений и взаимозависимости между компонентами.
  • Двухэтапные фиксации рассматриваются как антишаблон в архитектурах на основе микросервисов, поскольку это приводит к более тесной связи всех участники сделки. Однако отсутствие этой технологии вызывает неудобные танцы, которые должны быть реализованы всеми участниками транзакции, чтобы поддерживать согласованность данных.
  • Разработка и поддержка многих служб становятся более сложными, если они созданы с использованием различных инструментов и технологий. - это особенно проблема, если инженеры часто переключаются между проектами.
  • Протокол, обычно используемый с микросервисами (HTTP), был разработан для общедоступных сервисов и поэтому не подходит для работы внутренних микросервисов, которые часто должны быть безупречными. надежно.
  • Методология декомпозиции, не относящаяся к микросервисам, часто использует функциональную декомпозицию, которая не учитывает изменения требований, но при этом усложняет сервисы.
  • Сама концепция микросервиса является вводит в заблуждение, так как есть только сервисы. Нет четкого определения того, когда служба запускается или перестает быть микросервисом.

Когнитивная нагрузка

Архитектура привносит дополнительную сложность и новые проблемы, с которыми приходится иметь дело, например, задержка сети, формат сообщения дизайн, резервное копирование / доступность / согласованность (BAC), балансировка нагрузки и отказоустойчивость. Все эти проблемы необходимо решать масштабно. Сложность монолитного приложения не исчезнет, ​​если оно будет повторно реализовано как набор приложений микросервисов. Некоторая сложность превращается в сложность эксплуатации. Другие места, где проявляется сложность, - это увеличение сетевого трафика и, как следствие, снижение производительности. Кроме того, приложение, состоящее из любого количества микросервисов, имеет большее количество точек интерфейса для доступа к соответствующей экосистеме , что увеличивает сложность архитектуры. Различные принципы организации (такие как HATEOAS, документация по интерфейсу и модели данных, полученная с помощью Swagger и т. Д.) Были применены, чтобы уменьшить влияние такой дополнительной сложности.

Технологии

Компьютерные микросервисы могут быть реализованы на разных языках программирования и могут использовать разные инфраструктуры. Следовательно, наиболее важными технологическими решениями являются способ взаимодействия микросервисов друг с другом (синхронный, асинхронный, интеграция пользовательского интерфейса) и протоколы, используемые для взаимодействия (RESTful HTTP, обмен сообщениями, GraphQL...). В традиционной системе большинство технологических решений, таких как язык программирования, влияют на всю систему. Поэтому подход к выбору технологий совершенно иной.

Eclipse Foundation опубликовал спецификацию для разработки микросервисов Eclipse MicroProfile.

Service mesh

В служебной сети каждый экземпляр службы сопряжен с экземпляром обратного прокси-сервера, который называется служебным прокси, дополнительным прокси или дополнительным сервером. Экземпляр службы и дополнительный прокси-сервер совместно используют контейнер, а контейнеры управляются инструментом оркестрации контейнеров, например 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 OSSKubernetes
Управление конфигурацией: конфигурация для приложения микросервисов должна быть извлечена из кода и извлечена с помощью простого вызова службы.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 AtlasHeapster, Prometheus, Grafana
Распределенная трассировка: ведение журналов по процессам и мониторинг показателей имеют свое место, но ни один из них не может реконструировать сложные пути, по которым транзакции распространяются по распределенной системе. Распределенная трассировка - важный инструмент для платформы микросервисов.Spring Cloud SleuthHawkular, Jaeger
Устойчивость и отказоустойчивость: распределенные системы должны иметь возможность автоматической маршрутизации при сбоях и маршрутизации запросов к службе. экземпляр, который обеспечит оптимальный отклик.Spring Hystrix, Turbine, RibbonПроверка работоспособности, сервисные сетки (пример: Istio)
Автомасштабирование и самовосстановление: распределенные системы реагируют на более высокую нагрузку путем горизонтального масштабирования: платформа должна обнаруживать такие условия и автоматически реагировать на них. Кроме того, системе необходимо обнаруживать сбои и предпринимать попытки автоматического перезапуска без вмешательства оператора.-Проверка работоспособности, самовосстановление и автоматическое масштабирование
Упаковка, развертывание и планирование. Для крупномасштабных систем требуется надежное управление пакетами, а также системы развертывания для управления скользящим или сине-зеленым развертыванием и откатом при необходимости. Планировщик помогает определить, на каком конкретном исполнительном узле может быть развернут новый набор служб, исходя из текущих условий.Spring Boot, Apache Maven. В системе Spring Cloud нет настоящего планировщика.Docker, Rkt, Kubernetes Scheduler Deployment, Helm
Управление заданиями: запланированные вычисления отключены от любых индивидуальных запросов пользователей.Spring BatchЗадания и запланированные задания Kubernetes
Одноэлементное приложение: ограничьте выполнение конкретной службы как единственного экземпляра этой службы во всей системе.Spring Cloud ClusterKubernetes Pods

См. Также

Ссылки

Дополнительная литература

Последняя правка сделана 2021-05-30 10:10:19
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте