Блог Архитектура и шаблоны проектирования

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

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

Все мы прекрасно знаем 4 главных требования к транзакциям: атомарность, изолированность, согласованность и долговечность (ACID — Atomicity, Consistency, Isolation, Durability). Давайте поговорим о транзакциях в контексте высоконагруженных проектов.

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

Строитель представляет собой порождающий шаблон проектирования, с помощью которого можно создать составной объект. Этот паттерн предназначается для решения проблемы антипаттерна «Телескопический конструктор».

Согласно Википедии, абстрактная фабрика является порождающим шаблоном проектирования, который предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов. Этот шаблон реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (к примеру, для оконного интерфейса он способен создавать окна и кнопки). Потом пишутся классы, реализующие этот интерфейс.

Когда осуществляется переход с монолитной архитектуры на микросервисную, команды, не имеющие опыта, зачастую начинают дробить свои сервисы по верхнеуровневым объектам доменной модели (к примеру, User/Client/Employee и т. п.). И это ошибка номер один. При более детальной проработке возникает понимание, что разбивать удобнее и лучше на более крупные блоки, которые агрегируют внутри себя несколько объектов доменной области. Такое решение позволит вам избежать лишних вызовов в сторонние сервисы.

Cloud-native — это современный подход к созданию и выполнению приложений. Он использует преимущества облачной модели и подходит как для публичных, так и для частных облаков.