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

В программной инженерии архитектура микросервисов — это архитектурный шаблон , который организует приложение как набор слабосвязанных , мелкозернистых сервисов, взаимодействующих через легкие протоколы . Архитектура на основе микросервисов позволяет командам разрабатывать и развертывать свои сервисы независимо, уменьшать взаимозависимость кода и повышать читаемость и модульность в кодовой базе. Это достигается за счет сокращения нескольких зависимостей в кодовой базе, что позволяет разработчикам развивать свои сервисы с ограниченными ограничениями и уменьшать дополнительную сложность. [1] Следовательно, организации могут разрабатывать программное обеспечение с быстрым ростом и масштабируемостью, а также проще реализовывать готовые сервисы. Эти преимущества сопряжены с затратами на необходимость поддержания разъединенной структуры в кодовой базе, что означает, что ее первоначальная реализация сложнее, чем у монолитной кодовой базы . [2] Интерфейсы должны быть тщательно спроектированы и рассматриваться как API .

Микросервис аналогичен ограниченному контексту в доменно-ориентированном проектировании . [3]

Определение

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

  • Службы в архитектуре микросервисов часто представляют собой процессы , которые взаимодействуют по сети для достижения цели с использованием технологически независимых протоколов, таких как HTTP . [4] [5] [6]
  • Услуги организованы вокруг бизнес-возможностей [ необходимо разъяснение ] . [7]
  • Услуги могут быть реализованы с использованием различных языков программирования , баз данных , аппаратных и программных сред, в зависимости от того, что подходит лучше всего. [8]
  • Сервисы имеют небольшой размер, поддерживают обмен сообщениями, ограничены контекстами, разрабатываются автономно, развертываются независимо, [9] [8] децентрализованы и создаются и выпускаются с использованием автоматизированных процессов . [9]
  • Микросервисы — это специализация подхода к реализации сервисно-ориентированных архитектур, используемых для создания гибких, независимо развертываемых программных систем . [7]

Микросервис не является слоем внутри монолитного приложения (например, веб-контроллера или бэкэнда для фронтэнда). [10] Скорее, это самостоятельная часть бизнес-функциональности с понятными интерфейсами, и может, через свои внутренние компоненты, реализовывать многоуровневую архитектуру. Со стратегической точки зрения, архитектура микросервисов по сути следует философии Unix «Делай одно дело и делай это хорошо». [11] Мартин Фаулер описывает архитектуру на основе микросервисов как имеющую следующие свойства: [4]

  • Подходит для непрерывного процесса разработки программного обеспечения. [12] Изменение небольшой части приложения требует только перестройки и повторного развертывания только одной или небольшого количества служб. [13]
  • Придерживается таких принципов, как мелкозернистые интерфейсы (для независимо развертываемых сервисов), разработка, ориентированная на бизнес (например, проектирование, ориентированное на домен ). [14]

Использование

Микросервисные архитектуры обычно принимаются для облачных приложений , серверных вычислений и приложений, использующих легкое развертывание контейнеров . По словам Фаулера, из-за большого количества (по сравнению с монолитными реализациями приложений) сервисов, децентрализованная непрерывная доставка и DevOps с целостным мониторингом сервисов необходимы для эффективной разработки, поддержки и эксплуатации таких приложений. [15] Следствием (и обоснованием) следования этому подходу является то, что отдельные микросервисы могут масштабироваться по отдельности. В монолитном подходе приложение, поддерживающее три функции, должно быть масштабировано полностью, даже если только одна из этих функций имеет ограничение по ресурсам. [16] С микросервисами необходимо масштабировать только микросервис, поддерживающий функцию с ограничениями по ресурсам, что обеспечивает преимущества оптимизации ресурсов и затрат. [17]

В феврале 2020 года в отчете по исследованию рынка облачных микросервисов был сделан прогноз, что объем мирового рынка архитектуры микросервисов будет увеличиваться в среднем на 21,37% в период с 2019 по 2026 год и достигнет 3,1 млрд долларов США к 2026 году. [18]

