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

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

Вступление

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

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

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

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

История

Еще в 2005 году Питер Роджерс ввел термин «микро-Веб-сервисы "во время презентации на конференции Web Services Edge. Вопреки традиционному мышлению и на пике шумихи вокруг архитектуры SOAP SOA он выступал за" REST-сервисы "и на слайде № 4 презентации конференции он обсуждает"Программные компоненты являются Micro-Web-Services ».[14] Он продолжает: «Микросервисы создаются с использованием Unix-подобные конвейеры (в Интернет соответствует Unix = true Слабая связь ). Службы могут вызывать службы (+ многоязычная среда выполнения). Сложные сервисные сборки абстрагируются за простыми URI интерфейсы. Любой сервис на любой степени детализации может быть раскрыт ». Он описал, как хорошо спроектированная платформа микросервисов« применяет базовые архитектурные принципы Интернет и службы REST вместе с Unix-подобным планированием и конвейерами, чтобы обеспечить радикальную гибкость и повышенную простоту сервис-ориентированных архитектур.[15]

Работа Роджерса началась в 1999 году с исследовательского проекта Декстера в г. Лаборатория Hewlett Packard, целью которого было сделать код менее хрупким и создать крупномасштабные сложные программные системы. крепкий изменить.[16] В конечном итоге этот путь исследований привел к развитию ресурсо-ориентированные вычисления (ROC), обобщенная абстракция вычислений, в которой REST является особым подмножеством.

В 2007 году Юваль Леви в своем сочинении[17] и говоря[18][19] призывал к созданию систем, в которых каждый класс был бы службой. Леви понял, что это требует использования технологии, которая может поддерживать такое детальное использование услуг, и он расширил Фонд связи Windows (WCF) сделать именно это,[20][21] брать каждый класс и рассматривать его как службу, сохраняя при этом обычную модель программирования классов.

На семинаре архитекторов программного обеспечения, состоявшемся недалеко от Венеции в мае 2011 года, термин «микросервис» использовался для описания того, что участники считали общим архитектурным стилем, который многие из них недавно изучали.[22] В мае 2012 года та же группа выбрала «микросервисы» как наиболее подходящее название. Джеймс Льюис представил некоторые из этих идей как тематическое исследование в марте 2012 г. на 33-й степени в Кракове в области микросервисов - Java, Unix Way,[23] как и Фред Джордж[24] примерно в то же время. Адриан Кокрофт, бывший директор по облачным системам в Netflix,[25] описал этот подход как «мелкозернистую SOA», стал пионером этого стиля в веб-масштабе, как и многие другие, упомянутые в этой статье - Джо Уолнес, Дэн Норт, Эван Ботчер и Грэм Тэкли.[26]

Микросервисы - это специализация подхода к реализации для сервис-ориентированные архитектуры (SOA) используется для создания гибких, независимо развертываемых программные системы.[4] Подход с использованием микросервисов - это первая реализация SOA, которая последовала за появлением DevOps и становится все более популярным для строительства постоянно развернутый системы.[27]

В феврале 2020 года в отчете об исследовании рынка облачных микросервисов было предсказано, что размер мирового рынка микросервисной архитектуры будет расти не менее CAGR 21,37% с 2019 по 2026 год и достигнет 3,1 миллиарда долларов к 2026 году.[28]

