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

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

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

Микросервисная архитектура — масштабирование

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

Масштабирование по оси X

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

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

Масштабирование по оси Y

Масштабирование по оси Y также называется вертикальным масштабированием, которое включает в себя любое масштабирование уровня ресурса. Любая система DBaaS или Hadoop может считаться масштабируемой по оси Y. При таком типе масштабирования пользовательский запрос перенаправляется и ограничивается путем реализации некоторой логики.

Давайте рассмотрим Facebook в качестве примера. Facebook должен обрабатывать 1,79 миллиона пользователей в секунду; следовательно, управление трафиком является огромной ответственностью сетевых инженеров Facebook. Чтобы избежать любой опасности, они используют масштабирование по оси Y, которое включает запуск нескольких серверов с одним и тем же приложением одновременно. Теперь, чтобы контролировать этот огромный уровень трафика, Facebook перенаправляет весь трафик из одного региона на конкретный сервер, как показано на рисунке. Эта передача трафика в зависимости от региона называется балансировкой нагрузки на архитектурном языке.

Этот метод разделения ресурсов на небольшие независимые бизнес-единицы известен как масштабирование по оси Y.

Масштабирование по оси Z

Масштабирование по осям X и Y гораздо проще для понимания. Однако одно приложение также можно масштабировать на бизнес-уровне, которое называется масштабированием по оси Z. Ниже приведен пример масштабирования приложения службы такси в различных вертикалях бизнес-единиц.

Преимущества масштабирования

• Стоимость — Правильное масштабирование программного обеспечения снизит стоимость обслуживания.

• Производительность. Из-за слабой связи производительность правильно масштабируемого программного обеспечения всегда лучше, чем немасштабированного программного обеспечения.

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

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

Стоимость — Правильное масштабирование программного обеспечения снизит стоимость обслуживания.

Производительность. Из-за слабой связи производительность правильно масштабируемого программного обеспечения всегда лучше, чем немасштабированного программного обеспечения.

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

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

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

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

Правило и рабочий процесс

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

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

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

• Business Domain Centric — программное обеспечение будет модульным в соответствии с бизнес-единицей и не будет основано на уровнях.

• Автоматизация — Тестирование развертывания будет автоматизировано. Попробуйте ввести минимальное человеческое взаимодействие.

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

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

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

Business Domain Centric — программное обеспечение будет модульным в соответствии с бизнес-единицей и не будет основано на уровнях.

Автоматизация — Тестирование развертывания будет автоматизировано. Попробуйте ввести минимальное человеческое взаимодействие.

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

Управление командой

«Two Pizza Rule» — это своего рода правило, ограничивающее количество участников в команде разработчиков микросервисов. Согласно этому правилу, количество членов команды одного приложения должно быть настолько маленьким, чтобы их можно было кормить двумя пиццами. Как правило, это число не должно превышать 8. Поскольку микросервис имеет полный стек по своей природе, команда также имеет полный стек по своей природе. Чтобы повысить производительность, нам нужно собрать одну команду, состоящую максимум из 8 человек, со всеми видами опыта, необходимыми для этой услуги.

Управление задачами

Задача играет важную роль в жизненном цикле разработки программного обеспечения. Разработка крупномасштабного приложения может быть разбита на несколько небольших блоков задач. Давайте рассмотрим необходимость разработки одного приложения, такого как Facebook. Тогда функциональность «Вход в систему» ​​можно рассматривать как задачу всего процесса сборки. Ход выполнения каждой из этих задач должен контролироваться должным образом под руководством высококвалифицированных специалистов. Agile — это хорошо известная структура процессов, используемая в отраслях для обеспечения хорошего управления задачами.

Разные элементы

До сих пор мы узнали, что такое микросервис и каковы его основные потребности над современной архитектурой MVC. В этой главе мы изучим различные элементы этой архитектуры, которые одинаково важны для службы.

Категории услуг

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

