✖


Jump to content

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

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

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

Введение [ править ]

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

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

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

История [ править ]

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

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

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

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

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

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

Детализация сервиса [ править ]

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

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

В целом терминология звучит так: сервисы, предназначенные для одной задачи, например, вызов определенной серверной системы или выполнение определенного типа вычислений, называются атомарными сервисами . Аналогично, сервисы, которые вызывают такие атомарные сервисы для консолидации результатов, называются составными сервисами .

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

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

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

Преимущества [ править ]

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

  • Модульность : это упрощает понимание, разработку и тестирование приложения и делает его более устойчивым к эрозии архитектуры. [8] Это преимущество часто сравнивают со сложностью монолитной архитектуры. [30]
  • Масштабируемость . Поскольку микросервисы реализуются и развертываются независимо друг от друга, т. е. они выполняются в рамках независимых процессов, их можно отслеживать и масштабировать независимо. [31]

Критика и опасения [ править ]

Микросервисный подход подвергается критике по ряду вопросов:

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

Сложности [ править ]

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

Лучшие практики [ править ]

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

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

Технологии [ править ]

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

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

Сервисная сетка [ править ]

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

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

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

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

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

Концерн микросервисов Spring Cloud и Netflix OSS Кубернетес
Управление конфигурацией: [59] Конфигурацию микросервисного приложения необходимо извлечь из кода и получить с помощью простого вызова службы. 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) [60]
Автомасштабирование и самовосстановление. Распределенные системы реагируют на более высокую нагрузку горизонтальным масштабированием: платформа должна обнаруживать такие условия и автоматически реагировать на них. Кроме того, системе необходимо обнаруживать сбои и предпринимать попытки автоматического перезапуска без участия оператора. - Проверка работоспособности, самовосстановление и автоматическое масштабирование
Упаковка, развертывание и планирование. Крупномасштабные системы требуют надежного управления пакетами и систем развертывания для управления скользящим или сине-зеленым развертыванием, а также откатами при необходимости. Планировщик помогает определить, на каком именно исполнительном узле можно развернуть новый набор сервисов, исходя из текущих условий. Spring Boot, Apache Maven. В системе Spring Cloud нет настоящего планировщика. Docker, Rkt, планировщик и развертывание Kubernetes, Helm [61]
Управление заданиями: запланированные вычисления не связаны с запросами отдельных пользователей. Весенняя партия Задания Kubernetes и запланированные задания
Приложение Singleton: ограничьте запуск конкретной службы как единственного экземпляра этой службы во всей системе. Кластер весенних облаков Поды Кубернетеса

См. также [ править ]

