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

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

Концепция Going Micro

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

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

• Независимо — каждый микросервис должен быть развернут независимо.

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

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

Независимо — каждый микросервис должен быть развернут независимо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

Микросервис через SOA

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