Микросервисная архитектура - Введение
Микросервис - это методология разработки приложений на основе служб. В этой методологии большие приложения будут разделены на самые маленькие независимые сервисные единицы. Микросервис - это процесс реализации сервис-ориентированной архитектуры (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, его программные модули будут:
|
Если то же приложение построено с использованием микросервисной архитектуры, его API-интерфейсы будут:
|