Ссылки [ править ]

  1. ^ «Микросервисные архитектуры: больше, чем сумма их частей?» . Цифровой гид IONOS . 2 марта 2020 г. Проверено 29 марта 2022 г.
  2. ^ Фаулер, Мартин (2002). Шаблоны архитектуры корпоративных приложений . Аддисон-Уэсли Профессионал. ISBN  978-0321127426 .
  3. ^ Jump up to: Перейти обратно: а б с Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN  978-1492043454 .
  4. ^ Jump up to: Перейти обратно: а б с д Мартин Фаулер. «Микросервисы» . Архивировано из оригинала 14 февраля 2018 года.
  5. ^ Ньюман, Сэм (20 февраля 2015 г.). Создание микросервисов . О'Рейли Медиа. ISBN  978-1491950357 .
  6. ^ Вольф, Эберхард (12 октября 2016 г.). Микросервисы: гибкие архитектуры программного обеспечения . Аддисон-Уэсли. ISBN  978-0134602417 .
  7. ^ Jump up to: Перейти обратно: а б с Паутассо, Чезаре (2017). «Микросервисы на практике, Часть 1: Проверка реальности и проектирование сервисов». Программное обеспечение IEEE . 34 (1): 91–98. дои : 10.1109/MS.2017.24 . S2CID   5635705 .
  8. ^ Jump up to: Перейти обратно: а б с д Чен, Ляньпин (2018). Микросервисы: архитектура для непрерывной доставки и DevOps . Международная конференция IEEE по архитектуре программного обеспечения (ICSA 2018) . IEEE.
  9. ^ Jump up to: Перейти обратно: а б Надареишвили И., Митра Р., Макларти М., Амундсен М., Микросервисная архитектура: согласование принципов, практик и культуры, O'Reilly, 2016 г.
  10. ^ «Шаблон бэкендов для фронтендов» . Шаблоны облачного проектирования Microsoft Azure . Майкрософт.
  11. ^ Лукас Краузе. Микросервисы: шаблоны и приложения . АСИН   B00VJ3NP4A .
  12. ^ Форд, Н.; Ричардс, М; Садалаге, П; Дегани, З. «Архитектура программного обеспечения: сложные части» . Мыслительные работы . Проверено 20 января 2023 г.
  13. ^ « CI/CD для архитектур микросервисов », Центр архитектуры Azure, Microsoft . Проверено 9 января 2018 г.
  14. ^ Джосуттис, Н. (2007). SOA на практике. Севастополь, Калифорния, США: О'Рейли. ISBN   978-0-596-52955-0 .
  15. ^ Мартин Фаулер (28 августа 2014 г.). «Необходимые условия микросервиса» . Архивировано из оригинала 3 октября 2023 г.
  16. ^ Ричардсон, Крис (ноябрь 2018 г.). Шаблоны микросервисов . Публикации Мэннинга. 1.4.1 Масштабирование куба и микросервисов. ISBN  9781617294549 .
  17. ^ Мендонка, Набор К.; Джамшиди, Пуян; Гарлан, Дэвид; Паль, Клаус (16 октября 2019 г.). «Разработка самоадаптивных микросервисных систем: проблемы и направления». Программное обеспечение IEEE . 38 (2): 70–79. arXiv : 1910.07660 . дои : 10.1109/MS.2019.2955937 . S2CID   204744007 .
  18. ^ Jump up to: Перейти обратно: а б Роджерс, Питер (15 февраля 2005 г.). «Сервис-ориентированная разработка на NetKernel: шаблоны, процессы и продукты для уменьшения сложности системы» . Выставка облачных вычислений . СИС-КОН Медиа. Архивировано из оригинала 20 мая 2018 года . Проверено 19 августа 2015 г.
  19. ^ Рассел, Перри; Роджерс, Питер; Селлман, Ройстон (2004). «Архитектура и проектирование платформы приложений XML» . Технические отчеты HP . п. 62 . Проверено 20 августа 2015 г.
  20. ^ Драгони, Никола; Джяллоренцо, Саверио; Лафуэнте, Альберто Ллуч; Маццара, Мануэль; Монтези, Фабрицио; Мустафин, Руслан; Сафина, Лариса (2017). «Микросервисы: вчера, сегодня и завтра». Настоящее и дальнейшее развитие программного обеспечения . стр. 195–216. arXiv : 1606.04036 . дои : 10.1007/978-3-319-67425-4_12 . ISBN  978-3-319-67424-7 . S2CID   14612986 .
  21. ^ Джеймс Льюис. «Микросервисы — Java, путь Unix» .
  22. ^ Фред Джордж (20 марта 2013 г.). «Микросервисная архитектура: личный путь открытий» .
  23. ^ Фэрроу, Рик (2012). «Netflix взлетает в облака» (PDF) .
  24. ^ Джеймс Льюис и Мартин Фаулер. «Микросервисы» .
  25. ^ «Непрерывное развертывание: стратегии» . javacodegeeks.com . 10 декабря 2014 года . Проверено 28 декабря 2016 г.
  26. ^ Исследования, проверенный рынок. «Тенденции рынка облачных микросервисов в 2020 году, доля рынка, размер отрасли, возможности, анализ и прогноз до 2026 года – новости рынка мгновенных технологий» . Проверено 18 февраля 2020 г.
  27. ^ О. Циммерманн, Декомпозиция сервисов для конкретного домена с помощью шаблонов API микросервисов, Microservices 2019, https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
  28. ^ «Мандат Amazon SOA» . 13 октября 2011 г.
  29. ^ Вон, Вернон (2016). Краткий обзор предметно-ориентированного проектирования . Аддисон-Уэсли Профессионал. ISBN  978-0-13-443442-1 .
  30. ^ Юсиф, Мазин (2016). «Микросервисы». Облачные вычисления IEEE . 3 (5): 4–5. дои : 10.1109/MCC.2016.101 .
  31. ^ Драгони, Никола; Ланезе, Иван; Ларсен, Стефан Тордал; Маццара, Мануэль; Мустафин, Руслан; Сафина, Лариса (2017). «Микросервисы: как масштабировать приложение» (PDF) . Перспективы системной информатики . Конспекты лекций по информатике. Том. 10742. стр. 95–104. arXiv : 1702.07149 . Бибкод : 2017arXiv170207149D . дои : 10.1007/978-3-319-74313-4_8 . ISBN  978-3-319-74312-7 . S2CID   1643730 .
  32. ^ Ньюман, Сэм (2015). Создание микросервисов . О'Рейли. ISBN  978-1491950357 .
  33. ^ Вольф, Эберхард (2016). Микросервисы: гибкая архитектура программного обеспечения . Эддисон Уэсли. ISBN  978-0134602417 .
  34. ^ Кнохе, Хольгер; Хассельбринг, Вильгельм (2019). «Драйверы и препятствия для внедрения микросервисов – опрос среди профессионалов в Германии» . Моделирование предприятия и архитектура информационных систем . 14 : 1:1–35–1:1–35. дои : 10.18417/emisa.14.1 .
  35. ^ Jump up to: Перейти обратно: а б Тайби, Давиде; Ленардуцци, Валентина; Паль, Клаус; Джейнс, Андреа (2017). «Микросервисы в гибкой разработке программного обеспечения: исследование проблем, преимуществ и недостатков на основе семинара» . Материалы научных семинаров XP2017 . дои : 10.1145/3120459.3120483 . S2CID   28134110 .
  36. ^ Ричардсон, Крис. «Шаблон микросервисной архитектуры» . микросервисы.io . Проверено 19 марта 2017 г.
  37. ^ Чен, Ляньпин; Али Бабар, Мухаммед (2014). «На пути к научно обоснованному пониманию возникновения архитектуры посредством непрерывного рефакторинга в гибкой разработке программного обеспечения». Материалы рабочей конференции IEEE/IFIP по архитектуре программного обеспечения 2014 WICSA 2014 . 11-я рабочая конференция IEEE/IFIP по архитектуре программного обеспечения (WICSA 2014) . IEEE. дои : 10.1109/WICSA.2014.45 .
  38. ^ Балалай, Армин; Гейдарнури, Аббас; Джамшиди, Пуян (май 2016 г.). «Архитектура микросервисов обеспечивает DevOps: переход к облачной архитектуре» (PDF) . Программное обеспечение IEEE . 33 (3): 42–52. дои : 10.1109/ms.2016.64 . hdl : 10044/1/40557 . ISSN   0740-7459 . S2CID   18802650 .
  39. ^ Стенберг, январь (11 августа 2014 г.). «Опыт неудач с микросервисами» .
  40. ^ Каландра, Мариано (7 апреля 2021 г.). «Почему модульного тестирования недостаточно, когда дело касается микросервисов» .
  41. ^ Jump up to: Перейти обратно: а б «Разработка микросервисов для PaaS с помощью Spring и Cloud Foundry» .
  42. ^ Тильков, Стефан (17 ноября 2014 г.). «Насколько маленьким должен быть ваш микросервис?» . Иннок . Проверено 4 января 2017 г.
  43. ^ Ланца, Мишель; Дюкасс, Стефан (2002). «Понимание эволюции программного обеспечения с использованием комбинации визуализации программного обеспечения и показателей программного обеспечения» (PDF) . В Proceedings of LMO 2002 (Langages et Modeles à Objets) : 135–149. Архивировано из оригинала (PDF) 27 февраля 2021 г.
  44. ^ Ричардсон, Крис (ноябрь 2018 г.). «Глава 4. Управление транзакциями с сагами». Шаблоны микросервисов . Публикации Мэннинга. ISBN  978-1-61729454-9 .
  45. ^ Девокс (30 августа 2017 г.). «10 советов Дэвида Шмитца о том, как потерпеть неудачу в микросервисах» . Ютуб . Архивировано из оригинала 22 апреля 2021 г.
  46. ^ Jump up to: Перейти обратно: а б с Леви, Юваль (2019). Исправление программного обеспечения, 1-е изд . Аддисон-Уэсли Профессионал. стр. 73–75. ISBN  978-0136524038 .
  47. ^ Паутассо, Чезаре (2017). «Микросервисы на практике. Часть 2: интеграция и устойчивость сервисов». Программное обеспечение IEEE . 34 (2): 97–104. дои : 10.1109/MS.2017.56 . S2CID   30256045 .
  48. ^ Паутассо, Чезаре (2018). «Последовательное аварийное восстановление микросервисов: теорема BAC». Облачные вычисления IEEE . 5 (1): 49–59. дои : 10.1109/MCC.2018.011791714 . S2CID   4560021 .
  49. ^ Фаулер, Мартин . «Компромиссы микросервисов» .
  50. ^ «BRASS Создание адаптивных программных систем для ресурсов». Правительство США. ДАРПА. 7 апреля 2015 г. «Однако доступ к системным компонентам и интерфейсам между клиентами и их приложениями осуществляется через ряд часто не связанных друг с другом механизмов, включая неофициально документированные интерфейсы прикладного программирования (API), идиосинкразические интерфейсы внешних функций, сложные, плохо понятые интерфейсы. определения моделей или специальные форматы данных. Эти механизмы обычно обеспечивают лишь частичное и неполное понимание семантики самих компонентов. При такой сложности неудивительно, что приложения обычно включают множество предположений об ожидаемом поведении. экосистема, с которой они взаимодействуют».
  51. ^ Понимание распределенных систем: что должен знать каждый разработчик о больших распределенных приложениях . 2021. ISBN  978-1838430207 .
  52. ^ Бхаргав, Нихил (18 марта 2024 г.). «Какова задержка P99?» . baeldung.com . Проверено 8 июня 2024 г. Среднее значение и медиана часто маскируют выбросы
  53. ^ Вольф, Эберхард (15 апреля 2018 г.). Микросервисы — Практическое руководство . Независимая издательская платформа CreateSpace. ISBN  978-1717075901 .
  54. ^ Сварт, Стефани (14 декабря 2016 г.). «Микропрофиль Eclipse» . project.eclipse.org .
  55. ^ «МикроПрофиль» . МикроПрофиль . Проверено 11 апреля 2021 г.
  56. ^ Netflix США , Git Hub
  57. ^ Облако , Весна
  58. ^ «Spring Cloud для микросервисов по сравнению с Kubernetes» , Разработчики , Red Hat, 9 декабря 2016 г.
  59. ^ Сомашекар, Гаган; Ганди, Аншул (26 апреля 2021 г.). «На пути к оптимальной конфигурации микросервисов» . Материалы 1-го семинара по машинному обучению и системам . ЕвроМЛСис '21. Онлайн, Великобритания: Ассоциация вычислительной техники. стр. 7–14. дои : 10.1145/3437984.3458828 .
  60. ^ Управление микросервисами с помощью Service Mesh Istio , Kubernetes, май 2017 г.
  61. ^ Менеджер пакетов Kubernetes , Helm

Дальнейшее чтение [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Microservices&oldid=1229030420"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 79cf0eda44426e2ffe9f76c5fc7544a0__1718360340
URL1:https://arc.ask3.ru/arc/aa/79/a0/79cf0eda44426e2ffe9f76c5fc7544a0.html
Заголовок, (Title) документа по адресу, URL1:
Microservices - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)