Если мы возьмем приложение и отделим некоторые из его компонентов, мы увидим классы, методы, интерфейсы, каждый из которых имеет свою функцию, которые вместе позволяют нашему приложению делать все, что нам нужно, например, приложение для размещения заказов в небольшой пиццерии (нет, они не хотят быть в Uber Eats) их разработка не должна иметь высокую степень сложности, потому что в основном этот магазин не рассматривает возможность иметь так много заказов в короткие периоды времени.
Но что если эта же пиццерия получит отличного руководителя отдела маркетинга, который сумеет привлечь много клиентов и сгенерировать больше заказов, чем они могут получить, это вызовет большой поток информации, запросов, запросов к базе данных, ввода/удаления информации о пользователе, что происходит ежедневно в розничной торговле или банковских компаниях (это еще хуже в CyberDay), наше приложение перестанет работать, как ожидалось, и, конечно, не будет обладать необходимой масштабируемостью, Поэтому, если мы не хотим, чтобы наше монолитное приложение рухнуло, одним из способов решения этих проблем является определение архитектуры, которая, кстати, не является чем-то, что можно изменить с одного дня на другой, и выбор типа архитектуры приложения будет зависеть от многих факторов, я знаю, возможно, это не лучший пример маленькой пиццерии, поскольку им никогда не придется принимать такое решение, но я верю, что вы сможете уловить идею. Итак, нет абсолютного ответа на вопрос, какую архитектуру использовать при разработке, как и все в жизни… это зависит (как философски). Итак, для надежных и сложных приложений обычно используется архитектура микросервисов с огромным флагом с цитатой: “Разделяй, чтобы преуспеть”.
Микросервисы – это способ разработки приложений более быстрым, масштабируемым способом и с более короткими циклами оснащения и разработки, основанный на разработке сервисов, которые работают независимо друг от друга, взаимодействуя через REST API. Монолитное приложение – это, по сути, приложение, которое содержит всю программу, в то время как микросервисы стремятся разделить все функциональные возможности в одном приложении, так что каждый микросервис выполняет определенную функцию. Например, если микросервис A нуждается в другом микросервисе B, первый A – для регистрации пользователя или входа в систему, а второй B – для доступа к базе данных, то это независимые микросервисы с разными задачами, но в то же время для работы им необходимо взаимодействие.
Для того чтобы вся экосистема микросервисов могла взаимодействовать друг с другом, они должны зарегистрироваться, и это делается автоматически на сервере Eureka (или Discovery server). На этом сервере, который в свою очередь является микросервисом, регистрируется имя микросервиса, его порт, местоположение и вся необходимая информация, и когда одному микросервису требуется взаимодействие с другим, он сначала обратится к серверу Eureka, который предоставит имя и адрес этого сервиса, чтобы его можно было использовать. Представьте себе это как вечеринку, когда на вечеринку (экосистема микросервисов) прибывал гость (микросервис), об этом объявлял хозяин (Eureka), и все остальные гости знали, что прибыл новый, и имели информацию о том, кто это. Да, это звучит немного или довольно занудно, но таким образом вы никогда больше не забудете об этом.
Архитектура микросервисов имеет ряд зависимостей/библиотек, которые позволяют ее оптимально развивать и улучшать различные функциональные возможности, одной из них являются библиотеки Ribbon/LoadBalancer, которые отвечают за балансировку нагрузки, первая только старше второй упомянутой. Когда мне нужно масштабировать приложение и построить несколько экземпляров микросервиса, эта библиотека балансировки нагрузки дает мне наиболее оптимальный экземпляр для использования. У нас также есть Hystrix/Resillience4j – обе библиотеки, связанные с обработкой ошибок, например, если микросервис выполняет операцию, которая взаимодействует с тремя другими микросервисами, я могу использовать эти библиотеки для обработки ошибок в случае падения одного из них, чтобы избежать каскадного эффекта, влияющего на все приложение.
Feign – это библиотека, альтернативная использованию RestTemplate, поскольку обе они используются для обеспечения связи между микросервисами и основаны на использовании нотаций.
Библиотека Zuul (также разработанная Netflix), является реализацией так называемого API Gateway (хотя Spring Cloud GateWay, является наиболее используемым API в настоящее время), и стремится централизовать всю информацию и записи микросервисов, в одной точке доступа (порт), позволяя доступ ко всем микросервисам, зарегистрированным через конечную точку, которая формируется общим путем, и специфическим путем микросервиса. Таким образом, доступ к микросервисам осуществляется из одной точки.
Как я уже говорил, у нас есть возможность обрабатывать ошибки в случае их возникновения и быть готовыми к тому, чтобы наше приложение могло продолжать работать, если что-то не получится (и вот мой лучший совет, к тому же бесплатный: моя жизненная цитата: “Надейтесь на лучшее, готовьтесь к худшему”).
CircuitBreaker – это паттерн, реализуемый такими библиотеками, как Resilience4j или Hystrix, который имеет 3 состояния: открытое, закрытое и полуоткрытое. Когда приложение работает нормально, эта цепь закрыта (деактивирована), когда происходит ошибка или какой-то микросервис экосистемы выходит из строя, цепь переходит в открытое состояние, другими словами, она “активируется”, и микросервис с отказом изолируется от остальных микросервисов. Наконец, полуоткрытое состояние является “тестовым” состоянием, и микросервис оценивается через порог ошибки, может ли он быть включен обратно в другие микросервисы. Если микросервис превышает порог ошибок, он возвращается в открытое состояние, в противном случае он переходит в закрытое состояние и может быть включен в остальную экосистему микросервисов.
Другим важным компонентом является сервер конфигурации, именно в этом микросервисе содержится вся информация и файлы конфигурации каждого микросервиса, этот сервер конфигурации – первое, что необходимо загрузить, еще до Eureka (сервера обнаружения). И информация с этого сервера может храниться как локально, так и удаленно в Git-репозитории. Другими словами, сначала вам нужно получить информацию о каждом микросервисе из этого репозитория, и только потом вы просто разрешите регистрацию микросервисов на сервере Eureka. Этот сервер конфигурации также настраивает среду или окружение, если у вас их несколько, например, production, development.
Имея так много микросервисов, которые выполняют множество функций и находятся в постоянной работе, как узнать, если микросервис не хочет работать в понедельник, или заболел и плохо себя чувствует, или просто не хочет запускаться. Как мы можем увидеть “здоровье” нашей экосистемы микросервисов? Ведь в конце концов они как маленькие работники. Ну, для этого у нас есть инструменты отслеживания, которые позволяют нам увидеть, как работают микросервисы.
Sleuth – это, по сути, зависимость отслеживания, а Zipkin – сервер мониторинга с графическим интерфейсом, позволяющим следить за состоянием экосистемы микросервисов.
Sleuth позволяет предоставлять уникальные идентификаторы для потоков запросов. Разработчик использует этот ID, чтобы найти или идентифицировать поток полного запроса.
Существует 2 типа идентификаторов, Trace и Span. Trace – это идентификатор для полного потока (от запроса до ответа), поэтому разработчик может найти журналы всех микросервисов, участвующих в потоке. Span ID – это уникальный идентификатор только для одного микросервиса в потоке, он служит для идентификации журналов конкретного микросервиса.
Это создает своего рода запись, которая затем передается на сервер мониторинга Zipkin через брокеры обмена сообщениями, такие как rabbitMQ, чтобы Zipkin мог отобразить эту информацию на своем интерфейсе.
Оригинал: “https://dev.to/javier190/microservices-a-brief-introduction-2ghj”