История

В 1999 году разработчик программного обеспечения Питер Роджерс работал над исследовательским проектом Dexter в Hewlett Packard Labs , целью которого было сделать код менее хрупким и сделать крупномасштабные сложные программные системы устойчивыми к изменениям. [19] В конечном итоге этот путь исследований привел к разработке ресурсно-ориентированных вычислений (ROC), обобщенной абстракции вычислений, в которой REST является особым подмножеством. В 2005 году во время презентации на конференции Web Services Edge Роджерс выступил за « REST -сервисы» и заявил, что « Программные компоненты являются микро-веб-сервисами... Микро-сервисы составлены с использованием конвейеров, подобных Unix (Web встречает Unix = настоящая слабая связь ). Сервисы могут вызывать сервисы (+многоязыковые среды выполнения). Сложные сборки сервисов абстрагируются за простыми интерфейсами URI . Любой сервис, на любой гранулярности, может быть представлен». Он описал, как хорошо спроектированная платформа микросервисов «применяет базовые архитектурные принципы веб- и REST-сервисов вместе с планированием и конвейерами в стиле Unix, чтобы обеспечить радикальную гибкость и улучшенную простоту в сервисно-ориентированных архитектурах. [20]

Также в 2005 году Алистер Кокберн написал о гексагональной архитектуре , которая является шаблоном проектирования программного обеспечения, используемым вместе с микросервисами. Этот шаблон делает возможным проектирование микросервиса, поскольку он изолирует по слоям бизнес-логику от вспомогательных сервисов, необходимых для развертывания и запуска микросервиса полностью независимо от других.

Детализация услуг

Ключевым шагом в определении архитектуры микросервисов является выяснение того, насколько большим должен быть отдельный микросервис. Для этого нет консенсуса или лакмусовой бумажки, поскольку правильный ответ зависит от бизнес- и организационного контекста. [21] Например, Amazon использует сервисно-ориентированную архитектуру, где сервис часто сопоставляется 1:1 с командой из 3–10 инженеров. [22]

Чтобы найти правильный уровень детализации сервиса, архитекторы должны постоянно итерировать свои проекты компонентов с программистами . Архитекторы должны учитывать требования пользователей, обязанности и архитектурные характеристики (т. е. нефункциональные требования ). [3]

В контексте архитектуры программного обеспечения службы, предназначенные для одной задачи, например, вызова определенной бэкэнд-системы или выполнения определенного вычисления, называются атомарными службами. Службы, которые вызывают атомарные службы для консолидации вывода, называются составными службами.