Платформа как услуга [PaaS] — в этой сервис-ориентированной архитектуре платформа предоставляется как инструмент, который можно настроить в соответствии с потребностями бизнеса. PaaS играет важную роль в разработке мобильных приложений. Наилучшим примером PaaS является движок Google App, где Google предоставляет другую полезную платформу для создания вашего приложения. PaaS изначально разрабатывается для предоставления разработчикам встроенной архитектуры или инфраструктуры. Это уменьшает сложность программирования более высокого уровня в значительно сокращенное время. Ниже приведен снимок предоставленного Google PaaS.

Программное обеспечение как услуга [SaaS] — Программное обеспечение как услуга — это бизнес по лицензированию программного обеспечения, где программное обеспечение размещается централизованно и лицензируется на основе подписки. Доступ к SaaS возможен в основном через браузер, и это очень распространенный шаблон архитектуры во многих бизнес-вертикалях, таких как управление персоналом (HRM), планирование ресурсов предприятия (ERP), управление взаимоотношениями с клиентами (CRM) и т. Д. На следующем снимке экрана показаны примеры различные SaaS, предоставляемые Oracle.

Инфраструктура как услуга [IaaS] — Инфраструктура играет важную роль в ИТ-индустрии. Используя облачные вычисления, некоторые организации предоставляют виртуальную инфраструктуру в качестве своих услуг. IaaS очень полезен для обеспечения гибкости, экономичности, безопасности, производительности, производительности и т. Д. При разработке программного обеспечения. Amazon EC2 и Microsoft Azure являются крупнейшими примерами IaaS. На следующем изображении показан пример AWS, где центр обработки данных представлен как IaaS.

Данные как услуга [DaaS]. Информационные технологии работают с данными, и некоторые ведущие лидеры отрасли считают, что данные станут новой опорой для общества. DaaS — это тип сервиса, в котором данные передаются бизнес-конгломератам для исследований и анализа. DaaS обеспечивает простоту, гибкость и безопасность на уровне доступа к данным. Ниже приведен пример облака данных Oracle, к которому можно получить доступ или получить лицензию для собственных нужд бизнеса.

Бэкэнд как услуга [BaaS] — BaaS также известен как MBaaS, что означает мобильный бэкэнд как услуга. В этом типе обслуживания бэкэнд приложения будет предоставляться подразделениям для их собственных предприятий. Все push-уведомления, сервисы социальных сетей подпадают под этот тип сервисов. Facebook и Twitter являются примерами известного поставщика услуг BaaS.

Безопасность

Когда дело доходит до тонны пользовательских данных, безопасность играет важную роль. Проблема безопасности связана со всеми видами услуг, доступных на рынке. Независимо от того, какое облако вы используете — частное, общедоступное, гибридное и т. Д., Безопасность должна поддерживаться на всех уровнях. Вся проблема безопасности может быть разделена на следующие части:

• Проблема безопасности, с которой сталкиваются поставщики услуг. С такими проблемами безопасности сталкиваются поставщики услуг, такие как Google, Amazon и т. Д. Для обеспечения защиты необходима проверка данных клиента, особенно тех, кто имеет прямой доступ к основной части. облако.

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

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

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

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

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

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

• Детективный контроль — следите за своими пользователями и выявляйте любой потенциальный риск.

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

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

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

Детективный контроль — следите за своими пользователями и выявляйте любой потенциальный риск.

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

Композиции Шаблоны

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

Функциональная декомпозиция играет важную роль в создании ваших микросервисов. Это обеспечивает гибкость, гибкость и масштабируемость для вашего приложения.

Агрегатор

Агрегаторный паттерн — это самый простой веб-паттерн, который можно реализовать при разработке микросервиса. В этом шаблоне композиции простой веб-модуль будет действовать как балансировщик нагрузки, что означает, что он будет вызывать различные службы в соответствии с требованиями. Ниже приведена схема, изображающая простое микросервисное веб-приложение с дизайном агрегатора. Как видно на следующем рисунке, «Агрегатор» отвечает за вызов различных сервисов один за другим. Если нам нужно применить какую-либо бизнес-логику к результатам службы A, B и C, то мы можем реализовать бизнес-логику в самом агрегаторе.

