Как стать автором
Обновить
42.62

Микросервисы *

Микросервисная архитектура и все что с ней связано

Сначала показывать
Период
Уровень сложности

До микросервисов нужно дорасти, а не начинать с них

Время на прочтение6 мин
Количество просмотров52K


Предлагаю поговорить о том, когда нужны микросервисы, а когда нет. Спойлер: это зависит от проекта.

У нас, разработчиков программного обеспечения, довольно интересная профессия. Мы можем спокойно кодировать целыми днями, а затем прочитать статью о чём-то — и она подвергает сомнению всю нашу работу, потому что какой-нибудь Netflix сказал XYZ.

Просто так, из-за мнения одного человека или компании вы начинаете сомневаться во всём, что делали в течение многих лет, даже если всё работало отлично.
Читать дальше →

Почему JWT — не панацея: разбор проблем сессий и безопасности

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров25K

JWT для сессий: удобство или головная боль?

JSON Web Token (JWT) приобрёл популярность как удобный способ аутентификации и передачи данных между клиентом и сервером. Его ценят за простоту, stateless-подход и гибкость. Однако большинство гайдов рассказывают только о плюсах, забывая о недостатках.

В этой статье мы разберём основные проблемы использования JWT для хранения пользовательских сессий и обсудим более надёжные альтернативы.

Читать далее

Верните мне мой монолит

Время на прочтение3 мин
Количество просмотров41K
Кажется, пик хайпа по микросервисам остался позади. Мы уже не читаем по нескольку раз в неделю посты «Как я перенес свой монолит на 150 сервисов». Теперь я чаще слышу разумные мысли: «Я не ненавижу монолит, я просто забочусь об эффективности». Мы даже наблюдали несколько миграций от микросервисов обратно к монолиту. При переходе от одного большого приложения к нескольким службам меньшего размера вам придётся решать несколько новых проблем. Перечислим их максимально кратко.
Читать дальше →

REDIS: такой простой и такой сложный

Уровень сложностиСредний
Время на прочтение10 мин
Количество просмотров33K

Меня зовут Андрей Комягин, я СТО компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей и в своей работе широко используем open-source решения, в том числе СУБД Redis. Недавно я подробно рассказывал об этой системе на конференции Saint HighLoad++, а теперь с удовольствием поделюсь основной информацией с читателями Хабра. Итак, поехали.

Читать далее

SOLID. Проблема новичка

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров21K

Здравствуйте, друзья! Меня зовут Константин, я python backend developer из компании «Окенит». Сегодня я хочу рассказать свое видение проблемы новичка при ознакомлении с принципами SOLID, описанными в книге «Стерильная Архитектура» Робина Мартерта.

За свой десятилетний опыт я часто был свидетелем ситуации, когда молодые разработчики, желая сделать свой проект как можно более открытым для расширения и редактирования, превращали его в груду нечитаемого и неподдерживаемого кода при попытке использовать у себя все рекомендации Матушки Роба. Отсюда вопрос: «Почему, при следовании советам более опытного разработчика, код стал только хуже?».

Ответ на этот вопрос пришел ко мне очень быстро. Из‑за описания и без того абстрактных вещей чересчур абстрактными словами и примерами, Робин Мартерта вместо упорядочивания знаний, наводит хаос в умы читателей. Во избежание этой ситуации я решил написать данную статью, где коротко расскажу о наборе принципов SOLID, для чего они нужны и, главное, как применять эти принципы в жизни. Начнем по порядку, с буквы «S». И так, что же она значит?

Читать далее

Как мы ускорили Golang-тесты на CI

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров6K

Привет, Хабр ?! Меня зовут Александр, я занимаюсь разработкой ПО. В этом посте я расскажу про свой опыт, как желание улучшить свой рабочий процесс CI, помогло ускорить все golang пайплайны в PaaS в СберМаркета.

Читать далее

Лучшие практики для надёжной работы с RabbitMQ

Уровень сложностиПростой
Время на прочтение13 мин
Количество просмотров37K

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.

В первую очередь материал рассчитан на разработчиков, которым ещё не приходилось погружаться в тонкости работы с RabbitMQ или использовать его вообще. Более опытным читателям статья может пригодиться в качестве компактной и упорядоченной выжимки из уже знакомых статей, вебинаров и многочисленных страниц документации.

Следуй за белым кроликом

userver 2.0 — большой релиз фреймворка для IO-bound программ

Время на прочтение6 мин
Количество просмотров9.7K
С момента прошлого релиза фреймворка 🐙 userver для С++ прошло чуть больше полугода. За это время мы многое сделали:


  • сильно оптимизировали работу фреймворка и обогнали основных конкурентов в бенчмарках высокопроизводительных фреймворков;
  • значительно упростили конфигурирование;
  • обзавелись install, докер-образами, Yandex Cloud-образом и DEB-пакетами;
  • обросли новой функциональностью, включая серверные мидлвари для HTTP, и YDB-драйвером;
  • перешли на новую ежемесячную схему релизов и упростили версионирование.

