Микросервисная архитектура - Введение

Микросервис - это методология разработки приложений на основе служб. В этой методологии большие приложения будут разделены на самые маленькие независимые сервисные единицы. Микросервис - это процесс реализации сервис-ориентированной архитектуры (SOA) путем разделения всего приложения на набор взаимосвязанных сервисов, где каждая служба будет обслуживать только одну бизнес-потребность.

Концепция перехода на микро

В сервис-ориентированной архитектуре все программные пакеты будут подразделены на небольшие взаимосвязанные бизнес-единицы. Каждое из этих подразделений малого бизнеса будет общаться друг с другом, используя разные протоколы, чтобы обеспечить успешный бизнес для клиента. Теперь вопрос в том, чем микросервисная архитектура (MSA) отличается от SOA? Одним словом, SOA - это шаблон проектирования, а микросервис - это методология реализации для реализации SOA, или мы можем сказать, что микросервис - это тип SOA.

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

  • Independent - Каждый микросервис должен развертываться независимо.

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

  • Business Goal - Каждая сервисная единица всего приложения должна быть самой маленькой и способной выполнять одну конкретную бизнес-цель.

Давайте рассмотрим пример портала онлайн-покупок, чтобы глубже понять микросервис. Теперь давайте разберем весь этот портал электронной коммерции на небольшие бизнес-единицы, такие как управление пользователями, управление заказами, регистрация, управление платежами, управление доставкой и т. Д. Один успешный заказ должен пройти через все эти модули в течение определенного времени. Рамка. Ниже приводится сводное изображение различных бизнес-единиц, связанных с одной системой электронной торговли.

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

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

На изображении выше вы можете увидеть различные модули, такие как База данных, для хранения различных пользователей и бизнес-данных. Во внешнем интерфейсе у нас есть другое устройство, на котором мы обычно обрабатываем пользовательские или бизнес-данные. В середине у нас есть один пакет, который может быть развертываемым файлом EAR или WAR, который принимает запрос от конечной точки пользователя, обрабатывает его с помощью ресурсов и возвращает его пользователям. Все будет хорошо, пока бизнес не захочет изменить приведенный выше пример.

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

Бизнес-подразделению необходимо внести изменения в модуль «Поиск». Затем вам нужно изменить весь процесс поиска и повторно развернуть приложение. В этом случае вы перемещаете другие подразделения без каких-либо изменений.

Теперь снова вашему бизнес-подразделению необходимо внести некоторые изменения в модуль «Выписка», чтобы включить опцию «кошелек». Теперь вам нужно изменить модуль «Выписка» и повторно развернуть его на сервере. Обратите внимание: вы повторно развертываете различные модули своих программных пакетов, в то время как мы не внесли в него никаких изменений. А вот концепция сервис-ориентированной архитектуры, более специфичная для микросервисной архитектуры. Мы можем разработать наше монолитное приложение таким образом, чтобы каждый модуль программного обеспечения работал как независимая единица, способная независимо обрабатывать одну бизнес-задачу.

Рассмотрим следующий пример.

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

Сравним наш пример корзины покупок в линейке микросервисов. Мы можем разбить нашу корзину покупок на различные модули, такие как «Поиск», «Фильтр», «Оформление заказа», «Корзина», «Рекомендация» и т. Д. Если мы хотим создать портал корзины покупок, мы должны создать вышеупомянутые модули таким образом, что они могут подключаться друг к другу, чтобы вы могли совершать покупки круглосуточно и без выходных.

Преимущества недостатки

Ниже приведены некоторые сведения о преимуществах использования микросервиса вместо монолитного приложения.

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

  • Small in size- Микросервисы - это реализация паттерна проектирования SOA. Рекомендуется как можно дольше поддерживать свою службу. По сути, служба не должна выполнять более одной бизнес-задачи, следовательно, она будет явно небольшой по размеру и простой в обслуживании, чем любое другое монолитное приложение.

  • Focused- Как упоминалось ранее, каждый микросервис предназначен для выполнения только одной бизнес-задачи. При разработке микросервиса архитектор должен заботиться о фокусе сервиса, который является его продуктом. По определению, один микросервис должен быть по своей природе полным стеком и обеспечивать предоставление только одного бизнес-свойства.

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

  • Technology heterogeneity- Микросервис поддерживает различные технологии для связи друг с другом в одном бизнес-подразделении, что помогает разработчикам использовать правильную технологию в правильном месте. Реализуя гетерогенную систему, можно получить максимальную безопасность, скорость и масштабируемость.

  • Resilience- Устойчивость - это свойство изолировать программный модуль. Микросервис следует высокому уровню устойчивости в методологии построения, поэтому всякий раз, когда выходит из строя одно подразделение, это не влияет на весь бизнес. Устойчивость - еще одно свойство, позволяющее реализовать хорошо масштабируемую и менее связанную систему.

  • Ease of deployment- Поскольку все приложение разделено на небольшие части, каждый компонент должен быть по своей природе полным стеком. Все они могут быть легко развернуты в любой среде с меньшими временными затратами, в отличие от других монолитных приложений того же типа.

Ниже приведены некоторые замечания о недостатках микросервисной архитектуры.

Недостатки

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

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

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

Микросервис поверх SOA

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

Составная часть SOA Микросервис
Шаблон дизайна SOA - это парадигма проектирования компьютерного программного обеспечения, в которой компоненты программного обеспечения открываются внешнему миру для использования в форме сервисов. Микро-сервис является частью SOA. Это специализированная реализация SOA.
Зависимость Бизнес-единицы зависят друг от друга. Все бизнес-единицы независимы друг от друга.
Размер Размер программного обеспечения больше, чем у обычного программного обеспечения. Размер программного обеспечения невелик.
Технологии Стек технологий меньше микросервиса. Микросервис неоднороден по своей природе, поскольку для решения конкретной задачи используются точные технологии. Микросервисы можно рассматривать как конгломерат многих технологий.
Автономный и фокус Приложения SOA созданы для выполнения множества бизнес-задач. Приложения микросервисов созданы для выполнения одной бизнес-задачи.
Природа Монолитный по своей природе. Полный стек в природе.
Развертывание Развертывание занимает много времени. Развертывание очень простое. Следовательно, это займет меньше времени.
Рентабельность Более рентабельно. Менее рентабельно.
Масштабируемость Меньше по сравнению с микросервисами. Полностью масштабируется.
пример Давайте рассмотрим одно онлайн-приложение для бронирования CAB. Если мы хотим создать это приложение с использованием SOA, его программные модули будут:
  • GetPayments и DriverInformation и MappingDataAPI
  • Аутентифицировать пользователей и драйверы API
Если то же приложение построено с использованием микросервисной архитектуры, его API-интерфейсы будут:
  • SubmitPaymentsService
  • GetDriverInfoService
  • GetMappingDataService
  • AuthenticateUserService
  • AuthenticateDriverService