Документ обсуждает переход компании Ecwid к микросервисной архитектуре, описывая вызовы, с которыми они столкнулись, такие как сложности в межсервисном взаимодействии и длительность разработки. Для решения этих проблем предлагается внедрение единого RPC и единой инфраструктуры, что упростит коммуникацию и стандартизирует процессы. В результате компания стремится увеличить количество сервисов и улучшить эффективность разработки.

1. Дорога к микро-сервисам
Василий Васильков, Ecwid

2. Ecwid
• SaaS-платформа для создания интернет-магазинов
• ~750.000 клиентов
• ~100.000.000 посетителей в месяц
• 80 человек в команде
• Ульяновск, Казань, Самара и San Diego

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

4. Проблемы
• Четыре разных протокола меж-сервисного “общения”
• Три разных “каркаса” для создания сервисов
• Три разных стратегии обновления
• Три разных формата пакетов и способов старта на production
Всей команде приходится знать и помнить про эти отличия

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

6. Планы
• За первые годы мы сделали 10 сервисов
• За следующий год мы хотим +25

7. Как быть?
• Единый RPC
• Единая инфраструктура

8. Единый RPC
• Сервисам нужны разные способы “общаться” друг с другом:
• SYNC (обычный вызов точка-точка)
• ASYNC (отложенный вызов через очередь сообщений)
• STREAM (broadcast, pub-sub, один сервис сразу всем)

9. sync

10. async

11. stream

12. Единый RPC
• Повтор неудачного запроса N раз к разным серверам.
Это должен делать сам протокол.

13. retry
with backoff

14. Единый RPC
• Быстрая сериализация
• Forward/backward совместимая

15. protobuf vs JAXB
• Быстрее, но не очень
(в 2-5 раз)
• Меньше, но не очень
(в полтора раза)
• Проще
• Внутри это обычный объект
• Есть куча кода, готового для
JAXB-сериализации
XML

16. protobuf vs JAXB
• Быстрее, но не очень
(в 2-5 раз)
• Меньше, но не очень
(в полтора раза)
• Проще
• Внутри это обычный объект
• Есть куча кода, готового для
JAXB-сериализации
XML
Хорошо, дайте два

17. Единый RPC
• Простая реализация
• …и использование

18. Реализация
• Или слишком просто или АДЪ
• Наша реализация: ~60 классов, 3k loc

19. Пример

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

21. Единая инфраструктура
• У любого сервиса есть общие части. Это НЕ бизнес-логика!
• Писать в каждом сервисе с нуля?
• Copy-Paste Driven Development?

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

24. Единая инфраструктура
• Все вместе занимает примерно 1.000 строк кода
• 30 сервисов - 30.000 строк одинакового кода?
• Тупо? Тупо!

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

27. Единая инфраструктура
• Разработчики довольны
• А админы?

28. Единая инфраструктура
• Пакеты всех сервисов идентичны
service.properties
startup.sh
lib/*.jar
• Запуск любого сервиса выполняется одними и теми же
скриптами (уже написанными :)
• Логи в известном месте в известном формате
• Требования к любой машине понятны: linux, jdk, consul

29. Единая инфраструктура
• Базовые метрики (HTTP, PostgreSQL) всегда идут в graphite
• У всех сервисов единые служебные endpoint’ы:
/self-test
/warmup
/version
• Сервисы сами регистрируют себя в consul и поддерживают
состояние живой/нет, не надо писать отдельных скриптов

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

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

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

34. Вопросы?
Василий Васильков, @2vgv