Агрегатор может быть снова выставлен как другой сервис для внешнего мира, который может потребляться другими при необходимости. При разработке веб-службы шаблонов агрегатора мы должны учитывать, что каждый из наших сервисов A, B и C должен иметь свои собственные уровни кэширования, и он должен иметь полный стек по своей природе.

Прокси шаблон

Шаблон прокси-микросервиса — это разновидность модели агрегатора. В этой модели мы будем использовать модуль прокси вместо модуля агрегации. Прокси-сервис может вызывать разные сервисы индивидуально.

В шаблоне Proxy мы можем создать один уровень дополнительной безопасности, предоставив слой прокси-сервера дампа. Этот слой действует аналогично интерфейсу.

Цепной узор

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

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

Микросервисная структура филиала

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

Паттерн микросервиса филиала позволяет разработчику динамически настраивать вызовы сервиса. Все сервисные вызовы будут происходить одновременно, а это означает, что сервис A может вызывать сервис B и C одновременно.

Шаблон общих ресурсов

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

Микросервисная архитектура — практическая SOA

В этой главе мы разработаем приложение на основе CRUD с архитектурой SOA. Позже в последующих главах мы разберем этот сервис на микросервис и узнаем основное различие между SOA и архитектурой микросервисов.

Конфигурация и настройка системы

В этом разделе мы создадим пример приложения CRUD, которое будет возвращать объект JSON в качестве ответа при каждом вызове нашего сервиса. Мы будем использовать структуру Джерси, чтобы разработать то же самое. Ниже приведены шаги по настройке среды вашей локальной системы.

Разработка приложения CRUD

Шаг 1. Мы будем использовать NetBeans в качестве среды разработки. Загрузите и установите последнюю версию, доступную на официальном веб-сайте NetBeans https://netbeans.org/downloads/ .

Шаг 2. Откройте свою среду IDE NetBeans. Перейдите в «Файл -> Новый проект». Появится следующий скриншот. Выберите «Maven» в качестве категории и выберите «Project from ArchType» в качестве проекта и нажмите «Далее».

Это загрузит все необходимые файлы jar для создания вашего первого проекта Maven и веб-службы RESTful.

Шаг 3 — При нажатии кнопки «Далее» на предыдущем шаге появляется следующий снимок экрана. Здесь вам нужно будет указать Maven Archetype.

В окне поиска выполните поиск по запросу «Jersey-archType-Webapp (2.16)» и установите флажок «Показать более старый».

Шаг 4 — Как только вы выбрали то же самое, вы будете перенаправлены на следующий экран. Выберите предпочитаемую банку из списка и нажмите «Далее», чтобы продолжить.

Шаг 5 — На этом шаге вам необходимо указать название вашего проекта и идентификатор группы, а также сведения о пакете. После предоставления всей этой информации нажмите «Готово», чтобы продолжить.

Шаг 6 — Вы закончили настройку рабочего пространства. Каталог проекта будет выглядеть следующим образом.

Проверьте папку «Зависимости», и вы обнаружите, что Maven автоматически загрузил все необходимые файлы JAR для этого проекта.

Шаг 7 — Ваше рабочее пространство настроено, и вы можете начать с кодирования. Создайте четыре класса и пакеты, как указано на следующем снимке экрана. Вы можете обнаружить, что MyResource.java уже создан Maven, поскольку Maven достаточно умен, чтобы определить, что вы собираетесь создать свой собственный веб-сервис.

Шаг 8. После выполнения вышеуказанного шага мы создадим наш класс POJO, который будет UserProfile.java, следующим образом.

package com.tutorialspoint.userprofile.Model;

import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
public class UserProfile {
   private long ProId;
   private String FName;
   private String LName;
   private String Add;
   public UserProfile(){}
   
