На практике под модное ныне определение Highload могут подпадать абсолютно разные проекты с нагрузкой, которая будет различаться на порядки. По большему счету, даже похожие сервисы в рамках разных компаний могут быть в одном случае высоконагруженными, а в другом — нет. Вообще, вряд ли возможно заранее угадать, попадет ли тот либо иной проект в "зал славы highload", причем одного лишь желания разработчиков, инвесторов и заказчиков тут явно недостаточно. Однако это не значит, что готовиться к такому повороту событий не нужно -- нужно, но делать это надо с умом. К сожалению, в реальности иногда случаются перегибы.

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

Большинство из нас сталкивалось с таким понятием, как HighLoad. Но это понятие, которое дословно переводится как «высокая нагрузка», является довольно относительным. Когда же мы можем с уверенностью сказать, что highload все-таки наступил?

Как известно, схемы синхронного и асинхронного взаимодействия на основе REST API имеют свои недостатки. Чтобы эти недостатки нивелировать, существуют очереди сообщений — Message Queues. Поговорим о принципах их работы.

При проектировании микросервисной архитектуры нередко возникает вопрос, какой именно способ связи между микросервисами лучше использовать. Конечно, всегда можно отдать предпочтение RESTful API, что и делают в большинстве случаев. Но на практике такой подход эффективен не всегда, ведь в отдельных ситуациях возможно долгое ожидание со стороны клиента и потеря информации при сбоях. Однако существует и другой вариант взаимодействия между микросервисами: очереди сообщений.

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

Чтобы управлять потоком запросов в микросервисной архитектуре, применяют очереди сообщений MQ (message queues). Но какую MQ лучше выбрать, если речь идет о высоконагруженном проекте?

В предыдущих заметках мы рассказывали про горизонтальное масштабирование, CQRS и архитектурный паттерн Event Sourcing. Но, как известно, в системах с Event Sourcing нет строгой согласованности. А это значит, что нам можно задействовать сразу несколько хранилищ, причем без синхронизации между этими хранилищами.

Highload – это не болезнь, а условия, при которых приходится функционировать той либо иной системе. И насколько эта система будет справляться со своей нагрузкой, зависит работа многих видов бизнеса.

Как известно, быструю распределенную систему синхронизовать нельзя, так как мы уменьшаем производительность. С другой стороны, иногда нам все же необходимо обеспечить определенную согласованность компонентов. Как раз для этого и существует подход eventual consistency, при котором гарантируется, что в случае отсутствия изменений данных через какой-либо промежуток времени после последнего обновления все запросы станут возвращать последнее обновленное значение.