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