Recommended
More Related Content
What's hot
What's hot (19)
Similar to Как справиться с микросервисом
Similar to Как справиться с микросервисом (20)
Как справиться с микросервисом
- 2. От монолита к микросервису Каков порог вхождения?
- 4. Все просто станет сложнее • Запуск системы • Отладка • Тестирование • Доставка до серверов • Мониторинг
- 7. Придумать как приложения будут между собой общаться
- 8. Придумать как приложения будут между собой общаться • У каждого приложения может быть свой REST API. Приложения будут посылать друг другу запросы, получать ответы. • Организовать очередь сообщений (Message Queue) • Реализовать удаленный вызов процедур (RPC) • еще что-то…
- 9. Message Queues • Rabbit MQ • Zero MQ • NATS • Apache Active MQ
- 10. RPC • Можно взять за основу Google RPC фреймворк www.grpc.io • Мы в Tengriwallet запилили похожее на grpc решение, только на Руби
- 11. Что еще может помочь
- 12. Docker • Изоляция окружения • Версионирование пакетов продумано за вас • Собрал приложение в одной среде, перенес легко на другую • Устраняем вариации, которые вредят
- 13. Средства доставки и оркестрации Докер контейнерами • Docker Swarm • Kubernetes • Bash скрипты
- 14. Service Discovery • etcd • Consul • сами в конфигах каждого модуля задаете руками адреса соседних модулей
- 15. Централизованное логгирование • ELK (Elasticsearch, Logstash, Kibana) • Graylog • еще куча вариантов
- 16. Мониторинг приложения • В случае монолитного приложения можно было ограничиться NewRelic • В случае с микросервисом не все так просто. Есть открытая инициатива opentracing.io по распределенной трассировке.
- 17. Не пытайтесь делать все сразу
Editor's Notes
- Я — Миша. Старший разработчик в финтех проекте tengriwallet. В промышленной разработке уже 8 лет. Почему мне можно верить? Больше года мы строим микросервисное приложение.
- Вот вы решили переехать с монолитного приложения на микросервисное. Вы столкнетесь с вещами, о которых просто не думали до этого: интеграционная шина, service discovery, eventual consistency.
- Уже нельзя запустить приложение одной командой в консоли или нажав F5 в IDE. За одну функциональность будет отвечать несколько модулей, поэтому придется переключаться между ними распутывая поведение приложения. Тестировать придется не только отдельные сервисы, но и их интеграцию. Запуск тестового окружения так же станет сложнее. Поставить на сервер оно приложение гораздо проще, чем сотню.
- Автоматизация — самый главный инструмент в вашем арсенале. Если вы не привыкли автоматизировать все свои рутинные действия, то придется привыкнуть. Рутинные задачи растут геометрически с добавлением каждого нового модуля. Нужно наращивать DevOps экспертизу в команде разработчиков. Байка про то, как на поддержку попало приложение из 17-ти модулей. Просто пройти и сделать git pull стало в 17 раз сложнее.
- Самые популярные методы взаимодействия я перечислил, но все ограничивается только фантазией разработчика.
- Очереди делятся на очереди с брокером и очереди без брокера. Самая быстрая очередь 0MQ, но она без брокера. С брокерам самая быстрая по нынешним бенчмаркам NATS
- Упомянуть про prtobuffs когда рассказывать про GRPC Рассказать какие предпосылки были сделать свое решение.
- Ок, мы сделали Докер контейнеры со своими приложениями. Теперь их надо доставить на сервера, зупустить, остановить, перезапустить по надобности. Докер — хорошее развивающееся сообщество, которое предлагает хорошие инструменты вокруг контейнеризации. Swarm — это утилита для управления группами контейнеров. Kubernetes — мощная платформа для этих задач, которую применяют в гугле.
- Когда кол-во сервисов растет, встает проблема обнаружения сервисов внутри инфраструктуры. До какого-то момента можно просто прописывать в конфигах ближайших адресатов модулей. Потом нужно применять специальные тулзы. Как правило это обычный key-value storage в котором регистрируется приложение и его тип. И из этого общего реестра все понимают что теперь этому приложению можно направлять определенные запросы.
- Когда приложений много, то становится неудобным и трудозатратным просматривать логи каждого из модулей по отдельности. Гораздо эффективнее организовать сбор, просмотр и фильтрацию в одном месте. Более того, на этих логах по определенным выборкам можно построить мониторинг.
- В своем проекте мы только только подходим к задаче распределенной трассировки. Будем решать ее на уровне БСМ, а может и внедрим opentracing.
- Если будете внедрять все инструменты сразу, то скорее всего потерпите крах. Каждый сдай этой презентации достоин того, чтобы посвятить ему отдельную лекцию, а время на уверенное освоение можем занять до месяца. Больше года уйдет просто чтобы организовать грамотную инфраструктуру и процесс при том, что бизнес задач будет решено ничтожно мало. Как я уже сказал, задачи по мониторингу мы только только начинаем делать, и вещей, которые надо бы внедрить еще куча.