Детализация сервиса

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

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

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

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

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

  • Модульность: Это упрощает понимание, разработку, тестирование приложения и делает его более устойчивым к эрозии архитектуры.[5] Это преимущество часто сравнивают со сложностью монолитных архитектур.[32]
  • Масштабируемость: Поскольку микросервисы реализуются и развертываются независимо друг от друга, т. Е. Выполняются в рамках независимых процессов, их можно отслеживать и масштабировать независимо.[33]
  • Интеграция гетерогенных и унаследованные системы: микросервисы считаются эффективным средством модернизации существующего монолитного программного обеспечения.[34][35] Имеются отчеты об опыте нескольких компаний, которые успешно заменили (части) своего существующего программного обеспечения микросервисами или находятся в процессе этого.[36] Процесс для Модернизация программного обеспечения устаревших приложений выполняется с использованием инкрементного подхода.[37]
  • Распределенная разработка: распараллеливание разработка давая возможность небольшим автономным командам развиваться, развертывать и независимо масштабировать соответствующие услуги.[38] Это также позволяет создать архитектуру отдельной услуги за счет непрерывного рефакторинг.[39] Архитектура на основе микросервисов упрощает непрерывная интеграция, непрерывная доставка и развертывание.[40]

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

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

  • Услуги образуют информационные барьеры.[41]
  • Межсервисные вызовы по сети имеют более высокие затраты с точки зрения задержки сети и времени обработки сообщений, чем внутрипроцессные звонки в пределах монолитный сервисный процесс.[1]
  • Тестирование и развертывание сложнее.[42][43]
  • Распределить обязанности между службами сложнее.[5] Это может включать в себя общение между разными командами, переписывание функциональности на другом языке или приспособление ее к другой инфраструктуре.[1] Однако микросервисы можно развертывать независимо от остальной части приложения, в то время как командам, работающим над монолитами, необходимо синхронизировать их для совместного развертывания.[44]
  • Рассмотрение размера сервисов как основного механизма структурирования может привести к слишком большому количеству сервисов, тогда как альтернатива внутренней модуляции может привести к более простой конструкции.[45] Это требует использования приложений, помогающих понять общую архитектуру приложений и взаимозависимости между компонентами.[46]
  • Двухэтапные фиксации рассматриваются как антипаттерн в архитектурах на основе микросервисов, поскольку это приводит к более тесной связи всех участников транзакции. Однако отсутствие этой технологии вызывает неудобные танцы, которые должны быть реализованы всеми участниками транзакции для поддержания согласованности данных.[47]
  • Разработка и поддержка многих сервисов сложнее, если они созданы с использованием разных инструментов и технологий - это особенно проблема, если инженеры часто переходят между проектами.[48]
  • Протокол, обычно используемый с микрослужбами (HTTP), был разработан для общедоступных служб и поэтому не подходит для работы внутренних микросервисов, которые часто должны быть безупречно надежными.[49]
  • Методология декомпозиции, не относящаяся к микросервисам, часто использует функциональную декомпозицию, которая не обрабатывает изменения требований, но при этом усложняет услуги.[50]
  • Само понятие микросервиса вводит в заблуждение, так как есть только сервисы. Нет четкого определения того, когда служба запускается или перестает быть микросервисом.[51]

Познавательная нагрузка

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

Технологии

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

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

Сервисная сетка

Смотрите также: Сервисная сетка

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

Говорят, что в сетке службы экземпляры службы и их вспомогательные прокси составляют плоскость данных, которая включает не только управление данными, но также обработку запросов и ответ. Сетка служб также включает в себя плоскость управления для управления взаимодействием между службами через их прокси-серверы. Существует несколько вариантов архитектуры служебной сети: Открытая сервисная сетка, Istio (совместный проект Google, IBM и Lyft), Linkerd (а CNCF проект во главе с Плавучий[58]), Консул (а HashiCorp product) и многие другие в ландшафт служебной сетки. Плоскость управления сервисной сеткой, Мешеры, обеспечивает управление жизненным циклом, конфигурацией и производительностью в развертываниях сервисной сети.

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

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

Концерн микросервисовВесеннее облако и Netflix OSSKubernetes
Управление конфигурацией: конфигурация для приложения микросервиса должна быть извлечена из кода и извлечена с помощью простого вызова службы.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 как с севера на юг (трафик в центр обработки данных и из него), так и с востока на запад (трафик между центрами обработки данных, облаками или регионами).
Проблемы безопасности: многие проблемы безопасности возлагаются на реализацию шлюза API. С распределенными приложениями микросервисов имеет смысл не изобретать колесо безопасности и разрешить определение и реализацию политик в компонентах, которые являются общими для всех служб.Spring Cloud Security решает многие проблемы безопасности с помощью Spring Cloud ZuulЭкосистема Kubernetes предоставляет сервисные сети, такие как Istio, которые способны обеспечивать безопасность через свои механизмы шлюза API.
Централизованное ведение журнала: важно иметь централизованную инфраструктуру сбора и анализа журналов для управления множеством сервисов, многие из которых работают в распределенном режиме.ELK Стек (Elasticsearch, LogStash, Кибана )Стек EFK (Elasticsearch, Свободно, Кибана )
Централизованные метрики: централизованная область, в которой можно отслеживать работоспособность и производительность отдельных служб и системы в целом, имеет важное значение для правильной работы.Весенний зритель и АтласХипстер, Прометей и Графана
Распределенная трассировка: ведение журнала по процессам и мониторинг показателей имеют свое место, но ни один из них не может реконструировать сложные пути, по которым транзакции распространяются по распределенной системе. Распределенная трассировка - важный инструмент для платформы микросервисов.Весенний облачный сыщикЯстреб, Jaeger
Устойчивость и отказоустойчивость: распределенные системы должны иметь возможность автоматической маршрутизации отказов и возможность маршрутизации запросов к экземпляру службы, который обеспечит оптимальный ответ.Пружина Hystrix, турбина и лентаПроверка состояния здоровья, сервисные сети (пример: Istio)[62]
Автоматическое масштабирование и самовосстановление: распределенные системы реагируют на более высокую нагрузку путем горизонтального масштабирования: платформа должна обнаруживать такие условия и автоматически реагировать на них. Кроме того, системе необходимо обнаруживать сбои и предпринимать попытки автоматического перезапуска без вмешательства оператора.-Проверка работоспособности, самовосстановление и автоматическое масштабирование
Упаковка, развертывание и планирование. Для крупномасштабных систем требуется надежное управление пакетами, а системы развертывания - для управления скользящим или сине-зеленым развертыванием, а также при необходимости откатом. Планировщик помогает определить, на каком конкретном исполнительном узле может быть развернут новый набор служб, исходя из текущих условий.Весенняя загрузка, Apache Maven. В системе Spring Cloud нет настоящего планировщика.Докер, Rkt, Планировщик и развертывание Kubernetes, Helm[63]
Управление заданиями: запланированные вычисления отключены от любых индивидуальных запросов пользователей.Весенняя партияВакансии Kubernetes и запланированные задания
Одноэлементное приложение: ограничьте запуск определенной службы как единственного экземпляра этой службы во всей системе.Весенний кластер облаковМодули Kubernetes

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