   public UserProfile(long Proid, String Fname, String Lname,String Add) {
      this.ProId = Proid;
      this.FName = Fname;
      this.LName = Lname;
      this.Add = Add;
   }
   public long getProId() {
      return ProId;
   }
   public void setProId(long ProId) {
      this.ProId = ProId;
   }
   public String getFName() {
      return FName;
   }
   public void setFName(String FName) {
      this.FName = FName;
   }
   public String getLName() {
      return LName;
   }
   public void setLName(String LName) {
      this.LName = LName;
   }
   public String getAdd() {
      return Add;
   }
   public void setAdd(String Add) {
      this.Add = Add;
   }
}

Шаг 9 — Теперь мы создадим наш класс базы данных. Поскольку это часть учебного материала, мы не будем использовать БД в качестве нашей базы данных. Мы будем использовать встроенную память Java, чтобы работать как наша временная память. Как вы можете видеть в следующем наборе кода, мы будем использовать MAP в качестве нашей базы данных. Все операции веб-службы, которые мы выполняем, мы будем работать с этой MAP, определенной в классе.

package com.tutorialspoint.userprofile.DAO;

import com.tutorialspoint.userprofile.Model.UserProfile;

import java.util.HashMap;
import java.util.Map;

public class DatabaseClass {
   private static Map<Long,UserProfile> messages = new HashMap<Long,UserProfile>();
   public static Map<Long,UserProfile> getUsers() {
      return messages; 
      // Each time this method will return entire map as an instance of database
   }
}

Шаг 10 — Теперь давайте построим наш класс обслуживания. Затем скопируйте и вставьте следующий код в класс «ProfileService.java». Это класс, в котором мы будем объявлять все методы наших веб-сервисов, которые будут доступны для внешнего мира. Нам нужно создать одну ссылку на наш DatabaseClass, чтобы наша временная база данных была доступна в этом классе.

package com.tutorialspoint.userprofile.service;

import com.tutorialspoint.userprofile.DAO.DatabaseClass;
import com.tutorialspoint.userprofile.Model.UserProfile;

import java.util.ArrayList;
import java.util.List;
import java.util.Map;

public class ProfileService {
   private Map<Long,UserProfile> Userprofiles = DatabaseClass.getUsers();
   
   // Creating some predefine profile and populating the same in the map
   public ProfileService() {
      UserProfile m1 = new UserProfile(1L,"Tutorials1","Point1","TutorialsPoint.com");
      UserProfile m2 = new UserProfile(2L,"Tutorials2","Point2","TutorialsPoint.com2");
      UserProfile m3 = new UserProfile(3L,"Tutorials3","Point3","TutorialsPoint.com3");
      UserProfile m4 = new UserProfile(4L,"Tutorials4","Point4","TutorialsPoint.com4");
      
      Userprofiles.put(1L, m1);
      Userprofiles.put(2L, m2);
      Userprofiles.put(1L, m3);
      Userprofiles.put(2L, m4);
   }
   
   //Method to fetch all profile
   public List<UserProfile> getAllProfile() {
      List<UserProfile> list = new ArrayList<UserProfile>(Userprofiles.values());
      return list;
   }  // Method to fetch only one profile depending on the ID provided
   
   public UserProfile getProfile(long id) {
      return Userprofiles.get(id);
   }  //Method to add profile
   
   public UserProfile addProfile(UserProfile UserProfile) {
      UserProfile.setProId(Userprofiles.size()+1);
      Userprofiles.put(UserProfile.getProId(), UserProfile);
      return UserProfile;
   }  //method to update Profile

   public UserProfile UpdateProfile(UserProfile UserProfile) {
      if(UserProfile.getProId()<=0) { 
         return null;
      } else { 
         Userprofiles.put(UserProfile.getProId(), UserProfile);
         return UserProfile;
      }
   } //method to delete profile
   
   public void RemoveProfile(long Id) {
      Userprofiles.remove(Id);
   }
}

Шаг 11 — На этом шаге мы создадим наш класс Resource, который будет связан с URL, и будет вызвана соответствующая служба.

package com.tutorialspoint.userprofile.Resource;

import com.tutorialspoint.userprofile.Model.UserProfile;
import com.tutorialspoint.userprofile.service.ProfileService;

