Архитектура микросервисов - изучение, создание и развертывание микросервисов

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

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

В этом блоге вы узнаете о следующем:

аспирант такой же, как магистр

• Определение микросервисной архитектуры
• Ключевые концепции микросервисной архитектуры
• Плюсы и минусы микросервисной архитектуры
• UBER - Пример использования

Вы можете обратиться к , чтобы понять основы и преимущества микросервисов.

Будет справедливо, если я дам вам определение микросервисов.

Определение микросервисов

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

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

Рисунок 1: Разница между монолитной и микросервисной архитектурой - микросервисная архитектура

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

Чтобы вы лучше поняли, позвольте мне рассказать вам несколько ключевых концепций микросервисной архитектуры.

Ключевые концепции микросервисной архитектуры

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

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

Рекомендации при разработке микросервисов

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

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

Как работает микросервисная архитектура?

Типичная микросервисная архитектура (MSA) должна состоять из следующих компонентов:

1. Клиенты
2. Поставщики удостоверений
3. API шлюза
4. Форматы сообщений
5. Базы данных
6. Статический контент
7. Управление
8. Обнаружение услуг

См. Схему ниже.

Фигура 2: Архитектура микросервисов - микросервисная архитектура

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

1. Клиенты

Архитектура начинается с разных типов клиентов, с разных устройств, которые пытаются выполнять различные функции управления, такие как поиск, сборка, настройка и т. Д.

2. Провайдеры идентификационной информации

Эти запросы от клиентов затем передаются поставщикам удостоверений, которые аутентифицируют запросы клиентов и передают запросы на API-шлюз. Затем запросы передаются внутренним службам через четко определенный шлюз API.

3. API-шлюз

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

Преимущества использования шлюза API:

• Все услуги могут быть обновлены без ведома клиентов.
• Службы также могут использовать протоколы обмена сообщениями, которые не подходят для Интернета.
• Шлюз API может выполнять сквозные функции, такие как обеспечение безопасности, балансировка нагрузки и т. Д.

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

4. Форматы сообщений

Есть два типа сообщений, с помощью которых они общаются:

• Синхронные сообщения: В ситуации, когда клиенты ждут ответов от службы, микросервисы обычно используют REST (передача репрезентативного состояния) поскольку он полагается на безгражданство, клиент-сервер и Протокол HTTP . Этот протокол используется, поскольку это распределенная среда, каждая функциональность представлена ​​ресурсом для выполнения операций.
• Асинхронные сообщения: В ситуации, когда клиенты не ждут ответов от службы, микросервисы обычно используют такие протоколы, как AMQP, STOMP, MQTT . Эти протоколы используются в этом типе связи, поскольку характер сообщений определен, и эти сообщения должны взаимодействовать между реализациями.

Следующий вопрос, который может прийти вам в голову, - как приложения, использующие микросервисы, обрабатывают свои данные?

5. Обработка данных

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

Фигура 3: Представление микросервисов для обработки данных - микросервисная архитектура

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

6. Статическое содержимое

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

приведение двойного значения к int в Java

Помимо вышеперечисленных компонентов, в типичной архитектуре микросервисов присутствуют некоторые другие компоненты:

7. Управление

Этот компонент отвечает за балансировку сервисов на узлах и выявление сбоев.

8. Обнаружение услуг

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

Подпишитесь на наш канал на YouTube, чтобы получать новости ..!

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

Плюсы и минусы микросервисной архитектуры

См. Таблицу ниже.

Давайте лучше поймем микросервисы, сравнив предыдущую архитектуру UBER с нынешней.

ПРИМЕР ИССЛЕДОВАНИЯ UBER

Предыдущая архитектура UBER

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

Рисунок 4: Монолитная архитектура UBER - микросервисная архитектура

На диаграмме выше изображена предыдущая архитектура UBER.

• Присутствует REST API, с которым связываются пассажир и водитель.
• В них используются три разных адаптера с API для выполнения таких действий, как выставление счетов, платежи, отправка электронных писем / сообщений, которые мы видим, когда заказываем такси.
• База данных MySQL для хранения всех их данных.

Итак, если вы заметили здесь, все функции, такие как управление пассажирами, биллинг, функции уведомлений, платежи, управление поездками и управление водителями, были объединены в единую структуру.

Постановка задачи

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

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

Решение

Чтобы избежать таких проблем, UBER решил изменить свою архитектуру и последовать примеру других быстрорастущих компаний, таких как Amazon, Netflix, Twitter и многих других. Таким образом, UBER решил разбить свою монолитную архитектуру на несколько кодовых баз, чтобы сформировать микросервисную архитектуру.

На диаграмме ниже представлена ​​микросервисная архитектура UBER.

Фигура 5: Микросервисная архитектура UBER - микросервисная архитектура

• Главное изменение, которое мы здесь наблюдаем, - это введение API-шлюза, через который подключаются все водители и пассажиры. Из шлюза API подключаются все внутренние точки, такие как управление пассажирами, управление водителями, управление поездками и другие.
• Блоки представляют собой отдельные отдельные развертываемые блоки, выполняющие отдельные функции.
  • Например: если вы хотите что-либо изменить в микросервисах для выставления счетов, вам просто нужно развернуть только микросервисы для выставления счетов, и не нужно развертывать остальные.
• Теперь все функции масштабировались индивидуально, т.е. была удалена взаимозависимость между каждой функцией.
  • Например, мы все знаем, что количество людей, ищущих такси, сравнительно больше, чем людей, которые действительно заказывают такси и производят платежи. Из этого следует, что количество процессов, работающих с микросервисом управления пассажирами, больше, чем количество процессов, работающих с платежами.

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

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

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

Есть вопрос к нам? Пожалуйста, укажите это в комментариях к ' Микросервисная архитектура »И я вернусь к вам.