Рекомендации

  1. ^ а б c d Мартин Фаулер. «Микросервисы». В архиве из оригинала 14 февраля 2018 г.
  2. ^ Ньюман, Сэм (20 февраля 2015 г.). Создание микросервисов. O'Reilly Media. ISBN  978-1491950357.
  3. ^ Вольф, Эберхард (2016-10-12). Микросервисы: гибкие программные архитектуры. ISBN  978-0134602417.
  4. ^ а б c Паутассо, Чезаре (2017). «Микросервисы на практике. Часть 1: Проверка реальности и дизайн услуг». Программное обеспечение IEEE. 34 (1): 91–98. Дои:10.1109 / MS.2017.24. S2CID  5635705.
  5. ^ а б c d Чен, Ляньпин (2018). Микросервисы: проектирование для непрерывной доставки и DevOps. Международная конференция IEEE по архитектуре программного обеспечения (ICSA 2018). IEEE.
  6. ^ а б Надареишвили И., Митра Р., Макларти М., Амундсен М. Архитектура микросервисов: согласование принципов, практик и культуры, O’Reilly 2016
  7. ^ "Шаблоны бэкэндов для фронтендов". Шаблоны проектирования облака Microsoft Azure. Microsoft.
  8. ^ Лукас Краузе. Микросервисы: шаблоны и приложения. КАК В  B00VJ3NP4A.
  9. ^ Проектирование микросервисов: непрерывная интеграция Microsoft Дата обращения 9 января 2018.
  10. ^ Йосуттис, Н. (2007). SOA на практике. Севастополь, Калифорния, США: О'Рейли. ISBN  978-0-596-52955-0.
  11. ^ Мартин Фаулер. «Предварительные требования к микросервису».
  12. ^ Ричардсон, Крис (ноябрь 2018 г.). Шаблоны микросервисов. Глава 1, раздел 1.4.1 Масштабируемый куб и микросервисы: публикации Manning. ISBN  9781617294549.CS1 maint: location (связь)
  13. ^ Mendonca, Nabor C .; Джамшиди, Пуян; Гарлан, Дэвид; Пал, Клаус (2019-10-16). «Разработка самоадаптивных микросервисных систем: проблемы и направления». arXiv:1910.07660 [cs.SE ].
  14. ^ Роджерс, Питер. «Сервисно-ориентированная разработка NetKernel - паттерны, процессы и продукты для снижения сложности системы. Веб-службы Edge 2005 East: CS-3». CloudComputingExpo 2005. SYS-CON TV. Архивировано из оригинал 20 мая 2018 г.. Получено 3 июля 2017.
  15. ^ Роджерс, Питер. «Сервисно-ориентированная разработка NetKernel - паттернов, процессов и продуктов для снижения сложности системы». CloudComputingExpo. SYS-CON Media. Архивировано из оригинал 20 мая 2018 г.. Получено 19 августа 2015.
  16. ^ Рассел, Перри; Роджерс, Питер; Селлман, Ройстон (2004). «Архитектура и дизайн платформы приложений XML». Технические отчеты HP. п. 62. Получено 20 августа 2015.
  17. ^ Леви, Юваль (2007). Программирование служб WCF, 1-е изд.. O’Reilly Media. С. 543–553. ISBN  978-0-596-52699-3.
  18. ^ Юваль Леви "Каждый класс - служба WCF ". (Channel9, ARCast.TV, октябрь 2007 г.).
  19. ^ Юваль Леви "Каждый класс как услуга "(Конференция Microsoft TechEd, май 2009 г.), SOA206. Архивировано из оригинал на 2010 год.
  20. ^ Леви, Юваль (2007). Программирование служб WCF, 1-е изд.. O’Reilly Media. С. 48–51. ISBN  978-0-596-52699-3.
  21. ^ Леви, Юваль (2010). Программирование служб WCF, 3-е изд.. O’Reilly Media. С. 74–75. ISBN  978-0-596-80548-7.
  22. ^ Драгони, Никола; Джаллоренцо, Саверио; Лафуэнте, Альберто Ллуч; Маццара, Мануэль; Монтези, Фабрицио; Мустафин, Руслан; Сафина, Лариса (2017). «Микросервисы: вчера, сегодня, завтра». Настоящая и внешняя разработка программного обеспечения: 195–216. arXiv:1606.04036. Дои:10.1007/978-3-319-67425-4_12. ISBN  978-3-319-67424-7. S2CID  14612986.
  23. ^ Джеймс Льюис. «Микросервисы - Java, путь Unix».
  24. ^ Фред Джордж (2013-03-20). «Архитектура MicroService: личное путешествие открытий».
  25. ^ Фэрроу, Рик (2012). "Netflix летит в облака" (PDF).
  26. ^ Джеймс Льюис и Мартин Фаулер. «Микросервисы».
  27. ^ «Непрерывное развертывание: стратегии». javacodegeeks.com. Получено 28 декабря 2016.
  28. ^ Исследование, проверенный рынок. «Тенденции рынка облачных микросервисов в 2020 году, доля рынка, размер отрасли, возможности, анализ и прогноз к 2026 году - Новости рынка мгновенных технологий». Получено 2020-02-18.
  29. ^ О. Циммерманн, Декомпозиция сервисов для конкретных доменов с помощью шаблонов API микросервисов, Microservices 2019, https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
  30. ^ «Полномочия Amazon SOA».
  31. ^ Вон, Вернон (2016). Домен-ориентированный дизайн - дистиллированный. Эддисон-Уэсли Профессионал. ISBN  978-0-13-443442-1.
  32. ^ Юсиф, Мазин (2016). «Микросервисы». Облачные вычисления IEEE. 3 (5): 4–5. Дои:10.1109 / MCC.2016.101.
  33. ^ Драгони, Никола; Ланезе, Иван; Ларсен, Стефан Тордал; Маццара, Мануэль; Мустафин, Руслан; Сафина, Лариса (2017). «Микросервисы: как сделать ваше приложение масштабируемым» (PDF). Международная конференция памяти Андрея Ершова о перспективах системной информатики. Конспект лекций по информатике. 10742: 95–104. arXiv:1702.07149. Bibcode:2017arXiv170207149D. Дои:10.1007/978-3-319-74313-4_8. ISBN  978-3-319-74312-7. S2CID  1643730.
  34. ^ Ньюман, Сэм (2015). Создание микросервисов. О'Рейли. ISBN  978-1491950357.
  35. ^ Вольф, Эберхард (2016). Микросервисы: гибкая программная архитектура. Эддисон Уэсли. ISBN  978-0134602417.
  36. ^ Knoche, Holger; Хассельбринг, Вильгельм (2019). «Драйверы и препятствия для внедрения микросервисов - опрос профессионалов в Германии». Моделирование предприятий и архитектуры информационных систем. Дои:10.18417 / emisa.14.1.
  37. ^ Тайби, Давиде; Ленардуцци, Валентина; Пал, Клаус; Джейн, Андреа (2017). «Микросервисы в гибкой разработке программного обеспечения: исследование проблем, преимуществ и недостатков на семинарах». Материалы научных семинаров XP2017. Дои:10.1145/3120459.3120483. S2CID  28134110.
  38. ^ Ричардсон, Крис. «Шаблон микросервисной архитектуры». microservices.io. Получено 2017-03-19.
  39. ^ Чен, Ляньпин; Али Бабар, Мухаммед (2014). К основанному на фактах пониманию появления архитектуры посредством непрерывного рефакторинга в гибкой разработке программного обеспечения. 11-я рабочая конференция IEEE / IFIP по архитектуре программного обеспечения (WICSA 2014). IEEE. Дои:10.1109 / WICSA.2014.45. Архивировано из оригинала| архив-url = требует | url = (помощь) на 2014-07-30.
  40. ^ Балалай, Армин; Гейдарнори, Аббас; Джамшиди, Пуян (май 2016 г.). «Архитектура микросервисов делает возможным DevOps: переход на облачную архитектуру» (PDF). Программное обеспечение IEEE. 33 (3): 42–52. Дои:10.1109 / мс.2016.64. HDL:10044/1/40557. ISSN  0740-7459. S2CID  18802650.
  41. ^ Стенберг, янв (11 августа 2014 г.). «Опыт неудач с микросервисами».
  42. ^ Каландра, Мариано. «Почему для микросервисов недостаточно модульного тестирования».
  43. ^ а б «Разработка микросервисов для PaaS с помощью Spring и Cloud Foundry».
  44. ^ Тайби, Давиде; Ленардуцци, Валентина; Пал, Клаус; Джейн, Андреа (2017). «Микросервисы в гибкой разработке программного обеспечения: исследование проблем, преимуществ и недостатков на семинарах». Материалы научных семинаров XP2017. Дои:10.1145/3120459.3120483. S2CID  28134110.
  45. ^ Тилков, Стефан (17 ноября 2014 г.). "Насколько маленьким должен быть ваш микросервис?". Иннок. Получено 4 января 2017.
  46. ^ Ланца, Микеле; Дюкасс, Стефан (2002). «Понимание эволюции программного обеспечения с использованием комбинации визуализации программного обеспечения и показателей программного обеспечения» (PDF). In Proceedings of LMO 2002 (Langages et Modèles à Objets): 135–149.
  47. ^ Ричардсон, Крис (ноябрь 2018 г.). Шаблоны микросервисов. Глава 4. Управление транзакциями с помощью саг: Manning Publications. ISBN  978-1-61729454-9.CS1 maint: location (связь)
  48. ^ https://www.youtube.com/watch?v=X0tjziAQfNQ
  49. ^ Леви, Жуваль (2019). Righting Software 1-е изд.. Эддисон-Уэсли Профессионал. С. 73–75. ISBN  978-0136524038.
  50. ^ Леви, Жуваль (2019). Righting Software 1-е изд.. Эддисон-Уэсли Профессионал. С. 73–75. ISBN  978-0136524038.
  51. ^ Леви, Жуваль (2019). Righting Software 1-е изд.. Эддисон-Уэсли Профессионал. С. 73–75. ISBN  978-0136524038.
  52. ^ Паутассо, Чезаре (2017). «Микросервисы на практике. Часть 2: Интеграция услуг и устойчивость». Программное обеспечение IEEE. 34 (2): 97–104. Дои:10.1109 / MS.2017.56. S2CID  30256045.
  53. ^ Паутассо, Чезаре (2018). «Последовательное аварийное восстановление для микросервисов: теорема BAC». Облачные вычисления IEEE. 5 (1): 49–59. Дои:10.1109 / MCC.2018.011791714. S2CID  4560021.
  54. ^ Фаулер, Мартин. "Компромиссы микросервисов".
  55. ^ "BRASS Building Resource Adaptive Software Systems". Правительство США. DARPA. 7 апреля 2015 года. «Однако доступ к системным компонентам и интерфейсам между клиентами и их приложениями осуществляется через ряд часто не связанных между собой механизмов, в том числе неофициально задокументированных. интерфейсы прикладного программирования (API), своеобразные интерфейсы внешних функций, сложные непонятные определения моделей или для этого случая форматы данных. Эти механизмы обычно обеспечивают лишь частичное и неполное понимание семантики самих компонентов. При такой сложности неудивительно, что приложения обычно используют многие предположения об ожидаемом поведении экосистемы, с которой они взаимодействуют ".
  56. ^ Вольф, Эберхард (2018-04-15). Микросервисы - Практическое руководство. ISBN  978-1717075901.
  57. ^ Сварт, Стефани (14 декабря 2016 г.). «Eclipse MicroProfile». projects.eclipse.org.
  58. ^ "Что такое сервисная сеть?". Плавучий. Жизнерадостный. 2017-04-25. Получено 5 декабря 2018.
  59. ^ Netflix OSS, Git Hub
  60. ^ Облако, Весна
  61. ^ «Spring Cloud для микросервисов по сравнению с Kubernetes», Разработчики, Красная шапка, 2016-12-09
  62. ^ Управление микросервисами с помощью сервисной сети Istio, Kubernetes, май 2017 г.
  63. ^ Менеджер пакетов Kubernetes, Шлем

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