Считается плохой практикой делать сервис слишком маленьким, так как тогда накладные расходы времени выполнения и эксплуатационная сложность могут перевесить преимущества подхода. Когда сервисы становятся слишком мелкозернистыми, следует рассмотреть альтернативные подходы, такие как упаковка функции в виде библиотеки или интеграция ее в другие микросервисы. [7]

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

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

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

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

  • Модульность : Это упрощает понимание, разработку, тестирование приложения и делает его более устойчивым к разрушению архитектуры. [8] Это преимущество часто сравнивают со сложностью монолитных архитектур. [24]
  • Масштабируемость : поскольку микросервисы внедряются и развертываются независимо друг от друга, т.е. они работают в рамках независимых процессов, их можно контролировать и масштабировать независимо. [25]
  • Интеграция разнородных и устаревших систем : микросервисы считаются жизнеспособным средством модернизации существующих монолитных программных приложений. [26] [27] Имеются отчеты об опыте нескольких компаний, которые успешно заменили части своего существующего программного обеспечения микросервисами или находятся в процессе этого. [28] Процесс модернизации программного обеспечения устаревших приложений выполняется с использованием инкрементного подхода. [29]
  • Распределенная разработка: она распараллеливает разработку , позволяя небольшим автономным группам разрабатывать, развертывать и масштабировать свои соответствующие сервисы независимо. [30] Она также позволяет архитектуре отдельного сервиса возникать посредством непрерывного рефакторинга . [31] Архитектуры на основе микросервисов облегчают непрерывную интеграцию , непрерывную доставку и развертывание. [32]

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

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

  • Услуги формируют информационные барьеры. [33]
  • Межсервисные вызовы по сети имеют более высокую стоимость с точки зрения сетевой задержки и времени обработки сообщений, чем внутрипроцессные вызовы в рамках монолитного сервисного процесса. [4]
  • Тестирование и развертывание более сложны. [34] [35]
  • Передача ответственности между сервисами более сложна. [8] Это может включать в себя коммуникацию между различными командами, переписывание функциональности на другом языке или встраивание ее в другую инфраструктуру. [4] Однако микросервисы могут быть развернуты независимо от остальной части приложения, в то время как команды, работающие над монолитами, должны синхронизироваться для совместного развертывания. [29]
  • Рассмотрение размера сервисов как основного механизма структурирования может привести к слишком большому количеству сервисов, в то время как альтернатива внутренней модуляризации может привести к более простой конструкции. [36] Для этого требуется понимание общей архитектуры приложений и взаимозависимостей между компонентами. [37]
  • Двухфазные фиксации рассматриваются как антишаблон в архитектурах на основе микросервисов, что приводит к более тесной связи всех участников транзакции. Однако отсутствие этой технологии приводит к неловким танцам, которые должны быть реализованы всеми участниками транзакции для поддержания согласованности данных. [38]
  • Разработка и поддержка многих сервисов становится более сложной задачей, если они создаются с использованием разных инструментов и технологий — это особенно проблематично, если инженеры часто переключаются между проектами. [39]
  • Протокол, обычно используемый с микросервисами (HTTP), был разработан для общедоступных сервисов и, как таковой, не подходит для работы внутренних микросервисов, которые часто должны быть безупречно надежными. [40]
  • Хотя методология декомпозиции не является специфичной для микросервисов, она часто использует функциональную декомпозицию, которая не учитывает изменения в требованиях, но при этом усложняет сервисы. [40]
  • Само понятие микросервиса вводит в заблуждение, поскольку существуют только сервисы. Нет четкого определения того, когда сервис начинает или перестает быть микросервисом. [40]
  • Агрегация данных. Для того чтобы иметь полное представление о работающей системе, необходимо извлечь наборы данных из репозиториев микросервисов и объединить их в единую схему. Например, чтобы иметь возможность создавать операционные отчеты, которые невозможно создать с помощью одного репозитория микросервисов.

Сложности

Архитектура вносит дополнительную сложность и новые проблемы, с которыми приходится иметь дело, такие как задержка , дизайн формата сообщений , [41] резервное копирование /доступность/согласованность (BAC), [42] балансировка нагрузки и отказоустойчивость . [35] Все эти проблемы должны решаться в масштабе. Сложность монолитного приложения не исчезает, если оно повторно реализуется как набор микросервисов. Часть сложности преобразуется в операционную сложность. [43] Другие места, где проявляется сложность, — это увеличенный сетевой трафик, что приводит к снижению производительности. Кроме того, приложение, состоящее из любого количества микросервисов, имеет большее количество точек интерфейса для доступа к своей соответствующей экосистеме , что увеличивает архитектурную сложность. [44] Различные принципы организации (такие как гипермедиа как механизм состояния приложения (HATEOAS), документация по интерфейсу и модели данных, полученная с помощью Swagger и т. д.) были применены для уменьшения влияния такой дополнительной сложности.

Лучшие практики

По словам О'Рейли, каждый микросервис должен иметь свои собственные архитектурные характеристики (т. е. нефункциональные требования ), и архитекторы не должны определять единые характеристики для всей распределенной системы . [3]