Добро пожаловать под кат за подробностями

Керниган и Пайк были правы: делай что-то одно и делай это хорошо

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров28K
Роб Пайк и Брайан Керниган

В октябре 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?
Читать дальше →

Всегда ли нужны Docker, микросервисы и реактивное программирование?

Время на прочтение15 мин
Количество просмотров51K


Автор: Денис Цыплаков, Solution Architect, DataArt

В DataArt я работаю по двум направлениям. В первом помогаю людям чинить системы, сломанные тем или иным образом и по самым разным причинам. Во втором помогаю проектировать новые системы так, чтобы они в будущем сломаны не были или, если говорить реалистичнее, чтобы сломать их было сложнее.

Если вы не делаете что-то принципиально новое, например, первый в мире интернет-поисковик или искусственный интеллект для управления запуском ядерных ракет, создать дизайн хорошей системы довольно просто. Достаточно учесть все требования, посмотреть на дизайн похожих систем и сделать примерно так же, не совершив при этом грубых ошибок. Звучит как чрезмерное упрощение вопроса, но давайте вспомним, что на дворе 2019 год, и «типовые рецепты» дизайна систем есть практически для всего. Бизнес может подкидывать сложные технические задачи — скажем, обработать миллион разнородных PDF-файлов и вынуть из них таблицы с данными о расходах — но вот архитектура систем редко отличается большой оригинальностью. Главное тут — не ошибиться с определением того, какую именно систему мы строим, и не промахнуться с выбором технологий.

В последнем пункте регулярно возникают типичные ошибки, о некоторых из них я расскажу в статье.
Читать дальше →

Как мы делали свой поиск в Ozon: эволюция архитектуры от SQL до O2

Время на прочтение16 мин
Количество просмотров31K

Привет, Хабр! Меня зовут Сергей, я руководитель команды поиска в Ozon. Сегодня я расскажу об эволюции наших поисковых систем: как всё начиналось более 20 лет назад с обычных SQL-запросов, как мы осваивали Sphinx и Elasticsearch и как сейчас наш собственный поисковый движок O2 на базе Apache Lucene выдерживает нагрузку в десятки тысяч RPS в сезон распродаж. Исторические хроники восстанавливались по воспоминаниям современников и представлены для полноты картины. Новейшая история описана на основе собственного опыта, поэтому подробностей будет на порядок больше. Поехали!

Читать далее

Технология Serverless: снова привет, 1970-е

Время на прочтение7 мин
Количество просмотров12K


Я проработал с «Облаком» уже достаточно долго для того, чтобы убедиться, что ему предстоит пройти ещё долгий путь, прежде чем оно станет лучше старой доброй аренды пары серверов и запуска своего ПО на них. Сейчас в моде Serverless-решения, из-за которых у меня ощущение, что мы снова вернулись в 1970 год.

Когда-то давным-давно я притворялся, что учусь менеджменту, а на самом деле изучал кодинг на C. Наш университет находился в двух мирах: в нём существовала лаборатория с «персональными компьютерами», но в то же время имелись терминалы мини-компьютера, и в зависимости от предпочтений профессоров задания нужно было выполнять в одном из этих миров. Но обе эти системы были, по крайней мере, интерактивными и обеспечивали мгновенную обратную связь. Моему другу повезло не так сильно: на одном из курсов по технологии строительства ему дали задание, которое нужно было выполнить на Pascal и сдать в виде распечатки с университетского мейнфрейма.
Читать дальше →

Tornado vs Aiohttp: путешествие в дебри асинхронных фреймворков

Время на прочтение12 мин
Количество просмотров25K
Привет! Я Дима, и я довольно давно и плотно сижу на Python. Сегодня хочу показать вам отличия двух асинхронных фреймворков — Tornado и Aiohttp. Расскажу историю выбора между фреймворками в нашем проекте, чем отличаются корутины в Tornado и в AsyncIO, покажу бенчмарки и дам немного полезных советов, как забраться в дебри фреймворков и успешно оттуда выбраться.


Читать дальше →

Ближайшие события

Не бойся микросервиса: Алексей Баитов об использовании микросервисной архитектуры на практике

Время на прочтение16 мин
Количество просмотров18K
Для одних микросервисы — это возможность переделать и отрефакторить приложение под условно современный стиль. Другим это архитектурное решение не подходит из-за особенности взаимодействия различных частей приложения. В любом случае, выбирая архитектуру, полезно изучить чужой опыт перехода от монолита к набору сервисов.

