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

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

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

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

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

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

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

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

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

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

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

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

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

Cost - Правильное масштабирование программного обеспечения снизит стоимость обслуживания.
Performance - Из-за слабой связи производительность правильно масштабируемого программного обеспечения всегда лучше, чем немасштабируемого программного обеспечения.
Load distribution - Используя различные технологии, мы легко можем поддерживать нагрузку на наш сервер.
Reuse - Масштабируемость программного обеспечения также увеличивает удобство использования программного обеспечения.

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

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

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

High Cohesion- Все бизнес-модели необходимо максимально разбить на самые мелкие бизнес-части. Каждый сервис должен быть ориентирован на выполнение только одной бизнес-задачи.
Independent - Все сервисы должны быть по своему характеру полноценными и независимыми друг от друга.
Business Domain Centric - Программное обеспечение будет модульным в соответствии с бизнес-подразделением, а не по уровням.
Automation- Развертывание тестирования будет автоматизировано. Постарайтесь минимизировать человеческое взаимодействие.
Observable - Каждая служба будет иметь полный стек по своей природе, и они должны быть независимо развертываемыми и наблюдаемыми, как корпоративное приложение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Security issue faced by service providers - С этим типом проблем безопасности сталкиваются поставщики услуг, такие как Google, Amazon и т. Д. Для обеспечения защиты необходима проверка данных клиента, особенно тех, кто имеет прямой доступ к основной части облака.
Security issue faced by consumers- Облако экономично, поэтому оно широко используется в различных отраслях. Некоторые организации хранят сведения о пользователях в сторонних центрах обработки данных и извлекают данные по мере необходимости. Следовательно, необходимо поддерживать такие уровни безопасности, чтобы любые личные данные одного клиента не были видны другим пользователям.

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

Deterrent Control - Знайте свою потенциальную угрозу, чтобы уменьшить кибератаки.
Preventive Control - Поддерживайте политику аутентификации высокого уровня для доступа к вашему облаку.
Detective Control - Следите за своими пользователями и выявляйте любые потенциальные риски.
Corrective Control - Работайте в тесном сотрудничестве с разными командами и устраняйте проблемы, возникающие на этапе детективного контроля.

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

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

Шаблон агрегатора

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

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

Шаблон прокси

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

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

Цепной узор

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

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

Шаблон микросервиса филиала

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Step 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;
   }
}

Step 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
   }
}

Step 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);
   }
}

Step 11 - На этом этапе мы создадим наш класс ресурсов, который будет связан с 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);
   }
}

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

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

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

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

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

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

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

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

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

Разложение CRUD-приложения

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

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

End User/Main Users - Запросы некоторых ресурсов к Application Controller.
Application - Получает запрос и пересылает его конкретному диспетчеру ресурсов.
Resource Manager - Выполняет фактическую работу по обновлению, удалению и добавлению пользователей.

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

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

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

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

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

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

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

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

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

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

Step 2: Create your custom web service- Выполните тот же процесс, который упоминался на более раннем этапе в этом руководстве, и создайте REST api на основе 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";
   }
}

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

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

Step 3: Configure another Rest API- На этом этапе используйте другую веб-службу, доступную по адресу services.groupkt.com. При вызове это вернет объект JSON.

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

Step 5: Add the SOAP client- На шаге 1 вы создали файл клиента для веб-службы SOAP. Продолжайте и добавьте эти клиентские файлы в свой текущий проект. После успешного добавления клиентских файлов каталог вашего приложения будет выглядеть следующим образом.

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

Step 7: Call your custom 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();
}

Step 8: Consume SOAP Services- Вы создали файл клиента, но не знаете, какой метод следует вызывать во всем пакете? Для этого вам нужно снова обратиться к 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());

Step 9: Consume REST web service- Две услуги уже использованы. На этом шаге другая веб-служба 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();
}

Step 10: Consume all services - Учитывая, что ваша веб-служба «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();
      }
   }
}

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