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

Цели данной публикации:

• Краткое введение в Consumer Driven Contracts (CDC)
• Настройка CI pipeline на основе CDC

Consumer Driven Contracts

В этой части мы пройдемся по основным моментам CDC. Данная статья не является исчерпывающей на тему контрактного тестирования. Существует достаточное количество материалов на эту тему на том же Хабре.

Для продолжения нам необходимо познакомиться с основными положениями CDC:

• Контактное тестирование находится на уровне Service/Integration Tests над Unit Tests согласно пирамиде автотестирования (Mike Cohn)
• Контрактное тестирование может применяться, когда есть 2 (или более) сервиса, которые взаимодействуют друг с другом
• Сonsumer driven подход означает, что первым шагом в реализации является написание теста на стороне потребителя. Результатом теста является пакт (контракт) в формате json, который описывает взаимодействие между потребителем (например, веб-интерфейс / мобильный интерфейс: сервис, который хочет получить некоторые данные) и поставщиком (например, серверный API: сервис, который предоставляет данные)
• Следующим шагом является проверка договора с провайдером. Это полностью осуществлено фреймворком Pact.

Данная статья будет интересна как тестировщикам, так и разработчикам, но рассчитана в большей степени на автоматизаторов, которые столкнулись с проблемой настройки GitLab CI/CD для проведения интеграционного тестирования в условиях недостаточности инфраструктурных ресурсов и/или отсутствия платформы оркестрации контейнеров. Я расскажу, как настроить развертывание тестируемых окружений при помощи docker compose на одном единственном GitLab shell раннере и так, чтобы при развертывании нескольких окружений запускаемые сервисы друг другу не мешали.

Андрей Копылов, наш технический директор, любит, активно использует и пропагандирует Docker. В новой статье он рассказывает, как создать пользователей в Docker. Правильная работа с ними, почему пользователей нельзя оставлять с root правами и, как решить задачу несовпадения идентификаторов в Dockerfile.

Это продолжение статьи «Пишем первый микросервис на Node.js с общением через RabbitMQ», которая была неплохо принята пользователями хабра.

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

Со временем, каждый проект растет и реализовывать новый функционал в существующий монолит становится все сложнее, дольше и дороже для бизнеса.

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

На третьей встрече из серии Backend United мы с коллегами из Booking, Dodo Pizza и Авито обменялись опытом работы с микросервисной архитектурой. Говорили о распилах, монолитах и всём, что за этим стоит. Этот пост — отчёт о том, как прошёл митап. Внутри — видеозаписи, презентации спикеров, ссылки на фотоотчёт и отзывы участников встречи.

Постановка задачи

Приветствую всех читателей Хабра! Меня зовут Игорь Рыбаков и я технический директор в казахстанской IT-компании DAR. Сегодня я поделюсь с вами пониманием и использованием принципов параллельных вычислений в современных информационных системах. Чтобы глубже разобраться в этом, я хотел бы привести аргументы в пользу изучения и практического применения концепций параллельных и распределенных вычислений при разработке современных информационных систем.

Параллельные вычисления или при чем тут основатель Intel

Сначала немного истории. В 1965 году Гордон Мур, один из основателей Intel, обнаружил закономерность: появление новых моделей микросхем наблюдалось спустя примерно год после предшественников, при этом количество транзисторов в них возрастало каждый раз приблизительно вдвое. Получается, что количество транзисторов, размещаемых на кристалле интегральной схемы, удваивалось каждые 24 месяца. Такое наблюдение стало называться законом Мура. Основатель Intel предсказал, что количество элементов в чипе вырастет с 2^6 (порядка 60) в 1965 году до 2^16 (65 тыс.) уже к 1975 году.

Введение

Седьмого марта компания RedHat (вскоре — IBM) представила новый фреймворк — Quarkus. По словам разработчиков, этот фреймворк базируется на GraalVM и OpenJDK HotSpot и предназначен для Kubernetes. Стек Quarkus включает в себя: JPA/Hibernate, JAX-RS/RESTEasy, Eclipse Vert.x, Netty, Apache Camel, Kafka, Prometheus и другие.

Цель создания — сделать Java лидирующей платформой для развертывания в Kubernetes и разработки serverless приложений, предоставляя разработчикам унифицированный подход к разработке как в реактивном, так и в императивном стиле.

Если смотреть на эту классификацию фреймворков, то Quarkus где-то между "Aggregators/Code Generators" и "High-level fullstack frameworks". Это уже больше, чем агрегатор, но и до full-stack не дотягивает, т.к. заточен на разработку backend.

Привет! Мы продолжаем Backend United, серию митапов для разработчиков серверной части. Третья встреча называется «Холодец», и посвящена она будет микросервисной архитектуре. Вместе с коллегами из Booking.com, Dodo Pizza и Авито поговорим о монолитах, распилах и обратной стороне сервис-ориентированной архитектуры.

Регистрируйтесь на встречу и приглашайте коллег. Под катом — тезисы выступлений, ссылки на регистрацию и видеотрансляцию митапа.