Привет, Хабр!
Микросервисная архитектура предлагает нам гибкость, масштабируемость и управление сложными приложениями на новом уровне. Однако, чтобы извлечь максимальную выгоду из этой архитектуры, важно правильно спроектировать микросервисы и обеспечить эффективное взаимодействие между ними.
gRPC – высокопроизводительный и мощный инструмент для построения микросервисных систем.
Привет, Хабр!
Мы сталкиваемся с огромными объемами информации, высокой нагрузкой, и постоянно меняющимися требованиями. Все это требует от нас не только навыков программирования, но и грамотного проектирования архитектуры, которая способна справиться с этими вызовами.
Именно здесь на сцену выходит архитектурный паттерн, о котором мы сегодня поговорим - Lambda-архитектуре. Если вы уже имеете опыт в области обработки больших данных, то, возможно, слышали о ней. Lambda-архитектура - это эффективный способ структурирования и организации процессов сбора, обработки и анализа данных, обеспечивая надежность, масштабируемость и гарантированную консистентность.
Быстрая загрузка, реакция на действия пользователя без замедлений и низкая задержка — все это играет критическую роль в обеспечении высокого уровня пользовательского опыта. Чем быстрее приложение, тем довольнее пользователь, и тем больше вероятность, что он вернется к нему снова.
Для достижения такой производительности можно использовать два ключевых инструмента: кэширование и Content Delivery Network. Эти методы не только снижают нагрузку на сервер, но и ускоряют загрузку ресурсов, уменьшая время отклика приложения.
История о том, как время ответа сервиса выросло в несколько раз в течение месяца, в чем была причина, и какое в итоге нашли решение.
Написать этот пост меня побудила статья "В чем конечная цель программирования?" и её обсуждение в комментах. Я поставил свой плюс за статью сразу же, как прочитал первое предложение:
> В том, чтобы иметь код, который легко изменять.
Ведь это же очевидно любому, кто попрограммировал достаточно долго, чтобы столкнуться с необходимостью изменять свой собственный код через какое-то достаточно продолжительное время (более полугода от момента завершения проекта). Про чужой код я не говорю, потому что его, в массе своей, изначально пишут "криворукие ваш-любимый-эпитет" и нужно потратить кучу времени хотя бы для того, чтобы понять, что он делает, а чтобы что-то в нём изменить и не порушить всё остальное, времени нужно потратить в разы больше.
Но статья с таким очевидным (ну, лично для меня) выводом имеет, по состоянию на сегодня, оценку "-5" ("8" - в плюс, "13" - в минус). Под катом мои размышления о возможных причинах этого.
Привет, Хабр!
Каждая миллисекунда имеет значение, кэширование стало безусловно важной частью проектирования высокопроизводительных приложений. Оптимизация скорости и доступности данных стала приоритетом для разработчиков, и кэширование является одним из наиболее эффективных способов достижения этой цели. Redis и Memcached играют занимают важную роль в этом процессе.
Redis и Memcached – два из самых популярных и мощных инструментов для реализации кэширования. Redis, изначально разработанный как in-memory хранилище данных, позволяет эффективно хранить и быстро извлекать информацию в памяти, что делает его идеальным выбором для кэширования. Memcached, с другой стороны, специализируется исключительно на кэшировании данных и предоставляет простой, но мощный способ ускорить доступ к данным.
В чем конечная цель программирования? В том, чтобы иметь код, который легко изменять.
Давайте разберемся. Какую проблему мы пытаемся решить?
Мне кажется, что фундаментальная проблема программистов в том, что мы не понимаем, либо же имеем ложные представления о том, зачем мы вообще программируем.
Привет, Хабр!
Обработка данных в реальном времени стала важной составной частью современного мира. Бизнес, исследователи, разработчики и многие другие специалисты сталкиваются с необходимостью обрабатывать потоки данных в реальном времени, чтобы принимать решения быстрее и более точно.
В этой статье мы рассмотрим как построить пайплайн обработки данных в реальном времени с использованием Python.
Привет, Хабр! Если вас заинтересовал заголовок этой статьи, значит, вас интересует созданием телеграм-ботов, и вы стремитесь к совершенству в этом. Разработка телеграм-ботов требует не только креативности, но и правильной архитектуры. В этой статье мы рассмотрим 9 архитектурных антипаттернов, которые могут стать серьезными преградами на вашем пути к созданию бота.
Для многих начинающих разработчиков создание Телеграм бота может показаться достаточно простой задачей. Однако опытные знают, что успех в этой области зависит от многих факторов, включая архитектуру вашего приложения. Архитектурные решения могут определить, насколько ваш бот будет масштабируемым, надежным и легко поддерживаемым в будущем.
При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при маштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».
Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Потом архитектура системы и влияние требований на нее, БД, API, интеграции. И вот, в процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже?
Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я понимаю, что пришло время делать выбор: дорого переделывать или "костыли" подойдут.
Один раз столкнувшись с такой ситуацией, больше не хочется оставлять без внимания базу данных, даже если её проектированием должны были заниматься разработчики.
Привет, Хабр! Я участвую в разработке крупного Web приложения и мы с коллегами на этапе проработки и планирования архитектуры пришли к выводу о необходимости выносить всю логику приложения в отдельный поток Web Worker, т.к. предполагается большое число фоновых операций и вычислений. К чему это привело? Сложности? Пути их решения? Обо всем попорядку.
В книге Криса Ричардсона «Микросервисы: паттерны разработки и рефакторинга», описывается что-то около 20 паттернов, использующихся в микросервисной архитектуре. Все они делятся на 5 больших групп: decomposition patterns, integration patterns, database patterns, observability patterns и cross-cutting concern patterns. Я, узнав про паттерны, которые могут быть применимы в микросервисной архитектуре, немного изучила их и попробовала реализовать один из них. Всем привет, меня зовут Екатерина Попкова, я Java/Kotlin-разработчик в Альфа-Банке, и хочу рассказать, как можно обеспечить консистентность данных в микросервисной архитектуре с помощью применения паттерна «Сага».
Абстрактный тип данных.
Зачем нужны абстрактные типы данных? Чем они полезны для программиста? Когда необходимо создавать эти абстракции, а когда можно обойтись без них? Тип данных vs абстрактный тип данных vs структура данных.
Не буду вам рассказывать о всех прелестях использования статических анализаторов, на мой взгляд это очевидно. А я расскажу о том как можно расширить их функциональность под ваши нужды, на примере Psalm.
Поделюсь трудностями с которыми я столкнулся, что бы вы не наступали на те же грабли что и я.
А в конце интересный опрос про использование статических анализаторов.
Привет, Хабр! Представьте: вы – член большой команды среди десятка таких же команд на крупном и зрелом проекте. Казалось бы, все процессы уже выстроены, все масштабные разработки завершены и теперь остается только с наслаждением разрабатывать и дополнять проект новыми интересными фичами.
Гармония и красота.
Но откуда ни возьмись, появляется она – недоработанная масштабная функциональность, словно щупальцами оплетающая все базовые процессы сразу. Как монстр, затаившийся в пещере, она не давала покоя бизнесу вот уже 3 года, и успела «сожрать» несколько команд разработки. И вот бизнес снова объявил охоту на монстра… а вы оказались в этом отряде самоубийц героев, призванных положить конец бесчинствам чудовища.
Цели озвучены, задачи поставлены, команда в ужасе собрана. Но вот незадача, поле для сражений одно: либо ваша команда будет монстра рубить, либо остальные команды – семена сажать. И что же делать?
Как и множество больших сервисов, Яндекс Еда основана на микросервисной архитектуре. В общей сложности у нас чуть больше 200 микросервисов. Но есть один сервис, который совсем не микро – легаси-монолит.
Он написан на PHP 7.2 разработчиками разного уровня и в разное время. Мы подумали, что так больше нельзя, и решили навести порядок. В ходе разбирательств выяснилось, что версия языка, на котором всё написано, устарела и уже не поддерживается, что ведёт к рискам безопасности. Делать нечего — мы приняли решение обновиться до 8-й версии.
В этой статье я расскажу, чего стоило нам проапгрейдить монолит, сколько тестов мы сломали и как в этом проекте поучаствовали почти все PHP-разработчики Яндекс Еды. Это интересный и уникальный опыт, которым я хотел бы с вами поделиться. В конце дам несколько советов тем, кто тоже захочет ввязаться в подобную авантюру.
Любой автоматизатор тестов рано или поздно сталкивается с задачей либо дополнить, либо расширить тестовый фреймворк. К тому же, у многих есть профессиональная цель написать свой тестовый фреймворк. Чтобы реализовать это, необходимо знать и понимать архитектуру тестовых фреймворков, так как от заложенной архитектуры зависит стабильность, расширяемость и гибкость вашего фреймворка и тестов в целом.
Всем известная организация ISTQB разработала общую схему (архитектуру) компонентов, из которых должен состоять тестовый фреймворк. В этой статье разберем, что это за компоненты и для чего они нужны.
Хабр, привет! В прошлой статье про UML мы узнали что такое язык моделирования UML, зачем он нужен, основные плюсы и минусы UML, а также рассмотрели диаграмму классов. Сегодня я хочу продолжить тему проектирования процессов и остановиться на диаграмме компонентов.