Мы попросили поделиться своим кейсом разработки и доставки микросервисов Алексея Баитова, ведущего инженера 2ГИС. Поговорим на тему архитектурных решений, деплоя и возможности масштабирования. Расспросим про трендовые и просто удобные инструменты для работы.


Читать дальше →

Возможно, микросервисы вам не нужны

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров21K

Писать эту статью было весело. Многие наверняка её захейтят, но …

Дорогие коллеги-разработчики, нам нужно поговорить. Поговорить о микросервисах и ряде нежелательных ситуаций. Да, будет непросто, но это необходимо. Иначе нам не справиться.

Сегодня микросервисы очень популярны. Это прекрасный архитектурный стиль, который помогает масштабировать систему и саму организацию. Их используют многие успешные компании (Netflix, Spotify и прочие). Поэтому вполне нормально, что большинство организаций уже применяют или планируют начать применять этот стиль. Однако не все учитывают сопутствующие затраты.
Читать дальше →

Доводим распределённые действия до конца с использованием простейшего паттерна Saga

Время на прочтение11 мин
Количество просмотров24K

Привет! Меня зовут Иван, я занимаюсь бэкенд-разработкой в Ozon: пишу микросервисы на Go для личного кабинета продавца. В прошлом году мы запустили новый процесс регистрации продавцов, в котором задействовано сразу несколько микросервисов. В нём стало больше шагов, при этом каждый из них выполняется в разных микросервисах. Поэтому мы задались вопросом: «А что будет, если один из шагов упадёт?».


В микросервисной архитектуре давно известен инструмент решения подобных проблем — это паттерн Saga. Мы решили взять его на вооружение и немного упростить под нашу задачу. Я расскажу о том, как мы это сделали, и покажу, что Saga может быть простой. Так что если вы давно хотели попробовать реализовать Saga, но вам казалось, что это сложно — читайте дальше.


image

Читать дальше →

Kafka и микросервисы: обзор

Время на прочтение9 мин
Количество просмотров124K


Всем привет. В этой статье я расскажу, почему мы в Авито девять месяцев назад выбрали Kafka, и что она из себя представляет. Поделюсь одним из кейсов использования — брокер сообщений. И напоследок поговорим о том, какие плюсы мы получили от применения подхода Kafka as a Service.

Читать дальше →

Полезные фичи С++ на примере организации пайплайна

Время на прочтение20 мин
Количество просмотров15K

В рамках микросервисной архитектуры достаточно легко делать «реактивные» сервисы: к вам приходит событие или вызов HTTP-метода, и в ответ на это происходит какое-то действие. Однако бывают более сложные сценарии, когда надо собрать некоторое количество информации или событий прежде, чем что-то делать. В таком случае нужен пайплайн — механизм организации сложных правил обработки событий. 

Недавно нам пришлось организовать пайплайн с использованием интересных С++-трюков. О них я и расскажу в статье. 

— Как хранить в одном контейнере разные типы и использовать тип в качестве ключа контейнера 

— Как средствами метапрограммирования удобно сериализовать и десериализовать разнотипные объекты 

— Как сделать универсальный запускатель функций, который будет запускать любую функцию и сам искать, откуда «добыть» эти аргументы 

— И главное, как сделать интерфейс для написания пайплайна обработки события — удобный и полностью изолированный от инфраструктуры

Читать далее

Поднимаем динамические окружения (фича-стенды) для stateless- и stateful-сервисов

Уровень сложностиПростой
Время на прочтение14 мин
Количество просмотров6K

На связи Игорь Латкин, управляющий партнер и системный архитектор в KTS

Мы на своём опыте разобрались в развертывании stateless- и stateful-сервисов, и теперь хотим поделиться с вами. Мы в KTS не раз создавали подобные инфраструктуры, перепробовали разные решения и выясняли, как построить эффективные процессы.

Сегодня мы поговорим о динамических окружениях (фича-стендах) для stateless- и stateful-сервисов, обсудим особенности и проблемы, которые могут возникнуть и возникали у нас.

Читать далее

Почему я перестал говорить с архитекторами о микросервисах

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров25K

На прошлой неделе это случилось снова. Я был на совещании по анализу архитектуры, и коллега-архитектор начал ещё одну оживлённую дискуссию о микросервисах. Спустя считанные минуты взгляд присутствующих остекленел, и мы погрузились в абсурдное обсуждение того, что должно быть средством для достижения цели, но превратилось в саму цель. В тот самый момент я осознал: с меня хватит. Я наконец-то поклялся больше не общаться с архитекторами о микросервисах. Почему? Да потому, что такие обсуждения обычно не приводят ни к чему продуктивному.

Читать далее