Не секрет, что сегодня интернет-сервисы подвергаются усиленной нагрузке. Случается, что торговые сети даже останавливают сайты с заказами по причине нехватки имеющихся мощностей. Но если запросы клиентов не обрабатывать или обрабатывать с перебоями, клиенты, разумеется, уйдут к конкурентам. Избежать этого помогут архитектурные практики, позволяющие создавать быстрые и отказоустойчивые сервисы. Рассмотрим некоторые из таких паттернов.
Этот порождающий шаблон проектирования задает виды создаваемых объектов посредством экземпляра-прототипа, то есть создание новых объектов происходит путем копирования этого прототипа. В результате появляется возможность уйти от реализации и следовать принципу «программирование через интерфейсы». В роли возвращающего типа указывают интерфейс/абстрактный класс на верху иерархии, причем классы-наследники могут подставить туда наследника, реализующего данный тип.
Когда данные образованы в структуру, можно их эффективно обрабатывать и успешно ими управлять. В этой статье будет рассмотрена такая структура данных, как массив. Данный способ структурирования хорошо известен в программировании и широко используется для решения различных практических задач.
Под динамической маршрутизацией запроса понимается ситуация, когда API Gateway (Zuul) получает возможность выбора среди нескольких инстансов одного и того же сервиса, необходимого именно нам. Как правило, данную задачу можно решить, если добавить некий предикат, позволяющий на этапе обработки запроса выбрать нужный сервис из общего списка сервисов с таким же именем.
Все мы прекрасно знаем 4 главных требования к транзакциям: атомарность, изолированность, согласованность и долговечность (ACID — Atomicity, Consistency, Isolation, Durability). Давайте поговорим о транзакциях в контексте высоконагруженных проектов.
В настоящей статье я предлагаю обсудить какие возникают ошибки при разбивке монолита на микросервисную архитектуру (МСА), почему они возникают, к чему приводят. Ну а в конце я опишу как должен быть организован эффективный и правильный процесс перевода на МСА и какой должна стать архитектура микросервисной системы.
Когда осуществляется переход с монолитной архитектуры на микросервисную, команды, не имеющие опыта, зачастую начинают дробить свои сервисы по верхнеуровневым объектам доменной модели (к примеру, User/Client/Employee и т. п.). И это ошибка номер один. При более детальной проработке возникает понимание, что разбивать удобнее и лучше на более крупные блоки, которые агрегируют внутри себя несколько объектов доменной области. Такое решение позволит вам избежать лишних вызовов в сторонние сервисы.
Cloud-native — это современный подход к созданию и выполнению приложений. Он использует преимущества облачной модели и подходит как для публичных, так и для частных облаков.