import java.util.List;
import javax.ws.rs.Consumes;
import javax.ws.rs.DELETE;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("/Profile")
@Consumes(MediaType.APPLICATION_XML)
@Produces(MediaType.APPLICATION_XML)

public class ProfileResource {
   ProfileService messageService = new ProfileService();
   
   @GET
   public List<UserProfile> getProfile() {
      return messageService.getAllProfile();
   }

   @GET
   @Path("/{ProID}")
   public UserProfile getProfile(@PathParam("ProID")long Id) {
      return messageService.getProfile(Id);
   }

   @POST
   public UserProfile addProfile(UserProfile profile) {
      return messageService.addProfile(profile);
   }

   @PUT
   @Path("/{proID}")
   public UserProfile UpdateProfile(@PathParam("proID")long Id,UserProfile UserProfile) {
      UserProfile.setProId(Id);
      return messageService.UpdateProfile(UserProfile);
   }
   
   @DELETE
   @Path("/{ProID}")
   public void deleteProfile(@PathParam("ProID")long Id) {
      messageService.RemoveProfile(Id);
   }
}

Шаг 12 — Чистая сборка проекта и запуск его. Если все идет хорошо, вы должны получить следующий вывод в браузере, имея доступ к URL http: // localhost: 8080 / UserProfile / webapi / Profile .

Вы можете видеть, что различные записи заполняются с использованием представления XML.

Другой метод может быть протестирован с помощью Postman, применяя правильный метод URL.

Метод @GET — на следующем снимке экрана показано, как мы можем получить желаемый результат для запроса get, который возвращает все данные пользователя.

@POST — следующий запрос может быть использован для проверки нашего метода Post. Обратите внимание, как proId был сгенерирован автоматически.

@PUT — этот метод обновит записи. На следующем снимке экрана показано, как Джерси берет proId из URL-адреса запроса и обновляет тот же ответ профиля пользователя.

Таким же образом вы можете проверить другие методы, доступные в ваших веб-сервисах.

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

Актер должен быть отправной точкой нашего сервиса. В этом случае «ProfileResource.java» выполняет ответственность актера. Этот класс будет вызывать разные методы для выполнения разных операций, таких как добавление, обновление и удаление.

Декомпозиция приложения CRUD

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

«Основной пользователь» — это пользователь, который связывается с «Контроллером приложений» для удовлетворения своих потребностей. «Контроллер приложений» — это тот, кто просто вызывает разных «менеджеров ресурсов» в зависимости от запроса от конечного пользователя. «Resource Manager» выполняет ту работу, которую необходимо выполнить. Давайте кратко рассмотрим различные роли различных модулей приложения.

• Конечный пользователь / Основные пользователи — Запросы на некоторые ресурсы для Application Controller.

• Приложение — получает запрос и перенаправляет его конкретному менеджеру ресурсов.

• Resource Manager — выполняет реальную работу по обновлению, удалению и добавлению пользователей.

Конечный пользователь / Основные пользователи — Запросы на некоторые ресурсы для Application Controller.

Приложение — получает запрос и перенаправляет его конкретному менеджеру ресурсов.

Resource Manager — выполняет реальную работу по обновлению, удалению и добавлению пользователей.

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

Микросервисная архитектура — практический MSA

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

Конфигурация и настройка системы

Прежде чем перейти к этапу сборки, подготовьте свою систему соответствующим образом. Вам понадобятся некоторые публичные веб-сервисы. Вы можете легко Google для этого. Если вы хотите использовать веб-службу SOAP, вы получите один файл WSDL, а оттуда вам нужно использовать конкретный веб-сервис. Для службы REST вам потребуется только одна ссылка, чтобы потреблять то же самое. В этом примере вы объедините три разных веб-сервиса «SOAP», «REST» и «custom» в одном приложении.

Архитектура приложений

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

Ниже приведены шаги для разработки приложения микросервиса.

