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

Инструменты для налаживания взаимодействия

О докладчике

• Больше 5 лет разработки на JS
• 2 fail проекта на микросервисах  
• 2 success истории с микросервисной архитектурой
• Awwcor - медицинские данные

Сергеев Кирилл

twitter: @cloudkserg

github: @cloudkserg

План

1. Микросервисы - зачем нужны

2. Проблема взаимодействия

3. Набор инструментов для решения

4. Пример использования инструментов

5. Вывод

Зачем нужны микросервисы

Все идеально и так

Экспоненциальный рост сложности монолитного приложения

• Объем кодовой базы
• Связанность
• Единый стандарт качества,
• Единая архитектура и единый подход
• Проблема разбитого окна
• Скрытое разделение ответственности

Какие последствия будут от моего изменения в коде?

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

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

• Деление системы на полностью изолированные компоненты
• Взаимодействие по различным протоколам 
• Развертывание микросервисов производится отдельно

Плюсы микросервисов

• Уменьшенное время внедрения фич (time-to-market)
• Дифференциация стандартов качества
• Легкость масштабирования

Минусы микросервисов

• Склонность к превращению в монолиты
• Централизованные точки доступа (транзакции)
• Время доступа по сети
• Дополнительный код
• Расходы на эксплуатацию

Плохой пример

Идеальная архитектура

Причины хаоса

 

• Несогласованность взаимодействия сервисов
• Отсутствие определенных границ сервисов
• Возросшая сложность инфрастуктурного кода

Наш девиз - вместо микро много макро!

Результат

• Тесты на сервисах deprecated
• Возросшее количество deprecated  фич
• Возросшая нагрузка на QA инфраструктуру и QA
• Time-to-market стремится к бесконечности

Статистика

Уроки микросервисов

На что обратить внимание

1. Тесты

2. Документация

3. Удобство работы с api

4. Внутренняя архитектура

На что обратить внимание

• Тестировать должно быть быстро
• Тесты и документация должны выводиться из кода
• Взаимодействие  должно быть регламентировано и понятно

Какими технологиями укрощаем

Consumer driver contract

Consumer

Producer

Request

Response

Tests

Tests

Pact-defined

Artillery

BDD Security

Линтеры

Linter

DevOps

Example of Dockerfile

CI & CD

Dev

Build Prod

QA

Prod

Build Dev

Local

Рабочий пример

Диктатура

БИЗНЕС - он же потребитель, consumer

Контракт

• Бизнес требование (цель)
• Параметры интерфейса (подробности задачи)
• Параметры производительности (за сколько)

Pact - взаимодействие, BDD - сценарий

Контракт

 

• Описание качество кода ( параметры линтера)
• Описание архитектуры ( тип + линтер)
• Описание параметров QA ( процент покрытия + линтер)
• Описание документации (параметры линтера)

EsLint, TsLint - Качество кода

Contract

Контракт

 

• Описание безопасности кода ( какая security информации может присутствовать + как сильны проверки)
• Описание стабильности (  должны ли быть тесты на мутации)

Security BDD, own scripts

 Contract with overrides

Иерархия контрактов

Low

High

High

Mutable

Low

Mutable

Брокер контрактов 

• Хранилище контрактов
• Производный от Pact Broker
• Каждый контракт имеет свой статус ( Draft - InProcess - QA - Release- Deprecated)
• Доступен всюду и всегда

Публикация в broker

• Какие контракты уже есть
• Есть ли пересечения по именам
• Версия контракта инкрементом
• Контракт нижнего уровня одной версии не может обеспечивать качество хуже чем контракт высшей версии
• Связанность контрактов

Процесс разработки микросервиса

• Написание  контракта
• Генерация тестов
• Создание Producer
• Публикация в Broker

Авто деплой на dev 

 

• Сервис проверен по тестам контракта 
• Сервису присвоен номер, тег, автор, контракт
• Сервис вылит и ответил - InProcess

Build Dev

Авто деплой на prod

• Сервис проверен линтерем на качество
• Сервис проверен по всем контрактам
• Сборка  
• Сервису присвоен номер, тег, автор, контракт
• Сервис вылит и ответил - Release

Build Prod

Логгирование

Fluentd

Graylog

Pino

Contract, RequestId, ProcessId, LastSnapshotId

Суть работы

С

С

С

С

С

Mobile

Web

Знание по контракту

 

1) Формат логов

2) Производительность

3) Интерфейс

4) Стиль кода

Суть системы

Contract

Own packages

Суть системы

• У каждого микросервиса есть контракт
• Контракты хранятся на брокере
• На каждое взаимодействие есть контракт
• Контракт пишет тот, кто хочет получить результат

Контракты

Суть системы

• Каждый контракт превращается в тест
• Не проходишь тесты контракта - не попадешь в деплой
• Все параметры - качество, тестирование, безопасность стараемся превратить в контракт 
• Контракты учитывают зависимость сервиса и ограничивают возможность использования других сервисов

Контракт - Тест - Зависимость

Преимущества системы

• Согласование сервисов
• Deprecated становится явным
• Единый источник требований, проверки и интерфейсов

Преимущества системы

• Ленивая генерация кода
• Синхронизация кода с контрактами
• Все становится кодом - безопасность, devops, qa
• Хорошо расширяемая система

Недостатки системы

• Пионеризм
• Отсутствие готовых решений
• Поддержка новой инфраструктуры
• Время с разработки перекладывается на согласование
• Бюрократия! Бюрократия! Бюрократия!

Результат

• Контролируемый time-to-market
• Сменяемость комманд без ущерба качества код
• Контролируемое качество кода

Мы не победили хаос

Мы приблизились к его контролю

Time-to-market - возврат к 1 часу

Возросла сложность

Статистика

Q&A

 

My twitter: https://twitter.com/cloudkserg

 

Pact: https://docs.pact.io

Karate framework: https://intuit.github.io/karate

Gatling: https://gatling.io

AsyncApi: https://www.asyncapi.org

Raml: https://raml.org

Bdd: https://continuumsecurity.net/bdd-security