Микросервисы Java и Spring Boot | Полный 10-часовой Курс

• Курс посвящен созданию микросервисов с нуля.  

• Включает изучение Spring Boot, Maven, Docker и Kubernetes.  

• Курс поможет как новичкам, так и опытным разработчикам.  

• Рекомендуется присоединиться к сообществу Discord.  

• В Discord можно задавать вопросы и получать помощь.  

• Участие в сообществе помогает улучшить навыки.  

• Первый микросервис будет отвечать за регистрацию клиентов.  

• Использование Spring Boot для создания микросервисов.  

• Взаимодействие микросервисов с помощью API и баз данных.  

• Микросервисы обеспечивают гибкость и устойчивость.  

• Использование Spring Cloud для создания микросервисов.  

• Диаграмма, показывающая взаимодействие микросервисов.  

• Использование Maven для сборки проекта.  

• Установка Maven на Mac с помощью Brew.  

• Проверка установки Maven и создание проекта.  

• Открытие проекта в Intellij.  

• Настройка проекта для использования Java 17.  

• Добавление необходимых зависимостей для создания микросервисов.  

• Использование многомодульного Maven для управления зависимостями.  

• Создание папки src и открытие pom.xml.  

• Удаление ненужных зависимостей и добавление пустых плагинов.  

• Добавление зависимости spring-boot-starter.  

• Указание версии 2.5.7.  

• Использование BOM для управления зависимостями.  

• Добавление зависимости lombok.  

• Установка тестового артефакта spring-boot-starter-test.  

• Установка плагина spring-boot-maven.  

• Исправление ошибок в pom.xml.  

• Проверка зависимостей и плагинов.  

• Перезагрузка компьютера для применения изменений.  

• Подведение итогов по управлению зависимостями и сборкой.  

• Подпроекты могут выбирать зависимости по своему усмотрению.  

• Плагин spring-boot-maven используется для управления зависимостями.  

• Создаем новый проект Maven с именем "клиент".  

• Настраиваем идентификатор группы и артефакта.  

• Открываем родительский pom.xml и добавляем зависимости.  

• Добавляем зависимость spring-boot-starter-web.  

• Создаем новый пакет и класс для микросервиса.  

• Настраиваем основной метод и аргументы командной строки.  

• Создаем файл application.yaml для настройки порта и имени приложения.  

• Добавляем баннер для микросервиса.  

• Запускаем микросервис и проверяем логи.  

• Создаем класс модели с использованием lombok.  

• Добавляем поля для идентификатора, имени, фамилии и адреса электронной почты.  

• Создаем контроллер для обработки запросов.  

• Настраиваем сопоставление запросов и метод для регистрации клиента.  

• Создаем сервис для обработки запросов.  

• Преобразуем запрос в объект клиента.  

• Настраиваем базу данных и аннотируем класс для внедрения в контроллер.  

• Создаем файл docker-compose.yaml в корневой папке микросервисов.  

• Вставляем конфигурацию YAML из описания видео.  

• Запускаем базу данных через терминал с помощью команды docker-compose up -d.  

• Открываем веб-браузер и подключаемся к базе данных через localhost:5050.  

• Устанавливаем мастер-пароль и подключаемся к базе данных с именем пользователя "code amigos" и паролем "password".  

• Проверяем подключение и наличие базы данных.  

• В Intellij создаем файл application.yaml для микросервиса.  

• Вставляем конфигурацию для подключения к базе данных.  

• Добавляем зависимости для работы с базой данных в pom.xml.  

• Создаем класс Customer с аннотацией @Entity и конструктором без аргументов.  

• Создаем интерфейс для хранения клиентов и реализуем его.  

• Проверяем создание таблицы в базе данных и выполнение запросов.  

• Используем Postman для отправки запроса POST на сохранение клиента.  

• Проверяем успешное сохранение клиента в базе данных.  

• Создаем второй микросервис для проверки на мошенничество.  

• Создаем новый модуль в IntelliJ для проекта Maven.  

• Добавляем зависимости, включая spring boot starter web.  

• Переходим к src и видим, что модуль уже настроен.  

• Добавляем зависимости от базы данных.  

• Создаем новый пакет и основной класс для мошенничества.  

• Добавляем аннотацию @SpringBootApplication и запускаем приложение.  

• Настраиваем порт для микросервиса, чтобы избежать конфликтов с клиентом.  

• Копируем файл application.yml и добавляем баннер.txt.  

• Запускаем клиентское приложение для проверки.  

• Создаем базу данных для микросервиса мошенничества.  

• Копируем конфигурацию базы данных из клиентского микросервиса.  

