Добрый день!
Меня зовут Сергей Игнатенко, , я — девлид в поезде «Операционная платформа» Страхового Дома ВСК. Хочу сегодня рассказать об опыте использования SchemaRegistry и Avro в Kafka.
Начну с базовой схемы работы с Kafka, которая, возможно, будет знакома многим, но важна для понимания контекста.
Microservice Architecture Design in a NodeJS/NestJS Environment | Online Retail System
Сценарий: Перед вами стоит задача разработать микросервисную архитектуру для системы онлайн-ритейла. Эта система должна управлять различными сервисами, такими как каталог товаров, учетные записи пользователей, заказы и обработка платежей.
В начале немного о себе, мое основное занятие — обеспечение качества на вверенных проектах, я Senior QA в компании Umbrella IT. Периодически при тестировании микросервисов приходится сталкиваться с необходимостью изменения времени для проверки работы того или иного функционала. Это может быть функционал, который срабатывает по «тику» cron, или связанный с применением системного времени как одного из условий обработки/хранения/передачи данных тестируемым микросервисом.
Периодически общаемся с разработчиками о микросервисах, монолитах и прочих мифических существах. Порой такая эзотерика живёт в головах у людей и слышишь порой такое, что ёжики в тумане нервно курят в сторонке.
Дорогие коллеги-разработчики, нам нужно поговорить. Поговорить о микросервисах и ряде нежелательных ситуаций. Да, будет непросто, но это необходимо. Иначе нам не справиться.
Сегодня микросервисы очень популярны. Это прекрасный архитектурный стиль, который помогает масштабировать систему и саму организацию. Их используют многие успешные компании (Netflix, Spotify и прочие). Поэтому вполне нормально, что большинство организаций уже применяют или планируют начать применять этот стиль. Однако не все учитывают сопутствующие затраты.Читать полностью »
Термин объектно-ориентированное программирование придумал Алан Кэй. Кэй был членом команды PARC, которая изобрела графический интерфейс пользователя, сделавший таким полезным современный Интернет, персональные компьютеры, планшеты и смартфоны. Ещё она изобрела некоторые из объектно-ориентированных языков, на которых мы сегодня реализуем эти GUI.
Если отсечь все эмоции, связанные с ООП, то что останется? По-прежнему ли ООП является эффективным инструментом разработки ПО, или оно превратилось в устаревшее увлечение? Профессионалам важно знать ответ на этот вопрос!
Читать полностью »
Это перевод-адаптация https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices с вкраплениями моих собственных мыслей. Я не профессиональный переводчик, просто во многом согласен с изложенным.
В октябре 1984 года два идеолога опубликовали радикальный манифест… ну, или что-то вроде того.
Легенды computer science Брайан Керниган и Роб Пайк сформулировали в Program Design in the UNIX Environment паттерн архитектуры ПО, за сохранение которого оба боролись долгие годы.
Как и следовало ожидать от манифеста, в нём два этих канадских инженера максимально решительны. Самый резкий удар в статье — это запомнившаяся многим строчка из аннотации:
Старые программы покрываются коркой сомнительных фич.
Суть статьи часто сводят к аббревиатуре DOTADIW, или «Do One Thing And Do It Well» («Делайте что-то одно и делайте это хорошо»). В Unix и его потомках есть множество программ, в которых воплощена эта мантра: ls просто создаёт список файлов, cat просто выводит содержимое файлов, grep просто фильтрует данные, wc просто подсчитывает слова и так далее. У каждой программы есть несколько опций, меняющих её поведение, но не слишком сильно. Например: wc можно сконфигурировать для подсчёта строк или слов, но не для подсчёта количества абзацев или вхождений какой-то фразы.
Мощь Unix, защищаемая Керниганом и Пайком, заключалась в возможности соединения этих простых программ в цепочку для создания сложных поведений. Зачем добавлять сопоставление регулярных выражений в wc, если с этим уже способна справиться grep?Читать полностью »
На конференциях эта тема (монолит vs микросервисы) обсуждается с завидной регулярностью, но обычно в техническом ключе. Кто-то любит консистентность монолита, кто-то гибкость микросервисов, какие-то инструменты удобнее, какие-то нет.
Очень мало обсуждается вопрос команд и их взаимодействия, а ведь это самое главное при выборе. Я написал небольшую заметку в одном телеграм-канале, и в результате последующих обсуждений незаметно выросла целая статья на Хабр.
Поехали.
Итак, главное — это организационная структура компании и процессы взаимодействия команд. Да-да, как всегда, не технологии, а люди. Сейчас я работаю в Каруне, до этого работал в компаниях поменьше, видел, как набивались шишки, поэтому могу сравнить.
Когда команда одна, не очень большая (two pizza team), то никто никому не мешает. Код ревью, рефакторинг, деплой проходят быстро и весело. Бизнес сфокусирован на цели и работает как единое целое. Целью, кстати, зачастую является проверка гипотезы, нужен ли вообще этот проект кому-то или нет.
Автор статьи: Артем Михайлов
Микросервисная архитектура является одним из наиболее популярных подходов к созданию сложных приложений в настоящее время. Этот подход разбивает большое приложение на ряд маленьких, автономных сервисов, которые работают вместе для достижения общей цели.
Однако при работе с микросервисами возникают некоторые сложности в управлении нагрузкой на приложение. Именно здесь на помощь приходят два важных компонента — Load Balancer и Reverse Proxy.Читать полностью »
