Дорога к микросервисной архитектуре

Дорога к микро-сервисам

Василий Васильков, Ecwid

Ecwid

• SaaS-платформа для создания интернет-магазинов

• ~750.000 клиентов

• ~100.000.000 посетителей в месяц

• 80 человек в команде

• Ульяновск, Казань, Самара и San Diego

Как начинали

• Начали с трех сервисов• Через три года их стало десять• Это не так много, но…

Проблемы

• Четыре разных протокола меж-сервисного “общения”

• Три разных “каркаса” для создания сервисов

• Три разных стратегии обновления• Три разных формата пакетов и способов старта на production

Всей команде приходится знать и помнить про эти отличия

Следствия

• Время создания нового сервиса очень большое (дни)• Подготовка к деплою очень долгая (дни)

• Время разработки и поддержки увеличивается

Планы

• За первые годы мы сделали 10 сервисов

• За следующий год мы хотим +25

Как быть?

• Единый RPC

• Единая инфраструктура

Единый RPC

• Сервисам нужны разные способы “общаться” друг с другом:

• SYNC (обычный вызов точка-точка)

• ASYNC (отложенный вызов через очередь сообщений)

• STREAM (broadcast, pub-sub, один сервис сразу всем)

stream

Единый RPC

• Повтор неудачного запроса N раз к разным серверам.

Это должен делать сам протокол.

retry with backoff

Единый RPC

• Быстрая сериализация• Forward/backward совместимая

protobuf vs JAXB

• Быстрее, но не очень (в 2-5 раз)

• Меньше, но не очень (в полтора раза)

• Проще• Внутри это обычный объект• Есть куча кода, готового для

JAXB-сериализации

XML

protobuf vs JAXB

• Быстрее, но не очень (в 2-5 раз)

• Меньше, но не очень (в полтора раза)

• Проще• Внутри это обычный объект• Есть куча кода, готового для

JAXB-сериализации

XML

Хорошо, дайте два

Единый RPC

• Простая реализация• …и использование

Реализация

• Или слишком просто или АДЪ

• Наша реализация: ~60 классов, 3k loc

Пример

Пример

• Асинхронный вызов с аргументами будет сериализован и отправлен в очередь• Будет ждать пока один из серверов-адресатов не пойдет разбирать эту очередь и выполнять отложенные вызовы

Единая инфраструктура

• У любого сервиса есть общие части. Это НЕ бизнес-логика!

• Писать в каждом сервисе с нуля?

• Copy-Paste Driven Development?


• Все вместе занимает примерно 1.000 строк кода

• 30 сервисов - 30.000 строк одинакового кода?

• Тупо? Тупо!


• Разработчики довольны• А админы?


• Пакеты всех сервисов идентичны service.propertiesstartup.shlib/*.jar

• Запуск любого сервиса выполняется одними и теми же скриптами (уже написанными :)

• Логи в известном месте в известном формате

• Требования к любой машине понятны: linux, jdk, consul


• Базовые метрики (HTTP, PostgreSQL) всегда идут в graphite

• У всех сервисов единые служебные endpoint’ы:/self-test/warmup/version

• Сервисы сами регистрируют себя в consul и поддерживают

состояние живой/нет, не надо писать отдельных скриптов

• В проекте 30+ сервисов, как с ними работать?

Локальная разработка

Локальная разработка

Итог

• Беспощадная стандартизация• На всех уровнях, не только для разработки• Огромный простор для дальнейших оптимизаций

Вопросы?

Василий Васильков, @2vgv

Дорога к микросервисной архитектуре

Software

Transcript of Дорога к микросервисной архитектуре