stringtranslate.com

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

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

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

Определение

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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

Сложности

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

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

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

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

Технологии

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

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

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

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

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

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

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

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

Ссылки

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

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