У нас сейчас действительно CB на уровне отдельных инстансов и, как правило, в логах можно наблюдать, как они практически одновременно открываются на каждом из инстансов. Да, я чуть-чуть смотрел на Istio, согласен, что в случае горизонтального масштабирования это выглядит лучше. Спасибо за ваш совет.
Вы правы, хорошее замечание, такая проблема существует. И, пожалуй, неправильно выбирать какой-то константный таймаут для любого сервиса вне зависимости от архитектуры вашего решения. Сейчас мы больше опираемся на здравый смысл с выбором таймаутов в разных сервисах. Какого-то эффективного механизма или формулы правильной настройки таймаутов я пока не знаю.
У них немножко разная природа. 503 тоже считается транзиентной ошибкой и тоже ретраится.
429 это же клиентский код, это значит, что сервер может его использовать пока он еще в состоянии обрабатывать запросы, но ему уже сложно. Например, когда вы используете bulkhead на стороне сервера, и намеренно обрубаете запросы, которые не влезают в очередь.
А 503 – это уже как бы последняя стадия. Не смогла, так не смогла.
Про кейсы.
Ну например, мы послали запрос в пулл серверов и получили ответ 429. Что это означает? Это означает, что конкретный инстанс сейчас перегружен, ему тяжело. Это не значит, что соседний инстанс не сможет обработать запрос.
Таймаут мы можем получить опять же по причине утилизации коннекшенов.
Кейс с рестартом сервиса тоже валидный, так как по разным причинам такое может случиться.
Про количество и время.
Опять же, вопрос что с чем взаимодействует. Например, у нас есть платежный шлюз и есть эквайреры, у которых заложено очень большое время на ответ. И ты вынужден, во-первых, долго ждать, во-вторых, очень хочется прийти в консистентное состояние в результате взаимодействия.
Теоретически можно, но там нет же ничего интересного. Да и код на коленке написан. Если хочется что-то поковырять, то я рекомендую, например, Polly, но уж точно не нашу Алхимию :)
Скорее могу порекомендовать подписку на O'Reilly :)
Если серьезно, то часто приходится читать что-то под задачу или технологию, с которой работаешь. Например, здесь я открыл для себя Spark, с которым не работал ранее. Сейчас изучаю его в том числе по книге:
Spark: The Definitive Guide by Matei Zaharia, Bill Chambers
Из материалов, не привязанных к конкретным технологиям или базам, я бы рекомендовал посмотреть на:
Designing Data-Intensive Applications by Martin Kleppmann
Building a Scalable Data Warehouse with Data Vault 2.0 by Daniel Linstedt, Michael Olschimke
Вот еще, что успел полистать, мне понравилось и это в шорт-листе на чтение:
Database Internals by Alex Petrov
Designing Event-Driven Systems by Ben Stopford
Event Streams in Action by Alexander Dean, Valentin Crettaz
И пара рекомендаций от коллег:
Data Architecture: A Primer for the Data Scientist, 2nd Edition by W.H. Inmon, Daniel Linstedt, Mary Levins
DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition) by DAMA International
Еще можно доклады со Strata Data Conference by O'Reilly посмотреть.
У вас же .net в профиле, а там автомаппер всё решает, одно удовольствие.
Про мапперы я шутил, конечно. Хотя у нас в монолитном проекте достаточно много мапперов сделано вручную и на то была причина: у автомаппера были проблемы в свое время, он, если я не ошибаюсь, падал в рантайме иногда.
Про цели и заказчика — очень хороший вопрос. Цель: интеграция данных компании в одном месте. Данных, которым можно доверять. В это понятие включается: очистка, полнота, разложение в удобном для последующей аналитики виде.
Заказчиков у нас несколько. С одной стороны у нас есть большая система Dodo IS, в которой большое количество отчетов для наших партнеров. Это один наш заказчик. С другой стороны есть наша Управляющая Компания, есть команда BI, которым тоже нужна аналитика и ad-hoc запросы, это второй заказчик.
Нужно определить понятие Data Engineering и сферу деятельности. Конкретно в нашей компании сейчас это такой зонтичный бренд, включающий в себя проектирование архитектуры хранилища, моделирование данных, пайплайны, совместную работу с командами разработки над сбором состояния их сервиса, а еще просто накопление экспертизы по работе различных (в том числе и OLTP) баз данных в целом.
Конечно, если рассматривать DE как запускаторов ETL/ELT пайплайнов, то это довольно грустно. Но у нас, к счастью, есть много других задач.
А что касается карьеры. Если быть предельно откровенным, то я сейчас в таком ключе про это не думаю, просто занимаюсь тем, что интересно на данный момент и полезно для компании, дальше будет видно :)
Кстати, нельзя сказать, что мы больше не разрабатываем вообще. У нас есть свои внутренние сервисы, которые мы сами написали и поддерживаем.
Сбежать? Опять писать мапперы? Да ну. Это шутка, конечно. Нет, совсем не хочется. Хочется разобраться, как правильно работать с данными. И еще хочется, чтобы то, что мы делаем, не было таким таинством для разработчиков. Так что тут большое поле для деятельности и познания.
Какие направления развития? Я думаю, что эта область меня еще займет на долгое время, а там будет видно. Я пока только на спринт планироваться умею. В ближайшие две недели точно останусь в DE :)
В этом и состоит красота данной задачи. У нее еще есть любопытные вариации:
1) Например, гонцы ходят двумя дорогами, южная и северная. Причем генерал А1 — посылает гонца всегда южной дорогой, а А2 — всегда северной. Оппонент выставляет стражу на одну из дорог и случайно может перехватить, а может и не перехватить одного гонца.
2) Те же условия, что и в (1), но оппонент кидает монетку в самом начале, выбирает направление и всегда пытается поймать только на этом направлении.
3) Те же условия, что и в (2), но оппонент гарантированно ловит гонца на выбранном направлении.
В каких из этих кейсов генералы могут договориться, а в каких нет?
Вы правы, в статье я рассмотрел только самый позитивный сценарий, основной идеей статьи было, скажем так, интро в проблему консенсуса в распределенных системах. Конечно, каждый из алгоритмов заслуживает отдельной подробной статьи и даже не одной.
Вы имеете в виду ссылки на репозитории с кодом практических имплементаций алгоритма или про использование большими компаниями?
Если второе, то я натыкался на несколько статей, например, блог MySQL High Availability и блог Apache Cassandra, правда там совсем старая статья, не знаю, что используется сейчас.
У нас сейчас действительно CB на уровне отдельных инстансов и, как правило, в логах можно наблюдать, как они практически одновременно открываются на каждом из инстансов. Да, я чуть-чуть смотрел на Istio, согласен, что в случае горизонтального масштабирования это выглядит лучше. Спасибо за ваш совет.
429 это же клиентский код, это значит, что сервер может его использовать пока он еще в состоянии обрабатывать запросы, но ему уже сложно. Например, когда вы используете bulkhead на стороне сервера, и намеренно обрубаете запросы, которые не влезают в очередь.
А 503 – это уже как бы последняя стадия. Не смогла, так не смогла.
Про кейсы.
Ну например, мы послали запрос в пулл серверов и получили ответ 429. Что это означает? Это означает, что конкретный инстанс сейчас перегружен, ему тяжело. Это не значит, что соседний инстанс не сможет обработать запрос.
Таймаут мы можем получить опять же по причине утилизации коннекшенов.
Кейс с рестартом сервиса тоже валидный, так как по разным причинам такое может случиться.
Про количество и время.
Опять же, вопрос что с чем взаимодействует. Например, у нас есть платежный шлюз и есть эквайреры, у которых заложено очень большое время на ответ. И ты вынужден, во-первых, долго ждать, во-вторых, очень хочется прийти в консистентное состояние в результате взаимодействия.
Если серьезно, то часто приходится читать что-то под задачу или технологию, с которой работаешь. Например, здесь я открыл для себя Spark, с которым не работал ранее. Сейчас изучаю его в том числе по книге:
Из материалов, не привязанных к конкретным технологиям или базам, я бы рекомендовал посмотреть на:
Вот еще, что успел полистать, мне понравилось и это в шорт-листе на чтение:
И пара рекомендаций от коллег:
Еще можно доклады со Strata Data Conference by O'Reilly посмотреть.
Про мапперы я шутил, конечно. Хотя у нас в монолитном проекте достаточно много мапперов сделано вручную и на то была причина: у автомаппера были проблемы в свое время, он, если я не ошибаюсь, падал в рантайме иногда.
Про цели и заказчика — очень хороший вопрос. Цель: интеграция данных компании в одном месте. Данных, которым можно доверять. В это понятие включается: очистка, полнота, разложение в удобном для последующей аналитики виде.
Заказчиков у нас несколько. С одной стороны у нас есть большая система Dodo IS, в которой большое количество отчетов для наших партнеров. Это один наш заказчик. С другой стороны есть наша Управляющая Компания, есть команда BI, которым тоже нужна аналитика и ad-hoc запросы, это второй заказчик.
Нужно определить понятие Data Engineering и сферу деятельности. Конкретно в нашей компании сейчас это такой зонтичный бренд, включающий в себя проектирование архитектуры хранилища, моделирование данных, пайплайны, совместную работу с командами разработки над сбором состояния их сервиса, а еще просто накопление экспертизы по работе различных (в том числе и OLTP) баз данных в целом.
Конечно, если рассматривать DE как запускаторов ETL/ELT пайплайнов, то это довольно грустно. Но у нас, к счастью, есть много других задач.
А что касается карьеры. Если быть предельно откровенным, то я сейчас в таком ключе про это не думаю, просто занимаюсь тем, что интересно на данный момент и полезно для компании, дальше будет видно :)
Кстати, нельзя сказать, что мы больше не разрабатываем вообще. У нас есть свои внутренние сервисы, которые мы сами написали и поддерживаем.
Какие направления развития? Я думаю, что эта область меня еще займет на долгое время, а там будет видно. Я пока только на спринт планироваться умею. В ближайшие две недели точно останусь в DE :)
1) Например, гонцы ходят двумя дорогами, южная и северная. Причем генерал А1 — посылает гонца всегда южной дорогой, а А2 — всегда северной. Оппонент выставляет стражу на одну из дорог и случайно может перехватить, а может и не перехватить одного гонца.
2) Те же условия, что и в (1), но оппонент кидает монетку в самом начале, выбирает направление и всегда пытается поймать только на этом направлении.
3) Те же условия, что и в (2), но оппонент гарантированно ловит гонца на выбранном направлении.
В каких из этих кейсов генералы могут договориться, а в каких нет?
Если второе, то я натыкался на несколько статей, например, блог MySQL High Availability и блог Apache Cassandra, правда там совсем старая статья, не знаю, что используется сейчас.