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

Привет! Меня зовут Вадим Мадисон, я руковожу разработкой System Platform Авито. О том, как мы в компании переходим с монолитной архитектуры на микросервисную, было сказано не раз. Пора поделиться тем, как мы преобразовали свою инфраструктуру, чтобы извлечь из микросервисов максимум пользы и не дать себе в них потеряться. Как нам здесь помогает PaaS, как мы упростили деплой и свели создание микросервиса к одному клику — читайте дальше. Не всё, о чём я пишу ниже, в Авито реализовано в полной мере, часть — то, как мы развиваем нашу платформу.

(А ещё в конце этой статьи я расскажу о возможности попасть на трехдневный семинар от эксперта по микросервисной архитектуре Криса Ричардсона).

• На одной сцене собрались основные российские провайдеры — про специфику нашего облачного рынка и своих сервисов говорили Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, «Ростелеком — ЦОД» и «Яндекс.Облако»;
• Коллеги из «Битрикс24» рассказали, как они пришли к мультиклауду;
• «Леруа Мерлен», «Открытие», Burger King и Schneider Electric предоставили интересный взгляд со стороны потребителей облаков — какие задачи их бизнес ставит перед IT и какие технологии, в том числе облачные, видятся им наиболее перспективными.

Перевод статьи подготовлен для студентов курса «DevOps практики и инструменты» в образовательном проекте OTUS.

Когда в 2015 году начали появляться первые туториалы с использованием AWS Lambda и API Gateway, было неудивительно, что они в основном были сосредоточены на копировании микросервисной архитектуры. Но тем, кто использовал AWS Lambda в больших масштабах, с течением времени становилось понятно, что существуют значительные ограничения для применения микросервисного подхода к AWS Lambda…

• CPU лимиты
• Docker и server class machine
• CPU лимиты (да, опять) и фрагментация памяти
• Обрабатываем Java-OOM
• Оптимизируем потребление памяти
• Ограничиваем потребление памяти: heap, non-heap, direct memory
• Ограничиваем потребление памяти: Native Memory Tracking
• Java и диски
• Как за всем уследить?

Проблематика

• The Economist требовалось больше гибкости для распространения контента на все более разнообразные цифровые каналы. Для достижения этой цели и поддержания высокого уровня производительности и надежности, платформа перешла от монолитной к микросервисной архитектуре.
• Средства, написанные на Go, были ключевым компонентом новой системы, которая позволила The Economist предоставлять масштабируемые, высокопроизводительные сервисы и быстро создавать новые продукты.
• Go, нацеленный на параллелизм и поддержку API, вместе с его конструкцией статического компилируемого языка, облегчал разработку распределенных систем обработки событий которые могли бы масштабироваться. Поддержка тестирования также была плюсом.
• В целом, опыт работы команды The Economist с Go был положительным, и это был один из решающих факторов, которые позволили масштабировать Content Platform.
• Go не всегда будет являться подходящим инструментом, и это нормально. The Economist обладает платформой-полиглотом и использует разные языки там, где это имеет смысл.

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

• Краткое введение в 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.