Оригинальный адрес:микросервисы.IO/patterns/m…

описание сцены

Предположим, вы разрабатываете большое серверное корпоративное приложение со следующими требованиями:

• Должны поддерживаться различные клиенты, в том числе: веб-браузеры, WAP-браузеры и собственные мобильные приложения.
• Предоставлять общедоступные API для вызова
• Обработка HTTP-запросов или сообщений и выполнение соответствующей бизнес-логики.
• Доступ к базе данных, кэширование или сохранение данных ответов
• Связь с другими системами для обмена необходимой информацией
• Вернуть ответ HTTP, указав конкретный метод сериализации, такой как JSON, XML и т. д.
• В соответствии с бизнес-логикой и функциями спроектируйте и разделите различные логические модули.

Такое приложение, как бы вы спроектировали архитектуру и развернули его?

Соображения

• Это проект, разработанный командой, при этом независимая команда отвечает за
• Члены команды меняются, и новые участники должны быстро приступить к работе.
• Приложения должны быть простыми для понимания и изменения
• Ожидайте непрерывную интеграцию и развертывание приложений
• Приложения должны развертываться в нескольких экземплярах, чтобы соответствовать требованиям масштабируемости и доступности.
• Хотите использовать относительно новые технологии (фреймворки, языки программирования и т.д.)

решение

Определите совместную архитектуру, которая структурирует приложение как набор слабо связанных микросервисов, каждый из которых удовлетворяет следующим требованиям:

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

Службы взаимодействуют с использованием синхронных протоколов (таких как HTTP/REST) ​​или асинхронных протоколов (таких как AMQP). Сервисы можно разрабатывать и развертывать независимо друг от друга. Каждый сервис имеет свою базу данных для отделения от других сервисов. Использование согласованности данных между службамиРежим САГА

Пример

Предположим, вы разрабатываете приложение для электронной коммерции, функции которого включают в себя получение заказов от клиентов (StoreFrontUI), проверку и поддержание остатков на складе (служба инвентаризации), проверку и поддержание доступных пользователям остатков (служба бухгалтерского учета), успешное размещение заказов и доставку (служба доставки). ) ). Это приложение разработано какМикросервисыАрхитектура приложения, как показано на рисунке:

анализировать

выгода

• Поддерживает непрерывную доставку и развертывание больших и сложных приложений
  • Повышенная ремонтопригодность: Каждый сервис относительно небольшой, поэтому его легче понять и изменить.
  • легче проверить: Сервис меньше, а тест быстрее.
  • лучшая развертываемость: службы могут быть развернуты независимо.
  • Разделение работы и бизнес-границы модулей более четко определены, микросервис может предоставляться и поддерживаться одной или несколькими командами. Каждая команда может разрабатывать, тестировать, развертывать и масштабировать свои сервисы независимо от всех других команд.
• Каждый микросервис относительно меньше:
  • Легче понять разработчикам
  • Загрузка IDE ниже и быстрее, что повышает эффективность разработки
  • Приложения запускаются быстрее, отлаживаются эффективнее и развертываются быстрее.
• локализация отказов. Например, если в одном микросервисе есть утечка памяти, это повлияет только на этот микросервис. Другие службы могут продолжать обрабатывать запросы.
• Легче обновить технический стек. При разработке нового модуля микросервиса новый стек технологий можно использовать для экспериментальной разработки и использования, а после стабилизации постепенно расширять на другие микросервисы.

вред

• Разработчикдолжен столкнутьсяДополнительная сложность распределенных систем:
  • Разработчики должны быть знакомы с RPC-коммуникациями и писать логику обработки сбоев.
  • Реализация запросов в нескольких службах является более сложной задачей.
  • Тестировать взаимодействие между сервисами сложнее. Модульные тесты не могут охватить все сценарии, а интеграционные тесты сложнее развертывать.
  • Реализация запросов в нескольких службах требует тщательной координации между командами.
  • IDE в основном ориентированы на создание монолитных приложений и не предоставляют явной поддержки для разработки распределенных приложений.