Задержка часто измеряется с помощью «99-го процентиля», поскольку медианное и среднее значение задержки может вводить в заблуждение, поскольку они могут пропускать выбросы . [45] [ нужна страница ] [46]

Технологии

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

Фонд Eclipse опубликовал спецификацию для разработки микросервисов, Eclipse MicroProfile. [48] [49]

Сетка обслуживания

В сервисной сетке каждый экземпляр сервиса сопряжен с экземпляром обратного прокси-сервера, называемым сервисным прокси, прокси-сервером sidecar или sidecar. Экземпляр сервиса и прокси-сервер sidecar совместно используют контейнер, а контейнеры управляются инструментом оркестровки контейнеров, таким как Kubernetes , Nomad, Docker Swarm или DC/OS . Прокси-серверы сервисов отвечают за связь с другими экземплярами сервисов и могут поддерживать такие возможности, как обнаружение сервисов (экземпляров), балансировка нагрузки, аутентификация и авторизация, защищенная связь и другие.

В сервисной сетке экземпляры служб и их прокси-серверы sidecar, как говорят, составляют плоскость данных, которая включает не только управление данными, но и обработку запросов и ответ. Сервисная сетка также включает плоскость управления для управления взаимодействием между службами, опосредованным их прокси-серверами sidecar. [ необходима цитата ]

Сравнение платформ

Реализация архитектуры микросервисов очень сложна. Существует множество проблем (см. таблицу ниже), которые должна решать любая архитектура микросервисов. Netflix разработала фреймворк микросервисов для поддержки своих внутренних приложений, а затем открыла исходный код [50] многих частей этого фреймворка. Многие из этих инструментов были популяризированы через Spring Framework — они были повторно реализованы как инструменты на основе Spring под эгидой проекта Spring Cloud [51] . В таблице ниже показано сравнение реализации функции из экосистемы Kubernetes с эквивалентом из мира Spring Cloud. [52] Одним из примечательных аспектов экосистемы Spring Cloud является то, что все они основаны на Java, тогда как Kubernetes — это многоязычная платформа времени выполнения.

