Учебное пособие по микросервисам: что это такое, Archiтектура и пример

Что такое микросервисы?

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

Термин «микро» относится к размеру микросервиса, который должен быть управляемым одной командой разработчиков (от 5 до 10 разработчиков). В этой методологии крупные приложения делятся на мельчайшие независимые единицы.

Что такое монолитный Archiтекстура?

Проще говоря, монолитная архитектура — это как большой контейнер, в котором все программные компоненты приложения объединены в один пакет. Рассмотрим пример интернет-магазина в контексте монолитной архитектуры.

монолитный Archiструктура приложения электронной коммерции

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

Что такое микросервис Archiтекстура?

Микросервис Archiтекстура архитектурный стиль разработки, позволяющий создавать приложения как набор небольших автономных сервисов, разработанных для бизнес-домена. Это вариант архитектуры структурного стиля, который помогает организовать приложения как слабосвязанный набор сервисов. Микросервис Architecture содержит детализированные сервисы и облегченные протоколы.

Рассмотрим пример приложения для электронной коммерции, разработанного с использованием микросервисной архитектуры. В этом примере микросервисной архитектуры каждый микросервис ориентирован на одну конкретную бизнес-функцию: поиск, оценка и т.д. Review и Payment имеют свои собственные экземпляры (серверы) и взаимодействуют друг с другом.

Microservices Archiтекстура

В монолитном ArchiВ микросервисной архитектуре все компоненты объединяются в единый модуль. Но в микросервисах все компоненты объединяются в один модуль. ArchiВ архитектуре они распределены по отдельным модулям (микросервисам), которые взаимодействуют друг с другом, как показано в приведенном выше примере с микросервисами.

Связь между микросервисами — это связь без сохранения состояния, где каждая пара запроса и ответа независима. Следовательно, микросервисы могут легко взаимодействовать. В микросервисе ArchiВ этой архитектуре данные объединены в федеративную систему. Каждый микросервис имеет собственное отдельное хранилище данных.

Микросервисы против монолитных Archiтекстура

Microservices	монолитный Archiтекстура
Каждая единица всего приложения должна быть наименьшей и обеспечивать достижение одной конкретной бизнес-цели.	Единая кодовая база для достижения всех бизнес-целей.
Запуск сервиса происходит относительно быстро.	Запуск сервиса занимает больше времени.
Выявление неисправностей — простая задача. Даже если одна служба выйдет из строя, другие смогут продолжать функционировать.	Выявление неисправностей — сложная задача. Если какая-либо конкретная функция не работает, вся система выходит из строя. Для решения этой проблемы необходимо пересобрать, повторно протестировать и повторно развернуть приложение.
Все микросервисы должны быть слабо связаны между собой, чтобы изменения, внесенные в один, не влияли на другие.	Монолитная архитектура характеризуется тесной взаимосвязью. Изменения в одном модуле кода влияют на другие.
Предприятия могут направлять больше ресурсов на услуги, которые приносят более высокую рентабельность инвестиций.	Поскольку услуги не изолированы, индивидуальное распределение ресурсов невозможно.
Больше аппаратных ресурсов можно было бы выделить на наиболее часто используемый сервис. В приведенном выше примере с электронной коммерцией больше пользователей просматривают список товаров и осуществляют поиск, чем совершают платежи, поэтому больше ресурсов можно было бы выделить на микросервис поиска и отображения списка товаров.	Масштабирование приложений является сложной и расточительной задачей.
Микросервисы всегда остаются согласованными и непрерывно доступными.	Инструменты разработки перегружаются, поскольку процесс приходится начинать с нуля.
Данные объединены в федеративную систему. Это позволяет отдельным микросервисам использовать модель данных, наиболее подходящую для их потребностей.	Данные централизованы.
Небольшие, целеустремленные команды. Параллельная и ускоренная разработка.	Требуется большая команда и значительные усилия по управлению ею.
Изменение модели данных одного Микросервиса не влияет на другие Микросервисы.	Изменение модели данных затрагивает всю базу данных.
Взаимодействует с другими микросервисами, используя четко определенные интерфейсы.	Непригодный.
Микросервисы работают по принципу ориентации на продукт, а не на проекты.	Делает акцент на всем проекте в целом.
Никаких перекрестных зависимостей между базами кода. Вы можете использовать разные технологии для разных микросервисов.	Одна функция или программа зависит от других.

