Настоящее легаси — это тонны кода, оперирующие коэффициентами, про которые никто не помнит, откуда они взялись. Куски кода и системы на устаревших языках, которых вы не понимаете. Система, построенная на логике, которую вы не понимаете.
Настоящее легаси — это тонны кода, оперирующие коэффициентами, про которые никто не помнит, откуда они взялись. Куски кода и системы на устаревших языках, которых вы не понимаете. Система, построенная на логике, которую вы не понимаете.
Как известно, качественное программное обеспечение должно обладать такими свойствами, как гибкость, масштабируемость, безопасность, многократность использования, возможность реализации. Но каким образом всего этого достичь на практике? Здесь поможет разработка архитектуры ПО, под которой понимается процесс превращения всех вышеописанных характеристик в структурированное решение, соответствующее и техническим, и бизнес-требованиям.
Мы уже рассказывали о преимуществах использования очередей сообщений в микросервисах. Однако несмотря на многочисленные плюсы, самостоятельное внедрение может оказаться сложной задачей. И вот почему:
На практике под модное ныне определение Highload могут подпадать абсолютно разные проекты с нагрузкой, которая будет различаться на порядки. По большему счету, даже похожие сервисы в рамках разных компаний могут быть в одном случае высоконагруженными, а в другом — нет. Вообще, вряд ли возможно заранее угадать, попадет ли тот либо иной проект в "зал славы highload", причем одного лишь желания разработчиков, инвесторов и заказчиков тут явно недостаточно. Однако это не значит, что готовиться к такому повороту событий не нужно -- нужно, но делать это надо с умом. К сожалению, в реальности иногда случаются перегибы.
Если вы используете в качестве основных средств для взаимодействия микросервисов очереди, вы можете добиться определенных преимуществ. О них -- наша статья.
Декоратор представляет собой структурный шаблон проектирования, который позволяет динамически подключать к объекту дополнительное поведение. По сути, это более гибкая альтернатива практике по созданию подклассов с целью расширения функциональности.
Фасад представляет собой структурный шаблон проектирования, который дает возможность скрыть сложность системы посредством сведения всевозможных внешних вызовов к одному объекту, делегирующему эти вызовы соответствующим объектам системы.
Большинство из нас сталкивалось с таким понятием, как HighLoad. Но это понятие, которое дословно переводится как «высокая нагрузка», является довольно относительным. Когда же мы можем с уверенностью сказать, что highload все-таки наступил?
Как известно, схемы синхронного и асинхронного взаимодействия на основе REST API имеют свои недостатки. Чтобы эти недостатки нивелировать, существуют очереди сообщений — Message Queues. Поговорим о принципах их работы.
При проектировании микросервисной архитектуры нередко возникает вопрос, какой именно способ связи между микросервисами лучше использовать. Конечно, всегда можно отдать предпочтение RESTful API, что и делают в большинстве случаев. Но на практике такой подход эффективен не всегда, ведь в отдельных ситуациях возможно долгое ожидание со стороны клиента и потеря информации при сбоях. Однако существует и другой вариант взаимодействия между микросервисами: очереди сообщений.