Шаг 1. Создание клиента для службы SOAP. Существует множество бесплатных веб-API, доступных для изучения веб-службы. Для целей данного руководства используйте сервис GeoIP по адресу http://www.webservicex.net/. Файл WSDL находится по следующей ссылке на их веб-сайте « webservicex.net. Чтобы сгенерировать клиента из этого файла WSDL, все, что вам нужно сделать, это запустить следующую команду в вашем терминале.

wsimport http://www.webservicex.net/geoipservice.asmx?WSDL

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

Шаг 2. Создайте свой собственный веб-сервис. Выполните ту же процедуру, которая была упомянута на предыдущем этапе в этом руководстве, и создайте API-интерфейс REST на основе Maven с именем «CustomRest». По завершении вы найдете класс с именем «MyResource.java». Идите вперед и обновите этот класс, используя следующий код.

package com.tutorialspoint.customrest;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("myresource")
public class MyResource {
   @GET
   @Produces(MediaType.TEXT_PLAIN)
   
   public String getIt() {
      return "IND|INDIA|27.7.65.215";
   }
}

Когда все будет готово, запустите это приложение на сервере. Вы должны получить следующий вывод в браузере.

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

Шаг 3. Настройте другой API отдыха. На этом шаге используйте другой веб-сервис, доступный по адресу services.groupkt.com. Это вернет объект JSON при вызове.

Шаг 4. Создание приложения JAVA. Создайте одно обычное приложение Java, выбрав «Новый проект» -> «Проект JAVA» и нажмите «Готово», как показано на следующем снимке экрана.

Шаг 5. Добавление клиента SOAP. На шаге 1 вы создали файл клиента для веб-службы SOAP. Идите дальше и добавьте эти файлы клиента в ваш текущий проект. После успешного добавления файлов клиента каталог вашего приложения будет выглядеть следующим образом.

Шаг 6. Создайте главное приложение. Создайте основной класс, в котором вы будете использовать все эти три веб-службы. Щелкните правой кнопкой мыши по исходному проекту и создайте новый класс с именем «MicroServiceInAction.java». Следующая задача — вызвать разные веб-сервисы из этого.

Шаг 7. Позвоните в пользовательский веб-сервис. Для этого добавьте следующий набор кодов, чтобы реализовать вызов собственного сервиса.

try {
   url = new URL("http://localhost:8080/CustomRest/webapi/myresource");
   conn = (HttpURLConnection) url.openConnection();
   conn.setRequestMethod("GET");
   conn.setRequestProperty("Accept", "application/json");
   
   if (conn.getResponseCode() != 200) {
      throw new RuntimeException("Failed : HTTP error code : " + conn.getResponseCode());
   }
   
   BufferedReader br = new BufferedReader(new InputStreamReader(
      (conn.getInputStream())));
   while ((output = br.readLine()) != null) {
      inputToOtherService = output;
   }
   conn.disconnect();

} catch (MalformedURLException e) {
   e.printStackTrace();
} catch (IOException e) {
   e.printStackTrace();
}

Шаг 8. Использование служб SOAP. Вы создали клиентский файл, но не знаете, какой метод следует вызывать во всем пакете? Для этого вам нужно снова обратиться к WSDL, который вы использовали для генерации ваших клиентских файлов. Каждый файл WSDL должен иметь один тег «wsdl: service» для поиска этого тега. Это должна быть ваша точка входа в этот веб-сервис. Ниже приводится конечная точка службы этого приложения.

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

GeoIPService newGeoIPService = new GeoIPService();
GeoIPServiceSoap newGeoIPServiceSoap = newGeoIPService.getGeoIPServiceSoap();
GeoIP newGeoIP = newGeoIPServiceSoap.getGeoIP(Ipaddress);  
// Ipaddress is output of our own web service.

System.out.println("Country Name from SOAP Webserivce ---"+newGeoIP.getCountryName());

Шаг 9. Использование веб-службы REST. Две из этих служб использовались до сих пор. На этом шаге другой веб-сервис REST с настроенным URL-адресом будет использоваться с помощью вашего пользовательского веб-сервиса. Используйте следующий набор кода для этого.

