Архитектура микросервисов - вариант структурного стиля сервис-ориентированной архитектуры (SOA) - организует приложение как набор слабосвязанных сервисов. В архитектуре микросервисов сервисы детализированы, а протоколы легковесны .
Вступление
Единого определения микросервисов нет. Со временем в отрасли сформировалось консенсусное мнение. Некоторые из определяющих характеристик, которые часто упоминаются, включают:
- Сервисы в микросервисной архитектуре (MSA) часто представляют собой процессы, которые обмениваются данными по сети для достижения цели с использованием независимых от технологии протоколов, таких как HTTP. [1] [2] [3]
- Услуги организованы вокруг бизнес-возможностей. [4]
- Услуги могут быть реализованы с использованием разных языков программирования , баз данных , аппаратной и программной среды, в зависимости от того, что подходит лучше всего. [5]
- Сервисы имеют небольшой размер, поддерживают обмен сообщениями, ограничены контекстом, разрабатываются автономно, развертываются независимо, [6] [5] децентрализованы и создаются и выпускаются с автоматизированными процессами . [6]
Микросервис - это не уровень внутри монолитного приложения (например, веб-контроллера или внутреннего интерфейса для внешнего интерфейса). [7] Скорее, это автономная часть бизнес-функциональности с понятными интерфейсами, которая может через свои внутренние компоненты реализовывать многоуровневую архитектуру. С точки зрения стратегии, архитектура микросервисов по существу следует философии Unix «Делай одно и делай это хорошо». [8] Мартин Фаулер описывает архитектуру на основе микросервисов как имеющую следующие свойства: [1]
- Поддается непрерывному процессу разработки программного обеспечения. Изменение небольшой части приложения требует перестройки и повторного развертывания только одной или небольшого количества служб. [9]
- Придерживается таких принципов, как детализированные интерфейсы (для независимо развертываемых сервисов), разработка, управляемая бизнесом (например , проектирование на основе предметной области ). [10]
Архитектура микросервисов обычно применяется для облачных приложений , бессерверных вычислений и приложений, использующих облегченное развертывание контейнеров . По словам Фаулера, из-за большого количества (по сравнению с реализациями монолитных приложений) сервисов для эффективной разработки, поддержки и эксплуатации таких приложений необходимы децентрализованная непрерывная доставка и DevOps с целостным мониторингом сервисов. [11] Следствием (и обоснованием) такого подхода является возможность индивидуального масштабирования отдельных микросервисов. При монолитном подходе приложение, поддерживающее три функции, должно быть полностью масштабировано, даже если только одна из этих функций имеет ограничение ресурсов. [12] При использовании микросервисов необходимо масштабировать только микросервис, поддерживающий функцию с ограниченными ресурсами, что обеспечивает преимущества по оптимизации ресурсов и затрат. [13]
История
Существует множество заявлений о происхождении микросервисов. В 2004 году, будучи вице-президентом ThoughtWorks , Фред Джордж начал работать над архитектурой прототипа микросервисов, основанной на том, что он назвал «Baysean Principals» в честь Джеффа Бэя. [14]
Уже в 2005 году Питер Роджерс ввел термин «Микро- Web-служб » во время презентации на конференции Web Services Edge. Вопреки традиционному мышлению и на пике шумихи вокруг архитектуры SOAP SOA он выступал за «REST-сервисы», а на слайде № 4 презентации конференции он обсуждает « Программные компоненты - это Micro-Web-Services». [15] Далее он говорит: «Микросервисы состоят из Unix-подобных конвейеров ( Интернет встречает Unix = истинная слабая связь ). Сервисы могут вызывать сервисы (+ многоязычная среда выполнения). Сложные сервисные сборки абстрагируются. за простыми интерфейсами URI . Может быть предоставлена любая услуга на любой степени детализации ". Он описал, как хорошо спроектированная платформа микросервисов «применяет основные архитектурные принципы Web-сервисов и REST-сервисов вместе с Unix-подобным планированием и конвейерами для обеспечения радикальной гибкости и повышенной простоты сервис-ориентированных архитектур [16].
Работа Роджерса началась в 1999 году с исследовательского проекта Декстера в Hewlett Packard Labs , целью которого было сделать код менее уязвимым и сделать крупномасштабные сложные программные системы устойчивыми к изменениям. [17] В конечном итоге этот путь исследований привел к развитию ресурсо-ориентированных вычислений (ROC), обобщенной абстракции вычислений, в которой REST является особым подмножеством.
В 2007 году Юваль Леви в своих письмах [18] и выступлениях [19] [20] призвал к построению систем, в которых каждый класс был бы службой. Леви понял, что это требует использования технологии, которая может поддерживать такое детальное использование сервисов, и он расширил Windows Communication Foundation (WCF), чтобы делать именно это [21] [22], беря каждый класс и рассматривая его как сервис, сохраняя при этом общепринятая модель программирования классов.
На семинаре архитекторов программного обеспечения, проведенном недалеко от Венеции в мае 2011 года, термин «микросервис» использовался для описания того, что участники считали общим архитектурным стилем, который многие из них недавно изучали. [23] В мае 2012 года та же группа выбрала «микросервисы» как наиболее подходящее название. Джеймс Льюис представил некоторые из этих идей в качестве тематического исследования в марте 2012 года на 33-м градусе в Кракове, посвященном микросервисам - Java, Unix Way [24], как и Фред Джордж [25] примерно в то же время. Адриан Кокрофт , бывший директор по облачным системам в Netflix, [26] описал этот подход как «мелкозернистую SOA», впервые применил стиль в веб-масштабе, как и многие другие, упомянутые в этой статье - Джо Уолнес, Дэн Норт, Эван Ботчер и Грэм Такли. [27]
Микросервисы - это специализация подхода к реализации сервисно-ориентированных архитектур (SOA), используемая для создания гибких, независимо развертываемых программных систем . [4] Подход с использованием микросервисов - это первая реализация SOA, которая последовала за появлением DevOps и становится все более популярной для создания непрерывно развертываемых систем. [28]
В феврале 2020 года в отчете об исследовании рынка облачных микросервисов было предсказано, что размер мирового рынка микросервисных архитектур будет расти со среднегодовым темпом роста 21,37% с 2019 по 2026 год и достигнет 3,1 миллиарда долларов к 2026 году [29].
Детализация сервиса
Ключевым шагом в определении архитектуры микросервисов является определение размера отдельного микросервиса. Для этого нет консенсуса или лакмусовой бумажки, поскольку правильный ответ зависит от бизнес-среды и организационного контекста. [30] Например, Amazon широко использует сервис-ориентированную архитектуру, в которой сервис часто сопоставляется 1: 1 с командой от 3 до 10 инженеров. [31] Как правило, терминология такова: службы, предназначенные для выполнения одной задачи, например, вызов определенной серверной системы или выполнение определенного типа вычислений, называются атомарными службами . Точно так же сервисы, которые вызывают такие атомарные сервисы для консолидации вывода, называются составными сервисами .
Считается плохой практикой делать сервис слишком маленьким, поскольку в этом случае накладные расходы времени выполнения и операционная сложность могут подавить преимущества такого подхода. Когда все становится слишком детализированным, необходимо рассмотреть альтернативные подходы - такие как упаковка функции в виде библиотеки, перемещение функции в другие микросервисы. [4]
Если при моделировании домена, для которого строится система, используется дизайн, управляемый доменом, то микросервис может быть таким маленьким, как агрегат, или таким большим, как ограниченный контекст. [32]
Преимущества
Преимущества декомпозиции приложения на различные более мелкие службы многочисленны:
- Модульность : это упрощает понимание, разработку, тестирование приложения и делает его более устойчивым к эрозии архитектуры. [5] Об этом преимуществе часто говорят по сравнению со сложностью монолитных архитектур. [33]
- Масштабируемость : поскольку микросервисы реализуются и развертываются независимо друг от друга, т. Е. Выполняются в рамках независимых процессов, их можно отслеживать и масштабировать независимо. [34]
- Интеграция разнородных и унаследованных систем : микросервисы считаются эффективным средством модернизации существующего монолитного программного обеспечения. [35] [36] Имеются отчеты об опыте нескольких компаний, которые успешно заменили (части) своего существующего программного обеспечения микросервисами или находятся в процессе этого. [37] Процесс модернизации программного обеспечения унаследованных приложений выполняется с использованием поэтапного подхода. [38]
- Распределенная разработка: он распараллеливает разработку , позволяя небольшим автономным командам самостоятельно разрабатывать, развертывать и масштабировать свои соответствующие службы. [39] Это также позволяет создавать архитектуру отдельного сервиса посредством непрерывного рефакторинга . [40] Архитектура на основе микросервисов способствует непрерывной интеграции , непрерывной доставке и развертыванию. [41]
Критика и опасения
Подход микросервисов подвергается критике по ряду вопросов:
- Услуги образуют информационные барьеры. [42]
- Межсервисные вызовы по сети имеют более высокие затраты с точки зрения задержки сети и времени обработки сообщений, чем внутрипроцессные вызовы в рамках монолитного процесса обслуживания. [1]
- Тестирование и развертывание сложнее. [43] [44]
- Сложнее переносить обязанности между службами. [5] Это может включать в себя общение между разными командами, переписывание функциональности на другом языке или приспособление ее к другой инфраструктуре. [1] Однако микросервисы могут быть развернуты независимо от остальной части приложения, в то время как командам, работающим над монолитами, необходимо выполнить синхронизацию для совместного развертывания. [45]
- Рассмотрение размера сервисов как основного механизма структурирования может привести к слишком большому количеству сервисов, тогда как альтернатива внутренней модуляции может привести к более простой конструкции. [46] Это требует использования приложений, помогающих понять общую архитектуру приложений и взаимозависимости между компонентами. [47]
- Двухэтапные фиксации рассматриваются как антипаттерн в архитектурах на основе микросервисов, поскольку это приводит к более тесной связи всех участников внутри транзакции. Однако отсутствие этой технологии вызывает неудобные танцы, которые должны быть реализованы всеми участниками транзакции для поддержания согласованности данных. [48]
- Разработка и поддержка многих сервисов сложнее, если они созданы с использованием разных инструментов и технологий - это особенно проблема, если инженеры часто переходят между проектами. [49]
- Протокол, обычно используемый с микрослужбами (HTTP), был разработан для общедоступных служб и поэтому не подходит для работы внутренних микросервисов, которые часто должны быть безупречно надежными. [50]
- Методология декомпозиции, не относящаяся к микросервисам, часто использует функциональную декомпозицию, которая не обрабатывает изменения требований, но при этом усложняет сервисы. [51]
- Само понятие микросервиса вводит в заблуждение, так как есть только сервисы. Нет четкого определения того, когда служба запускается или перестает быть микросервисом. [52]
Познавательная нагрузка
Архитектура привносит дополнительную сложность и новые проблемы, с которыми приходится иметь дело, например, задержка в сети , дизайн формата сообщений , [53] резервное копирование / доступность / согласованность (BAC), [54] балансировка нагрузки и отказоустойчивость . [44] Все эти проблемы необходимо решать масштабно. Сложность монолитного приложения не исчезнет, если оно будет повторно реализовано в виде набора микросервисных приложений. Некоторая сложность превращается в операционную сложность. [55] Другие места, где проявляется сложность, - это увеличение сетевого трафика и, как следствие, снижение производительности. Кроме того, приложение, состоящее из любого количества микросервисов, имеет большее количество точек интерфейса для доступа к соответствующей экосистеме , что увеличивает архитектурную сложность. [56] Различные принципы организации (такие как HATEOAS , документация по интерфейсу и модели данных, полученная с помощью Swagger и т. Д.) Были применены, чтобы уменьшить влияние такой дополнительной сложности.
Технологии
Компьютерные микросервисы могут быть реализованы на разных языках программирования и могут использовать разные инфраструктуры. Следовательно, наиболее важными технологическими решениями являются способ взаимодействия микросервисов друг с другом (синхронный, асинхронный, интеграция пользовательского интерфейса) и протоколы, используемые для взаимодействия ( RESTful HTTP, обмен сообщениями, GraphQL ...). В традиционной системе большинство технологических решений, таких как язык программирования, влияют на всю систему. Поэтому подход к выбору технологий совсем другой. [57]
Фонд Eclipse , опубликовал спецификации для разработки microservices, Eclipse , микрорельеф. [58] [59]
Сервисная сетка
В служебной сети каждый экземпляр службы сопряжен с экземпляром обратного прокси-сервера, который называется служебным прокси, дополнительным прокси или дополнительным сервером. Экземпляр службы и дополнительный прокси-сервер совместно используют контейнер, а контейнеры управляются инструментом оркестровки контейнеров, таким как Kubernetes , Nomad , Docker Swarm или DC / OS . Прокси-серверы службы отвечают за связь с другими экземплярами службы и могут поддерживать такие возможности, как обнаружение службы (экземпляра), балансировка нагрузки, аутентификация и авторизация, безопасная связь и другие.
В сети служб экземпляры службы и их вспомогательные прокси-серверы составляют плоскость данных, которая включает в себя не только управление данными, но также обработку запросов и ответ. Сетка служб также включает в себя плоскость управления для управления взаимодействием между службами, опосредованным их дополнительными прокси-серверами. Существует несколько вариантов архитектуры сервисной сети: Open Service Mesh , Istio (совместный проект Google, IBM и Lyft), Linkerd (проект CNCF под руководством Buoyant [60] ), Consul ( продукт HashiCorp ) и многие другие в службы сетки пейзаж . Плоскость управления служебной сеткой, Meshery , обеспечивает управление жизненным циклом, конфигурацией и производительностью в развертываниях служебной сети.
Сравнение платформ
Реализовать микросервисную архитектуру очень сложно. Существует множество проблем (см. Таблицу ниже), которые необходимо решить любой микросервисной архитектуре. Netflix разработала платформу микросервисов для поддержки своих внутренних приложений, а затем предоставила открытый исходный код [61] для многих ее частей. Многие из этих инструментов были популяризированы через Spring Framework - они были повторно реализованы как инструменты на основе Spring под эгидой проекта Spring Cloud [62] . В таблице ниже показано сравнение реализуемой функции из экосистемы Kubernetes с эквивалентом из мира Spring Cloud. [63] Одним из примечательных аспектов экосистемы 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 Service обеспечивает возможность балансировки нагрузки между экземплярами сервиса. Это не эквивалент того, что предоставляет 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 Stack ( Elasticsearch , LogStash, Kibana ) | ЭФК Stack ( Elasticsearch , Fluentd , Kibana ) |
Централизованные метрики: централизованная область, в которой можно отслеживать работоспособность и производительность отдельных сервисов и системы в целом, имеет важное значение для правильной работы. | Весенний зритель и Атлас | Хипстер, Прометей и Графана |
Распределенная трассировка: ведение журнала по процессам и мониторинг показателей имеют свое место, но ни один из них не может реконструировать сложные пути, по которым транзакции распространяются по распределенной системе. Распределенная трассировка - важный инструмент для платформы микросервисов. | Весенний облачный сыщик | Хокулар, Джегер |
Устойчивость и отказоустойчивость: распределенные системы должны иметь возможность автоматической маршрутизации сбоев и маршрутизации запросов к экземпляру службы, который обеспечит оптимальный ответ. | Пружина Hystrix, турбина и лента | Проверка работоспособности, сервисные сети (пример: Istio) [64] |
Автомасштабирование и самовосстановление: распределенные системы реагируют на более высокую нагрузку путем горизонтального масштабирования: платформа должна обнаруживать такие условия и автоматически реагировать на них. Кроме того, системе необходимо обнаруживать сбои и предпринимать попытки автоматического перезапуска без вмешательства оператора. | - | Проверка работоспособности, самовосстановление и автоматическое масштабирование |
Упаковка, развертывание и планирование. Для крупномасштабных систем требуется надежное управление пакетами, а системы развертывания - для управления скользящим или сине-зеленым развертыванием и откатом при необходимости. Планировщик помогает определить, на каком конкретном исполнительном узле может быть развернут новый набор служб, исходя из текущих условий. | Весенняя загрузка, Apache Maven. В системе Spring Cloud нет настоящего планировщика. | Docker, Rkt, планировщик и развертывание Kubernetes, Helm [65] |
Управление заданиями: запланированные вычисления отключены от каких-либо индивидуальных запросов пользователей. | Весенняя партия | Вакансии Kubernetes и запланированные задания |
Одноэлементное приложение: ограничьте запуск определенной службы как единственного экземпляра этой службы во всей системе. | Весенний кластер облаков | Модули Kubernetes |
Смотрите также
- Закон Конвея
- Межсекторальная озабоченность
- DevOps
- Заблуждения распределенных вычислений
- GraphQL
- gRPC
- Передача репрезентативного состояния (REST)
- Сервисно-ориентированная архитектура (SOA)
- Модернизация программного обеспечения
- Философия Unix
- Автономная система (программное обеспечение)
- Бессерверные вычисления
- Веб-ориентированная архитектура (WOA)
Рекомендации
- ^ а б в г Мартин Фаулер. «Микросервисы» . Архивировано 14 февраля 2018 года.
- ^ Ньюман, Сэм (20 февраля 2015 г.). Создание микросервисов . O'Reilly Media. ISBN 978-1491950357.
- ^ Вольф, Эберхард (2016-10-12). Микросервисы: гибкие программные архитектуры . ISBN 978-0134602417.
- ^ а б в Паутассо, Чезаре (2017). «Микросервисы на практике. Часть 1: Проверка реальности и дизайн услуг». Программное обеспечение IEEE . 34 (1): 91–98. DOI : 10.1109 / MS.2017.24 . S2CID 5635705 .
- ^ а б в г Чен, Ляньпин (2018). Микросервисы: проектирование для непрерывной доставки и DevOps . Международная конференция IEEE по архитектуре программного обеспечения (ICSA 2018) . IEEE.
- ^ a b Надареишвили, И., Митра, Р., Макларти, М., Амундсен, М., Архитектура микросервисов: согласование принципов, практик и культуры, O'Reilly 2016
- ^ "Бэкэнды для паттернов фронтендов" . Шаблоны проектирования облака Microsoft Azure . Microsoft.
- ^ Лукас Краузе. Микросервисы: шаблоны и приложения . ASIN B00VJ3NP4A .
- ^ Разработка микросервисов: непрерывная интеграция, полученная от Microsoft, 9 января 2018 г.
- ^ Josuttis, N. (2007). SOA на практике. Севастополь, Калифорния, США: О'Рейли. ISBN 978-0-596-52955-0 .
- ^ Мартин Фаулер . «Предварительные требования к микросервису» .
- ^ Ричардсон, Крис (ноябрь 2018 г.). «1.4.1 Масштабируемый куб и микросервисы». Шаблоны микросервисов . Публикации Мэннинга. ISBN 9781617294549.
- ^ Mendonca, Nabor C .; Джамшиди, Пуян; Гарлан, Дэвид; Пал, Клаус (16.10.2019). «Разработка самоадаптивных микросервисных систем: проблемы и направления». Программное обеспечение IEEE . arXiv : 1910.07660 . DOI : 10.1109 / MS.2019.2955937 . S2CID 204744007 .
- ^ «Это техническое шоу: дед микросервисов, Фред Джордж» .
- ^ Роджерс, Питер. «Сервисно-ориентированная разработка NetKernel - паттерны, процессы и продукты для уменьшения сложности системы. Веб-службы Edge 2005 East: CS-3» . CloudComputingExpo 2005 . SYS-CON TV. Архивировано из оригинального 20 мая 2018 года . Проверено 3 июля 2017 года .
- ^ Роджерс, Питер. «Сервисно-ориентированная разработка NetKernel - паттернов, процессов и продуктов для уменьшения сложности системы» . CloudComputingExpo . SYS-CON Media. Архивировано из оригинального 20 мая 2018 года . Дата обращения 19 августа 2015 .
- ^ Рассел, Перри; Роджерс, Питер; Селлман, Ройстон (2004). «Архитектура и дизайн платформы приложений XML» . Технические отчеты HP . п. 62 . Проверено 20 августа 2015 года .
- ^ Леви, Юваль (2007). Программирование служб WCF, 1-е изд . O'Reilly Media. С. 543–553. ISBN 978-0-596-52699-3.
- ^ Юваль Леви « Каждый класс - служба WCF ». (Channel9, ARCast.TV, октябрь 2007 г.).
- ^ Юваль Леви « Каждый класс как услуга » (конференция Microsoft TechEd, май 2009 г.), SOA206. Архивировано из оригинала на 2010.
- ^ Леви, Юваль (2007). Программирование служб WCF, 1-е изд . O'Reilly Media. С. 48–51. ISBN 978-0-596-52699-3.
- ^ Леви, Юваль (2010). Программирование служб WCF, 3-е изд . O'Reilly Media. С. 74–75. ISBN 978-0-596-80548-7.
- ^ Драгони, Никола; Джаллоренцо, Саверио; Лафуэнте, Альберто Ллуч; Маццара, Мануэль; Монтези, Фабрицио; Мустафин, Руслан; Сафина, Лариса (2017). «Микросервисы: вчера, сегодня, завтра». Настоящая и дальнейшая разработка программного обеспечения : 195–216. arXiv : 1606.04036 . DOI : 10.1007 / 978-3-319-67425-4_12 . ISBN 978-3-319-67424-7. S2CID 14612986 .
- ^ Джеймс Льюис. «Микросервисы - Java, путь Unix» .
- ^ Фред Джордж (2013-03-20). «Архитектура MicroService: личное путешествие открытий» .
- ^ Фэрроу, Рик (2012). «Netflix летит в облака» (PDF) .
- ^ Джеймс Льюис и Мартин Фаулер. «Микросервисы» .
- ^ «Непрерывное развертывание: стратегии» . javacodegeeks.com . Проверено 28 декабря +2016 .
- ^ Исследование, проверенный рынок. «Тенденции рынка облачных микросервисов в 2020 году, доля рынка, размер отрасли, возможности, анализ и прогноз к 2026 году - Новости рынка мгновенных технологий» . Проверено 18 февраля 2020 .
- ^ О. Циммерманн, Разложение служб для конкретных доменов с помощью шаблонов API микросервисов, Microservices 2019, https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
- ^ «Полномочия Amazon SOA» .
- ^ Вон, Вернон (2016). Домен-ориентированный дизайн . Эддисон-Уэсли Профессионал. ISBN 978-0-13-443442-1.
- ^ Юсиф, Мазин (2016). «Микросервисы». Облачные вычисления IEEE . 3 (5): 4–5. DOI : 10.1109 / MCC.2016.101 .
- ^ Драгони, Никола; Ланезе, Иван; Ларсен, Стефан Тордал; Маццара, Мануэль; Мустафин, Руслан; Сафина, Лариса (2017). «Микросервисы: как сделать ваше приложение масштабируемым» (PDF) . Международная конференция памяти Андрея Ершова о перспективах системной информатики . Конспект лекций по информатике. 10742 : 95–104. arXiv : 1702.07149 . Bibcode : 2017arXiv170207149D . DOI : 10.1007 / 978-3-319-74313-4_8 . ISBN 978-3-319-74312-7. S2CID 1643730 .
- ^ Ньюман, Сэм (2015). Создание микросервисов . О'Рейли. ISBN 978-1491950357.
- ^ Вольф, Эберхард (2016). Микросервисы: гибкая программная архитектура . Эддисон Уэсли. ISBN 978-0134602417.
- ^ Knoche, Holger; Хассельбринг, Вильгельм (2019). «Драйверы и препятствия для внедрения микросервисов - исследование среди профессионалов в Германии» . Моделирование предприятий и архитектуры информационных систем . DOI : 10.18417 / emisa.14.1 .
- ^ Тайби, Давиде; Ленардуцци, Валентина; Пал, Клаус; Джейн, Андреа (2017). «Микросервисы в гибкой разработке программного обеспечения: исследование проблем, преимуществ и недостатков на семинарах» . Материалы научных семинаров XP2017 . DOI : 10.1145 / 3120459.3120483 . S2CID 28134110 .
- ^ Ричардсон, Крис. «Шаблон микросервисной архитектуры» . microservices.io . Проверено 19 марта 2017 .
- ^ Чен, Ляньпин; Али Бабар, Мухаммед (2014). «К основанному на фактах пониманию появления архитектуры посредством непрерывного рефакторинга в гибкой разработке программного обеспечения». Труды Рабочей конференции IEEE / IFIP по архитектуре программного обеспечения 2014 WICSA 2014 . 11-я рабочая конференция IEEE / IFIP по архитектуре программного обеспечения (WICSA 2014) . IEEE. DOI : 10,1109 / WICSA.2014.45 .
- ^ Балалай, Армин; Гейдарнори, Аббас; Джамшиди, Пуян (май 2016 г.). «Архитектура микросервисов позволяет DevOps: переход на облачную архитектуру» (PDF) . Программное обеспечение IEEE . 33 (3): 42–52. DOI : 10.1109 / ms.2016.64 . hdl : 10044/1/40557 . ISSN 0740-7459 . S2CID 18802650 .
- ^ Стенберг, янв (11 августа 2014 г.). «Опыт неудач с микросервисами» .
- ^ Каландра, Мариано. «Почему модульного тестирования недостаточно, когда речь идет о микросервисах» .
- ^ а б «Разработка микросервисов для PaaS с помощью Spring и Cloud Foundry» .
- ^ Тайби, Давиде; Ленардуцци, Валентина; Пал, Клаус; Джейн, Андреа (2017). «Микросервисы в гибкой разработке программного обеспечения: исследование проблем, преимуществ и недостатков на семинарах» . Материалы научных семинаров XP2017 . DOI : 10.1145 / 3120459.3120483 . S2CID 28134110 .
- ^ Тилков, Стефан (17 ноября 2014 г.). "Насколько маленьким должен быть ваш микросервис?" . Иннок . Проверено 4 января 2017 года .
- ^ Ланца, Микеле; Дюкасс, Стефан (2002). «Понимание эволюции программного обеспечения с использованием комбинации визуализации программного обеспечения и показателей программного обеспечения» (PDF) . В Proceedings of LMO 2002 (Langages et Modèles à Objets) : 135–149.
- ^ Ричардсон, Крис (ноябрь 2018 г.). Шаблоны микросервисов . Глава 4. Управление транзакциями с помощью саг: Manning Publications. ISBN 978-1-61729454-9.CS1 maint: location ( ссылка )
- ^ https://www.youtube.com/watch?v=X0tjziAQfNQ
- ^ Леви, Жуваль (2019). Правление программного обеспечения 1-е изд . Эддисон-Уэсли Профессионал. С. 73–75. ISBN 978-0136524038.
- ^ Леви, Жуваль (2019). Правление программного обеспечения 1-е изд . Эддисон-Уэсли Профессионал. С. 73–75. ISBN 978-0136524038.
- ^ Леви, Жуваль (2019). Правление программного обеспечения 1-е изд . Эддисон-Уэсли Профессионал. С. 73–75. ISBN 978-0136524038.
- ^ Паутассо, Чезаре (2017). «Микросервисы на практике. Часть 2: Интеграция сервисов и устойчивость». Программное обеспечение IEEE . 34 (2): 97–104. DOI : 10.1109 / MS.2017.56 . S2CID 30256045 .
- ^ Паутассо, Чезаре (2018). «Последовательное аварийное восстановление для микросервисов: теорема BAC». Облачные вычисления IEEE . 5 (1): 49–59. DOI : 10.1109 / MCC.2018.011791714 . S2CID 4560021 .
- ^ Фаулер, Мартин . «Компромиссы микросервисов» .
- ^ "BRASS Building Resource Adaptive Software Systems". Правительство США. DARPA. 7 апреля 2015 года.«Доступ к системным компонентам и интерфейсам между клиентами и их приложениями, однако, осуществляется через ряд часто не связанных между собой механизмов, включая неофициально задокументированные интерфейсы прикладного программирования (API), идиосинкразические интерфейсы внешних функций, сложные непонятные определения моделей или рекламные объявления. произвольные форматы данных. Эти механизмы обычно обеспечивают лишь частичное и неполное понимание семантики самих компонентов. При такой сложности неудивительно, что приложения обычно используют многие предположения об ожидаемом поведении экосистемы, с которой они взаимодействуют. ".
- ^ Вольф, Эберхард (2018-04-15). Микросервисы - Практическое руководство . ISBN 978-1717075901.
- ^ Сварт, Стефани (14 декабря 2016 г.). «Eclipse MicroProfile» . projects.eclipse.org .
- ^ «Микропрофиль» . Микропрофиль . Проверено 11 апреля 2021 .
- ^ "Что такое сервисная сеть?" . Жизнерадостный . Жизнерадостный. 2017-04-25 . Проверено 5 декабря 2018 .
- ^ Netflix OSS , Git Hub
- ^ Облако , Весна
- ^ «Spring Cloud для микросервисов по сравнению с Kubernetes» , разработчики , Red Hat, 2016-12-09
- ^ Управление микросервисами с помощью сервисной сети Istio, Kubernetes, май 2017 г.
- ^ Менеджер пакетов 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
- Виджесурия, Вирадж Брайан (2016-08-29) Архитектура микросервисов, конспекты лекций - Школа вычислительной техники Университета Коломбо, Шри-Ланка
- Кристудас Бинильдас (27 июня 2019 г.). Практические архитектурные шаблоны микросервисов: микросервисы Java на основе событий с Spring Boot и Spring Cloud. Апресс. ISBN 978-1484245002 .