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

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

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

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

Давайте обсудим пример магазина электронной коммерции в контексте монолитной архитектуры.

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

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

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

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

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

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

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

• Сложно управлять приложением при добавлении в систему новых услуг.
• Для поддержки гетерогенно распределенных микросервисов требуется широкий круг квалифицированных специалистов.
• Микросервис стоит дорого, так как вам нужно поддерживать разные серверные пространства для разных бизнес-задач.

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

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

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

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

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

Вот подробное сравнение SOA и микросервисов.

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

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

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

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

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

2) Докер

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

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

3) Хистрикс

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

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

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

• Отдельное хранилище данных для каждого микросервиса
• Сохраняйте код того же уровня зрелости.
• Отдельная сборка для каждого микросервиса.
• Всегда обращайтесь – сурово, как без гражданства.

Итого

• Микросервисы — это шаблон сервис-ориентированной архитектуры, в котором приложения создаются как совокупность различных наименьших независимых сервисных единиц.
• Микросервис Architecture — это архитектурный стиль разработки, позволяющий создавать приложение как набор небольших автономных сервисов, разработанных для определенной бизнес-области.
• Монолитная архитектура подобна большому контейнеру, в котором все программные компоненты приложения собраны в один пакет.
• В микросервисе каждая единица всего приложения должна быть наименьшей и обеспечивать достижение одной конкретной бизнес-цели.
• В монолитной архитектуре большая база кода может замедлить весь процесс разработки. Новые выпуски могут занять месяцы. Сопровождение кода затруднено
• Два типа микросервисов: 1) без сохранения состояния 2) с сохранением состояния.
• Микросервисы в Java полагаются друг на друга, и им придется общаться друг с другом. Помогает вам сделать акцент на конкретной функции и потребностях бизнеса.
• Сервис-ориентированная архитектура, вскоре известная как SOA, представляет собой эволюцию распределенных вычислений, основанную на модели проектирования запроса или ответа для синхронных и асинхронных приложений.
• В SOA компоненты программного обеспечения доступны внешнему миру для использования в виде сервисов, тогда как микросервис является частью SOA. Это реализация SOA
• Wiremock, Docker и Hystrix — некоторые популярные инструменты микросервисов.