Микросервисы вызывают беспокойствоSpring Cloud и Netflix OSSКубернетес
Управление конфигурацией: [53] конфигурация для приложения микросервиса должна быть вынесена из кода и иметь возможность извлечения с помощью простого вызова службы.Spring Config Server, Netflix Archaius поддерживают расположение конфигурации на основе Git-репозитория. Archaius поддерживает типизацию данных конфигурации.Kubernetes ConfigMaps раскрывает конфигурацию, хранящуюся в etcd, через сервисы. Kubernetes Secrets поддерживает безопасное развертывание на основе сервисов и использование конфиденциальной информации о конфигурации (такой как пароли, сертификаты и т. д.).
Обнаружение сервисов : ведение списка экземпляров сервисов, доступных для работы в домене микросервисов.Spring Cloud Eureka позволяет клиентам регистрироваться, поддерживает связь с зарегистрированными клиентами и сопоставляет имена служб с именами хостов для клиентов, которые ищут службы по имени службы.Службы Kubernetes обеспечивают регистрацию во время развертывания экземпляров служб, которые доступны внутри кластера. Ingress — это механизм, посредством которого служба может быть представлена ​​клиентам за пределами кластера.
Балансировка нагрузки : ключ к масштабированию распределенной системы — возможность запускать более одного экземпляра компонента. Затем нагрузка должна быть распределена по этим экземплярам с помощью балансировщика нагрузки.Spring Cloud Ribbon предоставляет клиентам сервиса возможность балансировать нагрузку между экземплярами сервиса.Служба Kubernetes обеспечивает возможность балансировки нагрузки службы по всем экземплярам службы. Это не эквивалент того, что предоставляет Ribbon.
API-шлюз: Детализация API, предоставляемых микросервисами, часто отличается от того, что нужно клиенту сервиса. API-шлюзы реализуют фасады и предоставляют дополнительные сервисы, такие как проксирование, трансляция протоколов и другие функции управления.Spring Cloud Zuul предоставляет API-фасады на основе конфигурацииKubernetes Service и Ingress-ресурсы, Istio, Ambassador — это решения, которые предоставляют как север-юг (трафик в центр обработки данных и из него), так и восток-запад (трафик между центрами обработки данных, облаками или регионами) функции API-шлюза. Zuul также может быть реализован вместе с Kubernetes, обеспечивая настройку на уровне отдельных служб.
Проблемы безопасности: Многие проблемы безопасности перекладываются на реализацию шлюза API. При использовании распределенных микросервисных приложений имеет смысл не изобретать велосипед безопасности и разрешить определение и реализацию политики в компонентах, которые являются общими для всех сервисов.Spring Cloud Security решает множество проблем безопасности с помощью Spring Cloud ZuulЭкосистема Kubernetes предоставляет сервисные сети, такие как Istio, которые способны обеспечивать безопасность с помощью механизмов шлюза API.
Централизованное ведение журнала: важно иметь централизованную инфраструктуру сбора и анализа журналов для управления множеством служб, многие из которых работают распределенно.Стек ELK ( Elasticsearch , Logstash , Kibana )Стек EFK ( Elasticsearch , Fluentd , Kibana )
Централизованные показатели: для надлежащей работы необходима централизованная область, где можно отслеживать работоспособность и производительность отдельных служб и всей системы.Спринг Спектатор и АтласХипстер, Прометей и Графана
Распределенная трассировка: ведение журнала по процессам и мониторинг метрик имеют свое место, но ни то, ни другое не может реконструировать сложные пути, по которым проходят транзакции при распространении по распределенной системе. Распределенная трассировка является важным инструментом для платформы микросервисов.Весенний Облачный СыщикЯстреб, Йегер
Устойчивость к сбоям и отказам: распределенные системы должны иметь возможность автоматической маршрутизации в обход сбоев и маршрутизации запросов к экземпляру службы, который обеспечит оптимальный ответ.Пружинный Hystrix, турбина и лентаПроверка работоспособности, сервисные сетки (пример: Istio) [54]
Автомасштабирование и самовосстановление: распределенные системы реагируют на более высокую нагрузку путем горизонтального масштабирования: платформа должна обнаруживать и автоматически реагировать на такие условия. Кроме того, система должна обнаруживать сбои и пытаться автоматически перезапускаться без участия оператора.-Проверка работоспособности, самовосстановление и автоматическое масштабирование
Упаковка, развертывание и планирование: крупномасштабные системы требуют надежного управления пакетами и систем развертывания для управления скользящими или сине-зелеными развертываниями и откатами при необходимости. Планировщик помогает определить, на каком конкретно узле выполнения может быть развернут новый набор служб на основе текущих условий.Spring Boot, Apache Maven. Система Spring Cloud не имеет настоящего планировщика.Docker, Rkt, Планировщик и развертывание Kubernetes, Helm [55]
Управление заданиями: запланированные вычисления, не привязанные к отдельным запросам пользователей.Весенняя партияЗадания Kubernetes и запланированные задания
Приложение-одиночка: ограничение работы определенной службы как единственного экземпляра этой службы во всей системе.Весеннее скопление облаковМодули Kubernetes

Смотрите также

