Создание приложения — это все, что нужно для того, чтобы сделать его эффективным и действенным. Существуют различные способы обеспечения бесперебойной работы приложения. Основная причина, по которой приложение работает должным образом, — это изобретение микросервисной архитектуры. Микросервисная архитектура помогает вам разбивать большие компоненты на подкомпоненты, что упрощает отладку, а также помогает в функционировании веб-сайта без каких-либо хлопот.
Использование микросервисной архитектуры в вашем приложении поможет вам создать его более эффективным и действенным образом. Но есть несколько серьезных проблем, с которыми вы можете столкнуться в микросервисной архитектуре. Итак, в этой статье мы собираемся обсудить 5 основных проблем, с которыми вы можете столкнуться в микросервисной архитектуре. Давайте рассмотрим эти проблемы, а также подробно узнаем об архитектуре микросервисов.
Проблемы разработки микросервисов
Написать микросервисы просто, но поддерживать их не так просто. Мы покажем вам некоторые проблемы, с которыми мы сталкиваемся при разработке микросервисов.
Задача № 1
Представьте, что у вас есть это приложение под названием «Приложение Employee-Customer-Management», в котором есть разные модули, такие как модуль адреса, модуль курса, модуль сотрудника, модуль клиента и т. д. И это просто монолитное приложение.
Прямо сейчас ваша компания хочет внедрить архитектуру микросервисов. Итак, вы разделяете это приложение на несколько сервисов и из этого одного приложения, которое содержит много модулей, прямо сейчас вы собираетесь конвертировать все эти модули в разные сервисы и разные приложения. Рассмотрите возможность создания различных приложений Spring Boot, подобных этому.
Теперь у вас есть отдельные приложения, такие как адресная служба для модуля адреса, служба курса для модуля курса и так далее. И вы знаете, что в весенней загрузке вы можете настроить все эти приложения, и мы можем настроить наши приложения, используя файл application.properties или файл application.yaml. Теперь представьте, что во всех этих приложениях у нас есть это свойство во всех файлах свойств.
company.name = geeksforgeeks
Это общее свойство, которое существует в файле application.properties во всех наших проектах. Теперь предположим, что однажды наши требования изменятся в зависимости от клиента. Клиент говорит, что вы разрабатываете приложение для нас, поэтому мы говорим вам, что вы можете изменить стоимость компании с » geeksforgeeks » на » gfg «.
company.name = gfg
Так что вы можете сделать это, если у вас есть 5-10 микросервисов. Но представьте, что у вас есть 1000 микросервисов. Итак, как вы будете это делать? Вы хотите перейти к каждому приложению, откройте файл application.properties и сразу же измените значение company.name. Там это будет трудным испытанием. Как мы будем решать этот вопрос?
Задача № 2
Теперь давайте обсудим другой вопрос/вызов. Представьте, что вы пишете микросервисы. Ваша компания приняла архитектуру микросервисов, у вас есть служба адресов, служба сотрудников, служба курсов, служба студентов и т. д. и т. д. У вас есть много приложений с весенней загрузкой, и все приложения с весенней загрузкой развернуты на многих разных серверах, и у вас могут быть тысячи Приложения. Прямо сейчас все эти приложения, скажем, служба курсов хочет подключиться к службе адресов, служба студентов хочет подключиться к службе курсов и хочет получить некоторые данные, связанные с курсом, то как эти серверы будут взаимодействовать друг с другом? Мы просто сделаем REST вызов, и все эти серверы будут общаться друг с другом с помощью REST API. Но настоящая сложность заключается в том, что когда сервер хочет подключиться к другому серверу, то, прежде чем этот сервер подключится к этому серверу, ему необходимо знать IP- адрес и номер порта, на котором на сервере работает это конкретное приложение.
Это не будет простой работой по управлению тем, где у вас есть тысячи и тысячи приложений. Как вы будете управлять IP сервера? Как вы будете поддерживать свой номер порта, потому что каждый сервер, когда вам нужны данные с другого сервера, должен подключиться к ним, а для подключения к ним ему нужно знать IP-адрес и адрес сервера этого, и это будет действительно важная работа по обработке всех IP-адресов и серверных портов, когда у вас есть тысячи серверов, где вы разделили одно приложение на тысячи различных модулей и развернули их на разных серверах. Не думаете ли вы, что управление IP и URL-адресом сервера будет иметь решающее значение? В случае монолитного приложения, там у нас только один сервер, поэтому мы помнили IP-адрес сервера и порт, но теперь ваш монолит разбит на тысячи приложений, как вы с этим справитесь?
Задача № 3
Теперь представьте, что у нас есть служба курсов, развернутая на сервере. Предположим, приближается особое событие, например, Дивали или Рождество. И мы проводим некоторые предложения, такие как скидка 50% на этот курс. Пожалуйста, проверьте это. Теперь много людей заходят на наш сервер и пытаются отправить много запросов на сервер. Прямо сейчас наш сервер не может обрабатывать все эти одновременные запросы или все те запросы, которые поступают от наших клиентов, или, может быть, у разных людей будет другой компьютер, и они будут продолжать поражать наш сервер, и наш сервер не будет справляться с нагрузкой.
Что мы можем сделать в микросервисах, так это то, что у нас будет три разные копии нашей службы курсов, и мы развернем их на трех разных серверах, и прямо сейчас, когда от клиента будут поступать запросы, мы просто распределим запрос между несколько серверов для балансировки нагрузки.
Мы не будем ограничивать один сервер, отправляя к нему много-много запросов.
Скорее, мы хотим, чтобы этот запрос направлялся на другой сервер, и для этого мы введем балансировщик нагрузки, и наша работа будет знать, когда поступает несколько запросов, мы позаботимся о том, чтобы он был первым достигнут балансировщиком нагрузки и нагрузкой. Балансировщик будет передавать этот запрос на другой или между разными серверами и будет распределять их с балансировкой нагрузки, чтобы один сервер не был перегружен множеством запросов.
Но теперь задача состоит в том, как написать балансировщик нагрузки. Это тяжелая работа. Так что не волнуйтесь, Load Balancer поставляется бесплатно с Spring Cloud.
Задача № 4
Теперь давайте обсудим еще одну задачу. Представьте, что у вас есть тот же сервис курсов, который был развернут на сервере, и прямо сейчас есть клиент, но это не хороший клиент, это хакер.
Он знает конечную точку вашего микросервиса и представьте, что он выполняет множество запросов к вашему серверу, и, в конце концов, если у хакера есть сценарий, и он написал этот сценарий для обработки множества запросов к серверу, в конечном итоге сервер выйдет из строя. Потому что он не может обработать такое количество запросов. Итак, как вы можете справиться с этим? В конкретном сценарии, если кто-то сознательно отправляет много запросов на ваш сервер, где ему не нужно ничего делать с вашим приложением, но он просто хочет, чтобы ваш сервер вышел из строя, чтобы помешать вашему бизнесу. Ваше приложение не дойдет до целевой аудитории или ваше приложение не дойдет до ваших клиентов, и у ваших клиентов будут проблемы, потому что ваш сервер не работает, и кто-то сознательно отправляет на сервер много запросов, как вы будете ограничивать все эти вещи?
Задача № 5
Теперь давайте обсудим последнюю задачу. Представьте, что у вас есть сервер, на котором вы развернули службу для учащихся, и еще один сервер, на котором вы развернули службу для курсов.
Теперь предположим, что один сервер, т. е. Student Service, хочет получить некоторые данные курса. Итак, он делает вызов REST и нажимает на эту конечную точку под названием » /courses».’. Представьте себе, что всякий раз, когда Службе Студентов нужны данные от Службы Курсов, но что, если сервер не работает, а сейчас мы переходим с одного сервера на другой, существует абсолютная вероятность того, что этот сервер не работает, этот сервер занят, или этот сервер медленный и не может принять наш запрос и обработать его. Существует n причин, по которым сервер не будет работать должным образом. Он будет работать хорошо, что должно быть нашим приоритетом, но подумайте о негативном сценарии. Что насчет сервера, на котором вы развернули свое приложение, работает медленно или не работает, или он не может принять или обработать ваш запрос, тогда в этом случае этот запрос приведет к ошибке, и из-за этой ошибки студенческая служба также не будет работать должным образом и у этого сервера может быть много проблем из-за того, что запрос, который он делает на другой сервер, не работает. Итак, как справиться со всеми этими сценариями?
Spring Cloud как решение
И для всех этих проблем, пожалуйста, приветствуйте Spring Cloud. Spring Cloud — это проект, в рамках которого у нас есть много подпроектов, которые дадут вам абсолютное сокровище. Используя эти подпроекты, вы можете решить все эти проблемы.
- Для задачи № 1 у нас есть Spring Cloud Config Server
- Для Challenge No 2 у нас есть регистрация и обнаружение Сервиса с помощью Eureka.
- Для задачи № 3 у нас есть Spring Cloud LoadBalancer.
- Для задания № 4 у нас есть resilience4j-ratelimiter.
- Для задания № 5 у нас есть шаблон автоматических выключателей.
И все это бесплатно предоставляется Spring Boot с использованием проекта Spring Cloud, а в Spring Cloud есть все эти подпроекты, с помощью которых вы можете бесплатно создавать высокоэффективные микросервисы, не имея большого опыта создания микросервисов, вы можете создавать микросервисы на идти.