String url1="http://services.groupkt.com/country/get/iso3code/";//customizing the Url
url1 = url1.concat(countryCode);

try {
   URL url = new URL(url1);
   HttpURLConnection conn = (HttpURLConnection) url.openConnection();
   conn.setRequestMethod("GET");
   conn.setRequestProperty("Accept", "application/json");
   
   if (conn.getResponseCode() != 200) {
      throw new RuntimeException("Failed : HTTP error code : " + conn.getResponseCode());
   }
   
   BufferedReader br = new BufferedReader(new InputStreamReader(
      (conn.getInputStream())));
   while ((output = br.readLine()) != null) {
      System.out.println(output);
   }
   conn.disconnect();

} catch (MalformedURLException e) {
   e.printStackTrace();
} catch (IOException e) {
   e.printStackTrace();
}

Шаг 10. Использование всех сервисов. Учитывая, что ваш веб-сервис «CustomRest» запущен и вы подключены к Интернету, если все выполнено успешно, то следующим должен быть ваш консолидированный основной класс.

package microserviceinaction;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
import java.util.StringTokenizer;

import net.webservicex.GeoIP;
import net.webservicex.GeoIPService;
import net.webservicex.GeoIPServiceSoap;

public class MicroServiceInAction {
   static URL url;
   static HttpURLConnection conn;
   static String output;
   static String inputToOtherService;
   static String countryCode;
   static String ipAddress;
   static String CountryName;
   public static void main(String[] args) {
      //consuming of your own web service
      try {
         url = new URL("http://localhost:8080/CustomRest/webapi/myresource");
         conn = (HttpURLConnection) url.openConnection();
         conn.setRequestMethod("GET");
         conn.setRequestProperty("Accept", "application/json");
         
         if (conn.getResponseCode() != 200) {
            throw new RuntimeException("Failed : HTTP error code : " + conn.getResponseCode());
         }
         
         BufferedReader br = new BufferedReader(new InputStreamReader(
            (conn.getInputStream())));
         while ((output = br.readLine()) != null) {
            inputToOtherService = output;
         }
         conn.disconnect();
      
      } catch (MalformedURLException e) {
         e.printStackTrace();
      } catch (IOException e) {
         e.printStackTrace();
      }
      
      //Fetching IP address from the String and other information
      StringTokenizer st = new StringTokenizer(inputToOtherService);
      countryCode = st.nextToken("|");
      CountryName = st.nextToken("|");
      ipAddress = st.nextToken("|");
      
      // Call to SOAP web service with output of your web service--- 
      // getting the location of our given IP address
      String Ipaddress = ipAddress;
      GeoIPService newGeoIPService = new GeoIPService();
      GeoIPServiceSoap newGeoIPServiceSoap = newGeoIPService.getGeoIPServiceSoap();
      GeoIP newGeoIP = newGeoIPServiceSoap.getGeoIP(Ipaddress);
      System.out.println("Country Name from SOAP Webservice ---"+newGeoIP.getCountryName());
      
      // Call to REST API --to get all the details of our country
      String url1 = "http://services.groupkt.com/country/get/iso3code/"; //customizing the Url
      url1 = url1.concat(countryCode);
      
      try {
         URL url = new URL(url1);
         HttpURLConnection conn = (HttpURLConnection) url.openConnection();
         conn.setRequestMethod("GET");
         conn.setRequestProperty("Accept", "application/json");
			
         if (conn.getResponseCode() != 200) {
            throw new RuntimeException("Failed : HTTP error code : " + conn.getResponseCode());
         }
      
         BufferedReader br = new BufferedReader(new InputStreamReader(
            (conn.getInputStream())));
         while ((output = br.readLine()) != null) {
            System.out.println(output);
         }
      
         conn.disconnect();
      } catch (MalformedURLException e) {
         e.printStackTrace();
      } catch (IOException e) {
         e.printStackTrace();
      }
   }
}

Запустив этот файл, вы увидите следующий вывод в консоли. Вы успешно разработали свое первое микросервисное приложение.