• Добавляем зависимости jpa spring data и драйвер postgres.  

• Создаем класс для истории проверок на мошенничество.  

• Добавляем конструктор данных и сущность с идентификатором.  

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

• Создаем интерфейс для хранилища истории проверок на мошенничество.  

• Использование JPA для хранения истории проверок на мошенничество.  

• Проверка клиента на мошенничество с использованием целочисленного идентификатора.  

• Возвращение false, если клиент не является мошенником.  

• Сохранение факта проверки в базе данных.  

• Использование конструктора для добавления данных проверки.  

• Создание контроллера для проверки на мошенничество.  

• Определение метода для проверки на мошенничество.  

• Использование переменной path для получения идентификатора клиента.  

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

• Преобразование записей в обычные классы для упрощения кода.  

• Удаление конструкторов и использование аннотаций.  

• Применение изменений к клиенту и контроллеру.  

• Клиент отправляет запрос на проверку мошенничества.  

• Использование шаблона REST для отправки запроса.  

• Настройка конфигурации для отправки запроса.  

• Создание класса для конфигурации клиента.  

• Использование шаблона REST для отправки запроса.  

• Передача идентификатора клиента и получение ответа.  

• Сохранение и удаление клиента.  

• Получение идентификатора клиента.  

• Обработка ответа на проверку мошенничества и создание исключений.  

• Проверка корректности URL-адреса для отправки запроса.  

• Тестирование изменений для проверки работы микросервисов.  

• Запускаем микросервис по борьбе с мошенничеством и микросервис для клиентов.  

• Проверяем работу микросервисов через Postman и pgAdmin.  

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

• Добавляем протоколирование в микросервис для борьбы с мошенничеством.  

• Проверяем, что клиентский контролер также регистрирует информацию.  

• Обсуждаем необходимость реестра служб для масштабирования.  

• Объясняем, как Eureka помогает микросервисам находить друг друга.  

• Сервер Eureka хранит информацию о хостах и портах микросервисов.  

• Микросервисы используют сервер для связи друг с другом.  

• Spring Cloud Sleuth обеспечивает автоматическую настройку для распределенной трассировки.  

• Настраивает хранение данных трассировки и отправку данных через Zipkin.  

• Объясняет, как работают идентификаторы трассировки и диапазона.  

• Добавляем Spring Cloud Sleuth в микросервисы для улучшения трассировки.  

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

• Завершаем настройку и продолжаем работу с микросервисами.  

• Все приложения перезапущены.  

• Открываем Postman и отправляем запрос в клиентский микросервис.  

• Получаем статус-кво 200.  

• Открываем панель управления Zipkin.  

• Находим след и видим запрос от сервера Eureka.  

• Клиентский запрос занимает около 2,798 секунд.  

• Расширяем поле и видим идентификатор трассировки и задействованные микросервисы.  

• Запрос клиента на мошенничество занимает около 2,798 секунд.  

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

• Можно увидеть дополнительную информацию о запросе, включая класс контроллера и метод MVC.  

• Возможность загрузки файла JSON для анализа.  

• Продолжительность запроса и число погибших.  

• Отправка еще одного запроса показывает значительное улучшение производительности.  

• Запрос занимает около 400 миллисекунд.  

• Сервер Eureka создает много шума, но результаты не сохраняются в базе данных.  

• Распределенная трассировка с использованием Zipkin и Spring Cloud Sleuth.  

• Возможность поиска по идентификатору трассировки в логах.  

• Использование поиска для диагностики проблем в микросервисах.  

• Возможность поиска по имени сервиса для диагностики проблем.  

• Объединение результатов поиска для получения точных данных.  

• Вопросы и комментарии приветствуются.  

• Балансировка нагрузки помогает распределить нагрузку между несколькими экземплярами приложения.  

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

• При увеличении числа клиентов требуется масштабирование, что приводит к проблемам с ресурсами.  

• При увеличении числа клиентов до 10-100, один экземпляр не справляется с нагрузкой.  

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

• Балансировка нагрузки решает эту проблему, распределяя трафик между экземплярами.  

• Внешний балансировщик нагрузки является основной точкой входа для клиентов.  

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

• Балансировщики нагрузки могут поддерживать множество функций, таких как TLS, управление сертификатами и аутентификация.  

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

• Облачные провайдеры, такие как Google Cloud и AWS, предоставляют управляемые балансировщики нагрузки.  

• Эти балансировщики поддерживают передовые протоколы и предоставляют множество функций для управления трафиком.  

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

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

• В текущей реализации нет асинхронного взаимодействия между микросервисами.  

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

• Зависимость от Twilio или Firebase может привести к задержкам в доставке уведомлений.  

