Мягкое введение в микросервисы

«Вкратце, микросервисы позволяют нам разбить нашу большую систему на ряд независимых взаимодействующих компонентов. »

Spring Cloud - который построен на основе Spring Boot, предоставляет набор функций для быстрого создания микросервисов. Очень разумно знать, как заставить их работать вместе, можно быстро настроить службы с минимальными настройками.

Такие вещи, как регистрация и обнаружение сервисов, автоматические выключатели, прокси, ведение журналов и отслеживание журналов, мониторинг, аутентификация и т. Д.

Мы рассмотрим код того, как интегрировать общие функции Spring Cloud, и объясним каждую из них. В восторге?! Итак, приступим.

В этом руководстве также предполагается, что вы уже знакомы с основами Spring Boot.

В этой серии уроков мы рассмотрим:

Последняя часть «ELK (Elasticsearch, Logstash, Kibana)» здесь не рассматривается. Я добавил ссылку на еще одно простое пошаговое руководство. Стоит добавить его в рамках этой серии руководств.

ОБНОВИТЬ:

🙌🥂🎉🎉🍺 Репозиторий GitHub для демонстрационного приложения: https://github.com/OmarElGabry/microservices-spring-boot

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

Микросервисы

Что ж, существует множество определений, и, вероятно, вы отвлечетесь. Следующее определение объединяет наиболее общие концепции микросервисов.

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

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

Разложение

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

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

class UserApp {
  User getUser() {
     // 1. auth user
     // 2. get user data
     // 3. log user actions
   }
}
class UserApp {
  void authUser(User user) { ... }
  User getUserData() { ... }
  void logUserActions() { ... }
}

Однофункциональный

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

Четкие интерфейсы

Сервисы должны предоставлять интерфейс, который определяет, как мы можем с ними общаться. Это в основном определяет список методов, а также их входы и выходы.

Независимый

Независимость означает, что службы не знают о реализации друг друга. Их можно тестировать, развертывать и обслуживать независимо.

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

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

class UserApp {
  void authUser(User user) {
    // log user login action (success or failure) 
    // using logUserActions
  }
  User getUserData() { ... }
  void logUserActions() { ... }
}

Маленькие команды

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

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

Весь жизненный цикл

Команда отвечает за весь жизненный цикл сервиса; от кодирования, тестирования, постановки, развертывания, отладки, сопровождения.

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

Минимизация общения

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

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

Объем и риск изменений

Сервисы следует менять, не нарушая работу других сервисов. И пока мы не меняем внешний интерфейс, для других сервисов проблем не будет.

В результате изменений версии сервисов обновляются индивидуально, и между ними нет никакой связи.

Интересуетесь характеристиками микросервисов? Вот выступление Мартина Фаулера и текстовая версия видео. Он объясняет, какие наиболее общие характеристики должны быть.

Монолитные против микросервисов

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

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

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

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

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

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

Для этого нам нужна квалифицированная команда DevOps, которая справится со сложностями, связанными с развертыванием и автоматизацией мониторинга.

Ok. Итак, мы закончили введение в микросервисы. Далее мы приступим к реализации наших микросервисов.

Спасибо за чтение! Если вам понравилось, пожалуйста, похлопайте 👏 в ладоши.