Комментарии 4
Спасибо за статью, тема интересная!
Я понимаю, что это первая статья из цикла, но как будто маловато технических подробностей для затравки:
Какой минимум времени уходит от вызова команды инита сервиса до деплоя в прод? С учетом подключения всей инфраструктуры (условный кубер, БД, логи, дашборды)
Для синхронного общения взяли только один протокол — gRPC. На первом этапе этого было достаточно, но в будущем у нас, конечно же, появился HTTP.
Для gRPC и HTTP пользователь пишет разные спеки или какую-то одну?
как собирать логи и метрики и отправлять спаны в трейсинг
Тут было интересно послушать какой стек выбрали для всего этого — от библиотек до бэкендов.
И было бы здорово узнать глубину observability — что может увидеть пользователь в платформенных графиках, логах и трейсах из коробки
Привет!
Я понимаю, что это первая статья из цикла, но как будто маловато технических подробностей для затравки:
Да, технических подробностей пока будет немного. Сейчас мы хотели рассказать историю и обзор возможностей, но дальше, конечно, будем добавлять статьи с техникой.
Какой минимум времени уходит от вызова команды инита сервиса до деплоя в
прод? С учетом подключения всей инфраструктуры (условный кубер, БД,
логи, дашборды)
Первый наш эксперимент показал, что от создания сервиса, до выкатки ушло 4 минуты. Это было больше сделано для продвижения PaaS в компании, в реальности выходило чуть больше. Прошло время и сейчас среднее время это минут 15: добавилось много линтеров, проверки на безопасность, тесты и прочее.
Для gRPC и HTTP пользователь пишет разные спеки или какую-то одну?
Да, спеки разные (proto и openapi), т.к. HTTP это для доступа к сервису через Gateway API, а gRPC для внутреннего общения между сервисами.
Тут было интересно послушать какой стек выбрали для всего этого — от библиотек до бэкендов.
Для метрик: https://github.com/prometheus/client_golang, бэк https://victoriametrics.com/
Для логов: https://github.com/uber-go/zap, бэк ELK
Для tracing изначально использовали https://github.com/opentracing/opentracing-go, затем мигрировали на https://github.com/open-telemetry/opentelemetry-go. В данный момент в компании на прием спанов работают Jaeger и Sentry. Приложение на Go может отправлять в любой из них.
И было бы здорово узнать глубину observability — что может увидеть
пользователь в платформенных графиках, логах и трейсах из коробки
Тут можно много рассказать и показать, боюсь в комментарии много не раскрою, лучше отдельную статью сделаю.
Первый наш эксперимент показал, что от создания сервиса, до выкатки ушло 4 минуты
круто, впечатляет
Да, спеки разные (proto и openapi), т.к. HTTP это для доступа к сервису через Gateway API, а gRPC для внутреннего общения между сервисами.
А если пользователю нужно сгенерить один и тот же хэндлер и для grpc и для http (например для фронта и для другого сервиса), получается ему нужно описать это в двух спеках и написать две реализации (и потом еще следить, чтобы они не разошлись)? Не рассматривали ли варианты вроде https://github.com/grpc-ecosystem/grpc-gateway для того, чтобы все было в одной спеке?
А если пользователю нужно сгенерить один и тот же хэндлер и для grpc и
для http (например для фронта и для другого сервиса), получается ему
нужно описать это в двух спеках и написать две реализации (и потом еще
следить, чтобы они не разошлись)?
Пакет https://github.com/grpc-ecosystem/grpc-gateway тоже используем, и такая возможность http->grpc включается переменной окружения. Но всё же мы различаем взаимодействие внутреннее (gRPC) и внешнее (фронт, мобильное приложение, клиенты), которое у нас принято описывать по спецификации openapi. Поэтому такой прокси в основном у тестировщиков востребован.
Разработка сервисов без боли: как подступиться к созданию PaaS