• Один экземпляр уведомления может не справиться с нагрузкой.  

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

• Асинхронность и масштабирование уведомлений остаются нерешенными.  

• В IntelliJ запущены все микросервисы, и уведомления о мошенничестве работают.  

• Запрос на шлюз API занимает около 941 миллисекунды.  

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

• Очередь сообщений позволяет отправлять запросы и получать подтверждения.  

• Это устраняет необходимость ждать 18 секунд, пока уведомление будет обработано.  

• Использование очереди сообщений улучшает пользовательский опыт и масштабируемость.  

• Apache Kafka обеспечивает высокую пропускную способность и масштабируемость.  

• RabbitMQ - популярный брокер сообщений с открытым исходным кодом.  

• Amazon SQS - полностью управляемая служба очереди сообщений, специфичная для AWS.  

• Kafka и RabbitMQ обеспечивают гибкость и отказоустойчивость.  

• Запуск в нескольких зонах доступности предотвращает потерю данных.  

• Важно иметь несколько очередей сообщений для всех микросервисов.  

• Kafka - это распределенная потоковая платформа для микросервисов.  

• Она позволяет производителям отправлять события, а потребителям получать их.  

• Kafka работает через темы, которые могут быть реплицированы и разделены на разделы.  

• Сообщения в Kafka остаются доступными для чтения, в отличие от RabbitMQ.  

• Kafka позволяет создавать приложения, управляемые событиями в реальном времени.  

• Kafka отказоустойчива и масштабируема, что делает её идеальной для больших систем.  

• Kafka Connect используется для интеграции данных из существующих источников.  

• Kafka Streams позволяет обрабатывать и преобразовывать данные в Kafka.  

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

• Темы в Kafka реплицируются и разделяются на разделы.  

• Разделы позволяют распределять данные по нескольким узлам для повышения доступности.  

• Темы могут быть как большими, так и маленькими, и не имеют ограничений по размеру.  

• Настройка брокера, темы, производителя и потребителя.  

• Использование Docker для упаковки и запуска контейнеров.  

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

• Docker - платформа для создания, запуска и доставки приложений.  

• Контейнеры в Docker работают одинаково в любой среде.  

• Docker часто используется в рабочих процессах CI/CD и DevOps.  

• Docker позволяет создавать образы и запускать контейнеры.  

• Образ Docker можно рассматривать как шаблон для запуска приложения.  

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

• Контейнер содержит операционную систему, инструменты и программное обеспечение.  

• Пример: приложение Spring Boot, JavaScript, Node.js, Golang, Python.  

• Контейнер позволяет запускать приложения, взаимодействуя с пользователем.  

• Kubernetes создан Google для управления контейнерами.  

• Kubernetes имеет открытый исходный код и написан на Golang.  

• Kubernetes управляет контейнерами, масштабируется и выполняет развертывания с нулевым временем простоя.  

• Кластер состоит из узлов, которые могут быть виртуальными машинами или работать в облаке.  

• Главный узел принимает решения, рабочие узлы выполняют задачи.  

• Взаимодействие между узлами осуществляется через kubelet.  

• Модуль - это наименьшая развертываемая единица в Kubernetes.  

• Модуль содержит основной контейнер и может включать init-контейнеры и побочные контейнеры.  

• Контейнеры взаимодействуют через localhost и порты, модуль имеет уникальный IP-адрес.  

• Модули эфемерны и одноразовы, поэтому их не следует создавать самостоятельно.  

• Kubernetes использует контроллеры для управления состоянием кластера.  

• Модули создаются с помощью контроллеров, таких как deployment и replication.  

• Создаем новую папку "services" в папке minikube.  

• В папке "services" создаем папку "customer".  

• Для каждого микросервиса создаем отдельную папку с YAML-файлами.  

• Создаем новый файл с именем "service.yaml".  

• Указываем имя сервиса "customer" и порт 80.  

• Тип сервиса устанавливаем как "балансировщик нагрузки".  

• Создаем новый файл "deployment.yaml".  

• Указываем имя развертывания "client".  

• Устанавливаем количество реплик на одну.  

• Указываем изображение как "code-amigos/client:latest".  

• Определяем порты: контейнерный порт 8080.  

• Указываем окружающую среду как "cube".  

• Настраиваем ресурсы, ограничения и запросы.  

• Устанавливаем датчики жизнеспособности и готовности.  

• Объясняем, почему оставляем одну реплику для тестирования.  

• Призываем записаться на полный курс.  

• Упоминаем о сообществе Amigos Code.  

• Прощаемся и желаем успехов в следующем уроке.