Проблемы микросервисов

• Микросервисы зависят друг от друга и должны взаимодействовать.
• По сравнению с монолитными системами существует больше сервисов для мониторинга, которые разрабатываются с использованием различных языки программирования.
• Поскольку это распределенная система, это по своей сути сложная модель.
• Различные сервисы будут иметь свои собственные механизмы, что приведет к значительному увеличению объема памяти для неструктурированных данных.
• Для предотвращения каскадных проблем необходимы эффективное управление и командная работа.
• Воспроизвести проблему будет сложно, если она отсутствует в одной версии и появляется в последней версии.
• Независимое развертывание микросервисов усложняется.
• Микросервисная архитектура требует большого количества операций.
• Управление приложением становится затруднительным при добавлении новых сервисов в систему.
• Для поддержки гетерогенно распределенных микросервисов требуется широкий круг квалифицированных специалистов.
• Микросервис стоит дорого, так как вам нужно поддерживать разные серверные пространства для разных бизнес-задач.

SOA против микросервисов

Сервисы SOA поддерживаются в организации с помощью реестра, который действует как каталог, содержащий список сервисов. Приложениям необходимо найти сервисы в реестре и вызвать их. Другими словами, SOA подобен оркестру, где каждый артист играет на своем инструменте, а музыкальный руководитель дает всем указания.

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

Параметр	SOA	Microservices
Тип конструкции	В SOA программные компоненты доступны внешнему миру для использования в виде сервисов.	Микросервис является частью SOA. Это реализация SOA.
Зависимость	Бизнес-единицы зависимы.	Они независимы друг от друга.
Размер программного обеспечения	Размер программного обеспечения больше, чем у любого традиционного программного обеспечения.	В микросервисной архитектуре размер программного обеспечения всегда невелик.
Технологический стек	Стек технологий ниже по сравнению с микросервисом.	Стек микросервисных технологий может быть очень большим.
Характер применения	По своей природе он монолитный.	По своей сути это полноценный стек технологий.
Независимость и фокус	Приложения SOA созданы для выполнения множества бизнес-задач.	Они созданы для выполнения одной бизнес-задачи.
развертывание	Процесс развертывания занимает много времени.	Развертывание является простым и требует меньше времени.
Экономичность	Более рентабельно.	Less экономически эффективным.
Масштабируемость	Less по сравнению с микросервисами.	Высокая масштабируемость.
Бизнес логика	Компоненты бизнес-логики хранятся в рамках единого домена сервиса, используются простые протоколы передачи данных (HTTP с XML или JSON) и API, управляемые с помощью SDK/клиентов.	Бизнес-логика может существовать в разных областях, используя промежуточные слои, подобные корпоративной сервисной шине (Middleware).

Инструменты микросервисов

1) Wiremock: тестирование микросервисов

WireMock Это гибкая библиотека для создания заглушек и имитации веб-сервисов. Она позволяет настраивать ответ, возвращаемый HTTP API при получении конкретного запроса. Также используется для тестирования микросервисов.

Ссылка для скачивания: http://wiremock.org/

2) Докер

Docker — это проект с открытым исходным кодом, который позволяет создавать, развертывать и запускать приложения с помощью контейнеров. Используя эти контейнеры, разработчики могут запускать приложение как единый пакет. Это позволяет распространять библиотеки и другие зависимости в одном пакете.

Ссылка для скачивания: https://www.docker.com/

3) Хистрикс

Hystrix — это отказоустойчивая система. Java Этот инструмент предназначен для разделения точек доступа к удалённым сервисам, системам и сторонним библиотекам в распределённой среде, такой как микросервисы. Он улучшает работу системы в целом, изолируя неисправные сервисы и предотвращая каскадный эффект сбоев.

Ссылка для скачивания: https://github.com/Netflix/Hystrix

лучшие практики микросервисов Archiтекстура

• Для каждого микросервиса предусмотрено отдельное хранилище данных.
• Поддерживайте аналогичный уровень зрелости кода.
• Отдельная сборка для каждого микросервиса.
• Всегда рассматривайте каждый сервер как не имеющий состояния.

Часто задаваемые вопросы (FAQ)