• Сложность развертывания. В производственной среде также возникают операционные сложности при развертывании и управлении системой, состоящей из множества различных сервисов. Текущие решения для контейнеризации и оркестрации контейнеров предназначены для решения этой проблемы.
• Увеличение потребления ресурсов, таких как память. Предполагая, что каждый микросервис имеет эксклюзивную JVM, ресурсы, занимаемые самой JVM (такие как ЦП и память, занимаемые сборщиком мусора, а также метапространство, кеш кода и т. д.), превышают исходные. Если микросервис занимает контейнер, а то и виртуальную машину или машину, трата ресурсов будет больше.

вопросы для рассмотрения

Когда использовать архитектуру микросервисов?

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

Как разложить приложение на сервисы?

Еще одна проблема — решить, как разделить систему на микросервисы. Это в значительной степени искусство, но есть много стратегий, которые следует учитывать:

• Разбейте по видам деятельности и определите иБизнес-функцииСоответствующие микросервисы.
• в соответствии сДизайн, управляемый доменомдекомпозиция подобластей
• в соответствии сПоведение пользователей и варианты использованияРазложите и определите микросервисы, отвечающие за определенные операции. НапримерShipping ServiceОтветственность за отгрузку комплектных заказов.
• определить ответственногоработать с сущностью/ресурсом определенного типамикросервисов. Например, служба учетных записей отвечает за управление учетными записями пользователей.

В идеале на каждую службу должна быть возложена лишь небольшая доля ответственности. Боб Мартин рассказывает об использованииПринцип единой ответственности. Для класса должна быть только одна причина для его изменения. Также имеет смысл применить принцип единой ответственности к сервис-дизайну.

Еще одна аналогия, которая помогает при проектировании услуг, — это проектирование утилит Unix. Unix предоставляет ряд утилит, таких как grep, cat и find. Каждая утилита выполняет только одну функцию, а сложные задачи выполняются с помощью сценариев оболочки в сочетании с другими утилитами.

Как обеспечить согласованность данных?

Для обеспечения слабой связи у каждой службы есть собственная база данных. Поддержание согласованности данных между службами является сложной задачей, поскольку для многих приложений двухфазная фиксация (2PC) или распределенные транзакции не являются хорошим вариантом. Приложения должны использовать шаблон SAGA, где службы публикуют события при изменении их данных, а другие службы используют это событие и обновляют свои данные. Существует несколько способов надежного обновления данных и публикации событий, включая Event Sourcing и Transaction Log Tailing.

Как реализовать запрос?

Еще одной проблемой является реализация запросов, которые должны извлекать данные, принадлежащие нескольким службам.

Связанные шаблоны проектирования

• Режим разборки микросервиса
• Независимый шаблон проектирования для каждой базы данных микросервиса: Как у каждой службы есть собственная база данных, чтобы обеспечить слабую связь.
• Унифицированный шаблон шлюза API: определяет, как клиенты получают доступ к службам в архитектуре микрослужб.
• Обнаружение клиентских службиОбнаружение службы на стороне сервераШаблоны используются для маршрутизации клиентских запросов к доступным экземплярам службы.
• Единая служба на хостиНесколько сервисов на хостШаблоны, которые представляют собой шаблоны проектирования для стратегий развертывания.
• шаблон проектирования сквозных проблем: Например, в аспектно-ориентированном дизайне два очень разных компонента имеют некоторые схожие функции.В настоящее время нам нужен аспектный дизайн, чтобы объединить эти похожие функции.
• выключатель
• токен доступа
• наблюдаемая мода
• Шаблоны, связанные с пользовательским интерфейсом
• Тестирование связанных шаблонов проектирования: Тестирование компонентов службы и тестирование контракта на интеграцию службы (Контрактное тестирование)