Ссылки

  1. ^ «Микросервисные архитектуры: больше, чем сумма их частей?». IONOS Digitalguide . 2 марта 2020 г. Получено 29.03.2022 .
  2. ^ Фаулер, Мартин (2002). Модели архитектуры корпоративных приложений . Addison-Wesley Professional. ISBN 978-0321127426.
  3. ^ abc Основы архитектуры программного обеспечения: инженерный подход . O'Reilly Media. 2020. ISBN 978-1492043454.
  4. ^ abcd Мартин Фаулер. "Микросервисы". Архивировано из оригинала 14 февраля 2018 года.
  5. ^ Ньюман, Сэм (2015-02-20). Создание микросервисов . O'Reilly Media. ISBN 978-1491950357.
  6. ^ Вольф, Эберхард (2016-10-12). Микросервисы: гибкие архитектуры программного обеспечения . Addison-Wesley. ISBN 978-0134602417.
  7. ^ abc Pautasso, Cesare (2017). «Микросервисы на практике, часть 1: проверка реальности и проектирование сервисов». IEEE Software . 34 (1): 91–98. doi :10.1109/MS.2017.24. S2CID  5635705.
  8. ^ abcd Чен, Ляньпин (2018). Микросервисы: Архитектура для непрерывной доставки и DevOps. Международная конференция IEEE по архитектуре программного обеспечения (ICSA 2018). IEEE.
  9. ^ ab Надареишвили, И., Митра, Р., Макларти, М., Амундсен, М., Архитектура микросервисов: согласование принципов, практик и культуры, O'Reilly 2016
  10. ^ "Шаблон бэкэндов для фронтэндов". Шаблоны проектирования облака Microsoft Azure . Microsoft.
  11. ^ Лукас Краузе. Микросервисы: шаблоны и приложения . ASIN  B00VJ3NP4A.
  12. ^ Форд, Н.; Ричардс, М.; Садалаге, П.; Дехгани, З. «Архитектура программного обеспечения: сложные детали». Thoughtworks . Получено 20 января 2023 г.
  13. ^ "CI/CD для архитектур микросервисов", Azure Architecture Center, Microsoft . Получено 9 января 2018 г.
  14. ^ Джосуттис, Н. (2007). SOA на практике. Севастополь, Калифорния, США: О'Рейли. ISBN 978-0-596-52955-0 . 
  15. ^ Мартин Фаулер (28 августа 2014 г.). «Предварительные условия микросервисов». Архивировано из оригинала 3 октября 2023 г.
  16. ^ Ричардсон, Крис (ноябрь 2018 г.). Шаблоны микросервисов . Manning Publications. 1.4.1 Масштаб куба и микросервисы. ISBN 9781617294549.
  17. ^ Мендонка, Набор К.; Джамшиди, Пуян; Гарлан, Дэвид; Пал, Клаус (16 октября 2019 г.). «Разработка самоадаптивных микросервисных систем: проблемы и направления». IEEE Software . 38 (2): 70–79. arXiv : 1910.07660 . doi :10.1109/MS.2019.2955937. S2CID  204744007.
  18. ^ Исследование, проверенный рынок. «Тенденции рынка облачных микросервисов 2020 года, доля рынка, размер отрасли, возможности, анализ и прогноз к 2026 году – мгновенные новости рынка технологий» . Получено 18.02.2020 .
  19. ^ Рассел, Перри; Роджерс, Питер; Селлман, Ройстон (2004). «Архитектура и проектирование платформы приложений XML». Технические отчеты HP . стр. 62. Получено 20 августа 2015 г.
  20. ^ Роджерс, Питер (15 февраля 2005 г.). «Сервисно-ориентированная разработка на NetKernel — шаблоны, процессы и продукты для снижения сложности системы». CloudComputingExpo . SYS-CON Media. Архивировано из оригинала 20 мая 2018 г. . Получено 19 августа 2015 г. .
  21. ^ О. Циммерманн, Декомпозиция сервиса, специфичного для предметной области, с использованием шаблонов API микросервисов, Микросервисы 2019, https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
  22. ^ "Мандат Amazon SOA". 13 октября 2011 г.
  23. ^ Вон, Вернон (2016). Domain-Driven Design Distilled . Addison-Wesley Professional. ISBN 978-0-13-443442-1.
  24. ^ Юсиф, Мазин (2016). «Микросервисы». IEEE Cloud Computing . 3 (5): 4–5. doi :10.1109/MCC.2016.101.
  25. ^ Dragoni, Nicola; Lanese, Ivan; Larsen, Stephan Thordal; Mazzara, Manuel; Mustafin, Ruslan; Safina, Larisa (2017). "Микросервисы: как сделать ваше приложение масштабируемым" (PDF) . Perspectives of System Informatics . Lecture Notes in Computer Science. Vol. 10742. pp. 95–104. arXiv : 1702.07149 . Bibcode : 2017arXiv170207149D. doi : 10.1007/978-3-319-74313-4_8. ISBN 978-3-319-74312-7. S2CID  1643730.
  26. ^ Ньюман, Сэм (2015). Создание микросервисов . O'Reilly. ISBN 978-1491950357.
  27. ^ Вольф, Эберхард (2016). Микросервисы: гибкая архитектура программного обеспечения . Эддисон Уэсли. ISBN 978-0134602417.
  28. ^ Кнохе, Хольгер; Хассельбринг, Вильгельм (2019). «Драйверы и барьеры для внедрения микросервисов — опрос среди профессионалов в Германии». Моделирование предприятий и архитектура информационных систем . 14 : 1:1–35–1:1–35. doi :10.18417/emisa.14.1.
  29. ^ ab Taibi, Davide; Lenarduzzi, Valentina; Pahl, Claus; Janes, Andrea (2017). «Микросервисы в гибкой разработке программного обеспечения: исследование проблем, преимуществ и недостатков на основе семинаров». Труды научных семинаров XP2017 . doi :10.1145/3120459.3120483. S2CID  28134110.
  30. ^ Ричардсон, Крис. "Шаблон архитектуры микросервисов". microservices.io . Получено 19.03.2017 .
  31. ^ Чен, Ляньпин; Али Бабар, Мухаммад (2014). «К пониманию возникновения архитектуры на основе фактических данных посредством непрерывного рефакторинга в гибкой разработке программного обеспечения». Труды рабочей конференции IEEE/IFIP по архитектуре программного обеспечения 2014 WICSA 2014. 11-я рабочая конференция IEEE/IFIP по архитектуре программного обеспечения (WICSA 2014). IEEE. doi :10.1109/WICSA.2014.45.
  32. ^ Балалайе, Армин; Хейдарноори, Аббас; Джамшиди, Пуян (май 2016 г.). «Архитектура микросервисов позволяет использовать DevOps: миграция в облачную архитектуру» (PDF) . IEEE Software . 33 (3): 42–52. doi :10.1109/ms.2016.64. hdl :10044/1/40557. ISSN  0740-7459. S2CID  18802650.
  33. ↑ Стенберг, Ян (11 августа 2014 г.). «Опыт неудач с микросервисами».
  34. ^ Каландра, Мариано (7 апреля 2021 г.). «Почему модульного тестирования недостаточно, когда речь идет о микросервисах».
  35. ^ ab «Разработка микросервисов для PaaS с помощью Spring и Cloud Foundry».
  36. ^ Тилков, Стефан (17 ноября 2014 г.). «Насколько маленьким должен быть ваш микросервис?». Innoq . Получено 4 января 2017 г.
  37. ^ Ланца, Мишель; Дюкасс, Стефан (2002). «Понимание эволюции программного обеспечения с использованием комбинации визуализации программного обеспечения и метрик программного обеспечения» (PDF) . В трудах LMO 2002 (Langages et Modèles à Objets) : 135–149. Архивировано из оригинала (PDF) 27 февраля 2021 г.
  38. ^ Ричардсон, Крис (ноябрь 2018 г.). "Глава 4. Управление транзакциями с помощью саг". Шаблоны микросервисов . Manning Publications. ISBN 978-1-61729454-9.
  39. ^ Devoxx (30 августа 2017 г.). «10 советов Дэвида Шмитца о том, как потерпеть неудачу в микросервисах». YouTube . Архивировано из оригинала 22 апреля 2021 г.
  40. ^ abc Löwy, Juval (2019). Righting Software 1-е изд . Addison-Wesley Professional. стр. 73–75. ISBN 978-0136524038.
  41. ^ Паутассо, Чезаре (2017). «Микросервисы на практике, часть 2: интеграция сервисов и устойчивость». IEEE Software . 34 (2): 97–104. doi :10.1109/MS.2017.56. S2CID  30256045.
  42. ^ Паутассо, Чезаре (2018). «Последовательное аварийное восстановление для микросервисов: теорема BAC». IEEE Cloud Computing . 5 (1): 49–59. doi :10.1109/MCC.2018.011791714. S2CID  4560021.
  43. ^ Фаулер, Мартин . «Компромиссы микросервисов».
  44. ^ "BRASS Building Resource Adaptive Software Systems". Правительство США. DARPA. 7 апреля 2015 г.«Однако доступ к системным компонентам и интерфейсам между клиентами и их приложениями осуществляется посредством ряда часто не связанных между собой механизмов, включая неофициально документированные интерфейсы прикладного программирования (API), своеобразные интерфейсы внешних функций, сложные плохо понимаемые определения моделей или специальные форматы данных. Эти механизмы обычно обеспечивают лишь частичное и неполное понимание семантики самих компонентов. При наличии такой сложности неудивительно, что приложения обычно включают в себя множество предположений об ожидаемом поведении экосистемы, с которой они взаимодействуют».
  45. ^ Витильо, Роберто (2021). Понимание распределенных систем: что каждый разработчик должен знать о больших распределенных приложениях . Роберто Витильо. ISBN 978-1838430207.
  46. ^ Бхаргав, Нихил (2024-03-18). "Что такое задержка P99?". baeldung.com . Получено 2024-06-08 . Среднее значение и медиана часто маскируют выбросы
  47. ^ Вольф, Эберхард (2018-04-15). Микросервисы — практическое руководство. CreateSpace Independent Publishing Platform. ISBN 978-1717075901.
  48. ^ Сварт, Стефани (14 декабря 2016 г.). «Eclipse MicroProfile». projects.eclipse.org .
  49. ^ "MicroProfile". MicroProfile . Получено 2021-04-11 .
  50. ^ Netflix OSS, Git Hub
  51. ^ Облако, Весна
  52. ^ "Spring Cloud для микросервисов в сравнении с Kubernetes", Разработчики , Red Hat, 2016-12-09
  53. ^ Сомашекар, Гаган; Ганди, Аншул (2021-04-26). «На пути к оптимальной конфигурации микросервисов». Труды 1-го семинара по машинному обучению и системам . EuroMLSys '21. Онлайн, Соединенное Королевство: Ассоциация вычислительной техники. стр. 7–14. doi :10.1145/3437984.3458828.
  54. ^ Управление микросервисами с помощью сервисной сети Istio, Kubernetes, май 2017 г.
  55. ^ Менеджер пакетов Kubernetes, Helm

Дальнейшее чтение

  • Специальный тематический выпуск по микросервисам, IEEE Software 35(3), май/июнь 2018 г., https://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=8354413
  • И. Надареишвили и др., Архитектура микросервисов – согласование принципов, практик и культуры, O'Reilly, 2016, ISBN 978-1-491-95979-4 
  • С. Ньюман, Создание микросервисов – Проектирование мелкозернистых систем, O'Reilly, 2015 ISBN 978-1491950357 
  • Виджесурия, Вирадж Брайан (29.08.2016) Архитектура микросервисов, конспект лекций - Высшая школа вычислительной техники Университета Коломбо, Шри-Ланка
  • Christudas Binildas (27 июня 2019 г.). Практические архитектурные шаблоны микросервисов: основанные на событиях микросервисы Java с Spring Boot и Spring Cloud. Apress. ISBN 978-1484245002 . 
Взято с "https://en.wikipedia.org/w/index.php?title=Микросервисы&oldid=1252628800"