Привет! Мы продолжаем Backend United, серию митапов для разработчиков серверной части. Третья встреча называется «Холодец», и посвящена она будет микросервисной архитектуре. Вместе с коллегами из Booking.com, Dodo Pizza и Авито поговорим о монолитах, распилах и обратной стороне сервис-ориентированной архитектуры.
Регистрируйтесь на встречу и приглашайте коллег. Под катом — тезисы выступлений, ссылки на регистрацию и видеотрансляцию митапа.
Всем привет!
Я бы хотел немного рассказать о проекте, над которым я работал последние полгода. Проект я делаю в свободное время, но мотивация к его созданию пришла из наблюдений, сделанных на основной работе.
На рабочем проекте мы используем архитектуру микросервисов, и одна из главных проблем, которая проявилась со временем и выросшим количеством этих самых сервисов — это тестирование. Когда некий сервис зависит от пяти-семи других сервисов, плюс ещё какая-нибудь база данных (а то и несколько) в придачу, то тестировать это в "живом", так сказать виде, весьма неудобно. Приходится обкладываться моками со всех сторон так плотно, что самого теста и не разглядеть. Ну или каким-то образом организовывать тестовое окружение, где все зависимости могли бы реально быть запущены.
Эта статья содержит краткую выжимку из моего собственного опыта и опыта моих коллег, с которыми мне днями и ночами доводилось разгребать инциденты. И многих инцидентов не возникло бы никогда, если бы всеми любимые микросервисы были написаны хотя бы немного аккуратнее.
К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.
Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.
Всем привет!
В этой статья я продемонстрирую основные компоненты для создания Reactive RESTful миксросервисов, используя Spring WebFlux, Spring Security, Spring Cloud Netflix Eureka (Service Discovery), Hystrix (Circuit Breaker), Ribbon (Client Side Load Balancer), External Configuration (через git repository), Spring Cloud Sleuth, Spring Cloud Gateway, Spring Boot Reactive MongoDB. А также Spring Boot Admin и Zipkin для мониторинга.
— Секрет успеха поставщика заключается в том, чтобы дать потребителям качественный товар… ой, то есть сервис. Ну и еще важно не пускаться во все тяжкие с нарушением обратной совместимости.
Уолтер Уайт
Это перевод статьи, описывающей шаблон Consumer-Driven Contracts (CDC).
Оригинал опубликован на сайте Мартина Фаулера за авторством Яна Робинсона.
В микросервисной архитектуре зависимости между сервисами являются источником проблем. Шаблон CDC помогает решать эти проблемы способом, устраивающим и разработчиков сервиса, и его потребителей. Фаулер ссылается на Consumer-Driven Contracts в ключевой статье по микросервисной архитектуре: Microservices.
Статья будет особенно полезна командам, разрабатывающим сервисы для нескольких потребителей в рамках одной организации, и командам-потребителям таких сервисов.
13 сентября в офисе Wrike прошел бэкенд-митап, посвященный глобальным изменениям в продукте. Поговорили о глобальном рефакторинге, смене методологии разработки на лету, унификации в проектах и микросервисах.
Для тех, кто не смог прийти, мы публикуем видеозаписи докладов.
Читать полностью »
GraphQL часто представляют как революционный путь дизайна веб API по сравнению с REST. Однако, если вы ближе посмотрите на эти технологии, то вы увидите, что между ними очень много различий. GraphQL относительно новое решение, исходники которого были открыты сообществу Фейсбуком в 2015 году. Сегодня REST все еще самая популярная парадигма, используемая для предоставления API и взаимодействия между микросервисами. Сможет ли GraphQL обогнать REST в будущем? Давайте посмотрим, как происходит микросервисное взаимодействие через GraphQL API с ипользованием Spring Boot и библиотеки GQL.
Читать полностью »
15 сентября в офисе Авито состоится встреча, посвященная масштабированию приложений на PostgreSQL. Поговорим об алгоритмах и нюансах реализации транзакционности в языках программирования, построении бизнес-транзакций в сервисах с паттерном database per service, как устроена OZO — асинхронная типобезопасная header-only библиотека-клиент PostgreSQL для C++17, и уровнях изоляции транзакций PostgreSQL. С докладами выступят Стас Кельвич (Postgres Professional), Сергей Хандриков (Яндекс), Константин Евтеев (Авито) и Михаил Тюрин. Регистрируйтесь на встречу и приглашайте коллег. Под катом — тезисы выступлений докладчиков, ссылка на регистрацию и информация по трансляции митапа.
Часто приложения развиваются посредством множества небольших улучшений, но наступает момент, когда множество частностей выстраивается в цельную картину, реализация которой требует качественных и масштабных изменений. И здесь только одной хорошей идеи недостаточно. Не менее важны организационная и техническая составляющие вопроса. Как подготовиться и осуществить архитектурные изменения в работающей системе? Мы хотим поговорить о глобальном рефакторинге, повышении производительности систем, оптимизации кода, подходах работы с базами данных и многих других вещах.
Читать полностью »
Микросервисная архитектура уже давно де-факто стала стандартом при разработке больших и сложных систем. Она имеет целый ряд преимуществ: это и строгое деление на модули, и слабая связность, и устойчивость к сбоям, и постепенность выхода в продакшн, и независимое версионирование компонентов.
Правда, зачастую, говоря о микросервисной архитектуре, упоминают только бэкенд-архитектуру, а фронтенд как был, так и остается монолитным. Получается, что мы сделали великолепный бэк, а фронт тянет нас назад.
Сегодня я расскажу вам, как мы делали микросервисный фронт в нашем SaaS-решении и с какими проблемами столкнулись.
Читать полностью »
