Дело в том, что Python (да и Java) не имеет встроенной поддержки чисел с фиксированной точкой.
…
Для выполнения вычислений с фиксированной точкой в Python мне пришлось импортировать модуль Decimal
Вообще удивительно как автор всю специфику кобола свёл к фикс.точке.
Решит ли зукипер за это время, что меседж не законсьюмился и повторит ли операцию?
Зукипер не повторяет, повторяет консьюмер.
Если консьюмер не успел закормить чтение в регулируеооме временное окно то он считается выбывшим и эти данные передадут другому (если их в группе несколько). А когда консьюмер доработает — он попытается закоммититься в кафку и получит ошибку.
У нас были довольно медленные таски и в них эту проблему решали параллельным тредом в консьюмере, который раз в 30 сек коммитил предыдущее положение указателя.
Я не автор но скажу что тащить в прокрашен неизвестный проект 1-го разработчика имеющего известную альтернативу-предшественника с тысячами статей, туториалов и рассказов о том как поднимали когда всё сломалось — интересно, но слишком рискованно.
Интересно почему в других языках предпочитают только JSON/XML?
По тому что только эти форматы поддерживаются из коробки и без проблем в абсолютном большинстве языков.
Я как то уговорил команду на AVRO http://avro.apache.org/docs/1.8.2/ под питоном. В результате пришлось активно коммитить в питонячью реализацию, т.к. она была крива и не реализовывала стандарт.
Ох… А вы точно «банк»?
Где же все эти традиционные soa и esb? Выглядит так что вы переизбрали их, только менее надёжные
Охи трудно комментировать.
A ESB нет из разных вариантов решения проблем выбрали тот, который описан.
(очередь вместо шины и нет распределенных транзакций)
Есть распределенные транзакции но не между сервисами, а внутри. А нет их между сервиссами т.к. сделать полноценные распределенные транзакции при такой архитектуре трудно.
Так же вызывает вопросы надёжность вашего решения вот в каком кейсе: вы прочли сообщение из очереди, выполнили бизнессстранзакцию, сделали коммит в базе, и тут ваш процесс упал или случился сетеовой сбой и кафке вы не смогли сообщить об успешной обработке. Как система отработает?
1) Каждое отправляемое сообщение снабжается UUID. При получении сообщения его UUID сравнивается с уже полученными и включается логика сервиса. Либо сообщение отбрасывается либо обновляется состояние в БД.
2) По возможности транзакция не закрывается, пока не получен ответ от кафки.
Жрёт в смысле принял, потерял, а сказал что обработал?
А иногда молча не присылает задачи в… а куда он их слать должен?
В топик кафки, за состоянием (скорость наполнения и статус обработки) мы получаем бесплатный мониторинг.
Ты сделал мой день, такой смешной шутки я давно не слышал.
Интернета не было или просо отпуск?
A, так что мы сделали так, чтобы когда A выкатилось, мы просто чистили очередь задач от него, а новая должна начать их использовать.
Сам так не делаю и другим не советую.
вы неявно предполагаете, что operation хорошо понимает архитектуру получившегося комка
Я явно знаю что понимание улучшилось. Естественно не по тому что какая то особая «микросервисная магия», а потому что одновременно с распилом монолита происходит рефакторниг.
В конце концов всё всегда как обычно, слава Тьюрингу. Однако до наступления этого счастливого конца есть ещё ряд этапов, некоторые из которых стали заметно проще.
Судя по моему опыту как раз становиться легче. Изрядная часть проблем вида «в большой системе что то сдохло — пускай программисты читают логи» превратились в «Сервис Б перестал обрабатывать задачи от А, пускай программисты читают логи сервиса Б». При этом задачи ждут в кафке и как починят — будут обработаны.
>Думать о замене надо лишь в том случае, если что-то не устраивает в текущем решении.
Уязвимая позиция.
Как я узнаю что меня что-то не устраивает, если не узнавать новое о других системах?
Я так, например пол жизни думал что раз левая рука слабее правой, то и нормально что левое ухо слышит хуже правого.
> А какая мотивация у вас?
Репликация, контроль схемы, более живое сообщество.
Думаю тут будет много читателей знакомых с CH так что задам вопрос:
Есть одна микросервисная архитектура. Пара десятков микросервисов шлют друг-другу сообщения через кафку. В день набегает 10-20 млн сообщений. Для мониторинга этого вся важная информация из сообщений как есть (т.е. прямо транзакционка) перекладывается в InfluxDB (бесплатная) и заводится в графину, где уже выборки-фильтрации настраиваются.
Есть в CH то, ради чего в этой схеме следует InfluxDB заменить на CH?
Вообще для Flow-based programming много чего есть, но обычно оно либо монструозное и тащить в проект страшно, либо минималистичное и тащить в проект бесполезно.
Взаимоисключающие параграфы:
Вообще удивительно как автор всю специфику кобола свёл к фикс.точке.
Если консьюмер не успел закормить чтение в регулируеооме временное окно то он считается выбывшим и эти данные передадут другому (если их в группе несколько). А когда консьюмер доработает — он попытается закоммититься в кафку и получит ошибку.
У нас были довольно медленные таски и в них эту проблему решали параллельным тредом в консьюмере, который раз в 30 сек коммитил предыдущее положение указателя.
Я не автор но скажу что тащить в прокрашен неизвестный проект 1-го разработчика имеющего известную альтернативу-предшественника с тысячами статей, туториалов и рассказов о том как поднимали когда всё сломалось — интересно, но слишком рискованно.
Раз любая теория содержательна, то разве не следет в целях экономии мышления не давать определение содержательной теории?
По тому что только эти форматы поддерживаются из коробки и без проблем в абсолютном большинстве языков.
Я как то уговорил команду на AVRO http://avro.apache.org/docs/1.8.2/ под питоном. В результате пришлось активно коммитить в питонячью реализацию, т.к. она была крива и не реализовывала стандарт.
Охи трудно комментировать.
A ESB нет из разных вариантов решения проблем выбрали тот, который описан.
Есть распределенные транзакции но не между сервисами, а внутри. А нет их между сервиссами т.к. сделать полноценные распределенные транзакции при такой архитектуре трудно.
1) Каждое отправляемое сообщение снабжается UUID. При получении сообщения его UUID сравнивается с уже полученными и включается логика сервиса. Либо сообщение отбрасывается либо обновляется состояние в БД.
2) По возможности транзакция не закрывается, пока не получен ответ от кафки.
Жрёт в смысле принял, потерял, а сказал что обработал?
В топик кафки, за состоянием (скорость наполнения и статус обработки) мы получаем бесплатный мониторинг.
Интернета не было или просо отпуск?
Сам так не делаю и другим не советую.
Я явно знаю что понимание улучшилось. Естественно не по тому что какая то особая «микросервисная магия», а потому что одновременно с распилом монолита происходит рефакторниг.
Судя по моему опыту как раз становиться легче. Изрядная часть проблем вида «в большой системе что то сдохло — пускай программисты читают логи» превратились в «Сервис Б перестал обрабатывать задачи от А, пускай программисты читают логи сервиса Б». При этом задачи ждут в кафке и как починят — будут обработаны.
— www.cs.utexas.edu/~cannata/cs345/Class%20Notes/10%20Haskell%20Programmer%20Evolution.html
Уязвимая позиция.
Как я узнаю что меня что-то не устраивает, если не узнавать новое о других системах?
Я так, например пол жизни думал что раз левая рука слабее правой, то и нормально что левое ухо слышит хуже правого.
> А какая мотивация у вас?
Репликация, контроль схемы, более живое сообщество.
Есть одна микросервисная архитектура. Пара десятков микросервисов шлют друг-другу сообщения через кафку. В день набегает 10-20 млн сообщений. Для мониторинга этого вся важная информация из сообщений как есть (т.е. прямо транзакционка) перекладывается в InfluxDB (бесплатная) и заводится в графину, где уже выборки-фильтрации настраиваются.
Есть в CH то, ради чего в этой схеме следует InfluxDB заменить на CH?
Вообще для Flow-based programming много чего есть, но обычно оно либо монструозное и тащить в проект страшно, либо минималистичное и тащить в проект бесполезно.
И «символьная логика» немного режет слух
Кажется что в logstash уже всё сделали :)