Может быть мы о разном. Давайте разбираться…
Все серивисы подписаны на кафку и имеют локальные копи (снэпшоты, кеши и т.д.) так как им удобно… Они могут вести свои собственные базы данных NoSQL и прочую организацию для исполнения задачи. Им не нужно совершенно прочесывать кавку.
Кавка остается "универсальной правдой" потоком событий (или фактов). Сервисы подписаны на кафку и лишь слушают изменения и актуализируют свое сотояние.
Допустим у вас 250 сервисов… я не совсем понял как они слушают и кого? Раббита? или постоянно ходят в базу данных что-бы забрать новые эвенты? Не говороя уже о не скалиремости релациональной БД не понимаю даже приемущества ДБ+раббит супротив кавки начиная с систем не помещающихся на 3 хоста
В том примере Постгри какраз второстепенен. Ничего не попадет ни в какие базы данных никаких серверов кроме как через кафку. И кафка единственнай правда остальное получается снэпшоты и кеши.
Ну самое тривиальное упращение: берем актуальный в каую-то секунду статус из базы данных и импортируем в новую ситему. Теоритичеки тривиально…
А на практике новая система может быть вовсе не понимать SQL и надо думать о трансформации и реализовывать её, причем может надо избежать даунтайм.
Далее одна система с которой мне приходится возится, несмотря на то что она достаточно легаси, построена на нескольких базах данных которые несут распределенно статус и историю. Некоторые пишут по 2 миллиона событий в день. Одна только синхронизация такого експорта/импрота в новую систему не тривиальна как мне представляется из опыта.
Вы работаете с SQL это конечно упрощает но в случае вышеупомянутой системы, было бы в нашем случае не целесобразно, потому что железо для такой SQL машины стоило бы непомерно… Да и зачем когда вся фишка вроде как в специализированых решения как кафка. Мне бы очень хотелось пощупать это ;)
Не зависимо от импорта, если я дальше думаю о вышеупомянутой системе, присутствует условие стирания событий назовем их Messages (законы просто не позволяют долго хронить определнню информацию) и в даже в новой системе эти события придется стирать, что не предусмотренно в описанном подходе в принципе если я правильно понимаю.
Я об этом же. Но это не тивирально может быть. Например если уже есть некая история.
P.S. У вас с Кафкой опыт есть? Я так понимаю именно для это-го он подходит?
Отличная статья, большое спасибо! В закладки!
Поговорить о деталях видимо может быть уместным только попробовав на практике… Пока у меня небыло подобного опыта в полном обьеме хотя писать эвенты вместа апдейта статуса уже догадывались под разным причинам ;)
Интересует такой момент. В описаной вамеи связке Event Sourcing + CORS события имеет смысл класть в какое-то хранилище (Event Bus).
Вы вначале статьи написали о Кафке и похоже именно на неё намекаете, (я именно в таком контексте слышал о кафке). Могли бы вы побольше пролить свет о роли кафки или другого хранилища?
И правильно ли я понял что при наличии надежного хранилища событий, в идеале его можно сделать единственным и эксклюзивным хранилищем всей истории событий?
Даный подход открывает невероятное возможности в динамике конзумирующих сервисов в таком случае, что очень интересно.
П.С.
А при переходе на таку модель с чего-то исторического, надобно существующий статус как-то перевести в начальные события, что-бы отчего-то оталкиватся, без потери информации и возможнои истории, что может быть тоже не тривиально совершенно..
А родной aws cli сильно тормозит? Через него можно получить логи в json формате, на ходу можно pipe-ить в читалку json-a и оттуда уже пайпить в slit либо куда душа пожелает
Месяца 3 назад бегло пробовал. Да тормозило сильно…
Но можно посерьезнее постмотреть и хитро пайпить… это верно.
papertrail
да именно к нему присмариваюсь в часном проекте… Но на фирме там разные сложные констрейны с банковскими клиентами. так просто уйти в следующий клауд сервис да еще с логами не реально пока ;))
Простите я бы хотел попробовать ваш тул. Но пока мы логим в CloudWatch только и смотрим там ( Хватает, но те кто привыкли к копаться в логах недовольны...)
Не посоветуете что-то не тормозящее что может выкичивать из CloudWatch напрямую или переброс в S3 это стандартных подход к вопросу? Если да то как это делают?
которая предоставляет в пользовательском окружении следующие файлы:
/proc/cpuinfo
список CPU
/proc/diskstats
статистика I/O в контейнере
/proc/meminfo
доступная контейнеру память и статистика по использованию
/proc/stat
статистика по доступным CPU
/proc/swaps
статистика по swap
/proc/uptime
uptime контейнера.
Простите а виртуальная машина явы именно на них смотрит при планировании ресурсов?
Вообще то с философией юникса ассоциируют именно эти три вещи и именно в этом порядке.
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
И это действительно могущественный вывод на опыте создания програмных систем. Который постоянно вплывает в разные контекстах и эпохах. Сейчас к примеру это микросервисы.
Помоему если просто уяснить какие проблемы решают виртульные машины и какие проблемы решают контейнеры не останется вопросов и не надо будет писать такие странные простыни…
Контейнере в виртуалках самое распространенное явление. Docker vs. VM
но насколько — практически невозможно измерить, зависит от решаемых задач и самого программиста.
В том то и дело…
Eclipse вполне можно без мыши работать как и в IDEA. Но на практике редко встретишь тех кто может это полностью без мыши в одной из них…
1,5 года eclipseпод xubuntu. Наблюдаю небольшой провал в скорости работы (иногда небольшие задержки) по сравнению с виндовой версией.
Но в целом вполне… Проблем с явой никаких которые можно было свести к eclipse. Но возможно ноут надо будет обновить — ему лет 7, хотя пока пофиг.
Может быть мы о разном. Давайте разбираться…
Все серивисы подписаны на кафку и имеют локальные копи (снэпшоты, кеши и т.д.) так как им удобно… Они могут вести свои собственные базы данных NoSQL и прочую организацию для исполнения задачи. Им не нужно совершенно прочесывать кавку.
Кавка остается "универсальной правдой" потоком событий (или фактов). Сервисы подписаны на кафку и лишь слушают изменения и актуализируют свое сотояние.
Допустим у вас 250 сервисов… я не совсем понял как они слушают и кого? Раббита? или постоянно ходят в базу данных что-бы забрать новые эвенты? Не говороя уже о не скалиремости релациональной БД не понимаю даже приемущества ДБ+раббит супротив кавки начиная с систем не помещающихся на 3 хоста
В том примере Постгри какраз второстепенен. Ничего не попадет ни в какие базы данных никаких серверов кроме как через кафку. И кафка единственнай правда остальное получается снэпшоты и кеши.
Кафка подходит. Хотя на мой вкус немного радикальное решение но этим то и интересно.
Вот тут очень хорошо описано с поянениями в каментах:
Ну самое тривиальное упращение: берем актуальный в каую-то секунду статус из базы данных и импортируем в новую ситему. Теоритичеки тривиально…
А на практике новая система может быть вовсе не понимать SQL и надо думать о трансформации и реализовывать её, причем может надо избежать даунтайм.
Далее одна система с которой мне приходится возится, несмотря на то что она достаточно легаси, построена на нескольких базах данных которые несут распределенно статус и историю. Некоторые пишут по 2 миллиона событий в день. Одна только синхронизация такого експорта/импрота в новую систему не тривиальна как мне представляется из опыта.
Вы работаете с SQL это конечно упрощает но в случае вышеупомянутой системы, было бы в нашем случае не целесобразно, потому что железо для такой SQL машины стоило бы непомерно… Да и зачем когда вся фишка вроде как в специализированых решения как кафка. Мне бы очень хотелось пощупать это ;)
Не зависимо от импорта, если я дальше думаю о вышеупомянутой системе, присутствует условие стирания событий назовем их Messages (законы просто не позволяют долго хронить определнню информацию) и в даже в новой системе эти события придется стирать, что не предусмотренно в описанном подходе в принципе если я правильно понимаю.
Я об этом же. Но это не тивирально может быть. Например если уже есть некая история.
P.S. У вас с Кафкой опыт есть? Я так понимаю именно для это-го он подходит?
Отличная статья, большое спасибо! В закладки!
Поговорить о деталях видимо может быть уместным только попробовав на практике… Пока у меня небыло подобного опыта в полном обьеме хотя писать эвенты вместа апдейта статуса уже догадывались под разным причинам ;)
Интересует такой момент. В описаной вамеи связке Event Sourcing + CORS события имеет смысл класть в какое-то хранилище (Event Bus).
Вы вначале статьи написали о Кафке и похоже именно на неё намекаете, (я именно в таком контексте слышал о кафке). Могли бы вы побольше пролить свет о роли кафки или другого хранилища?
И правильно ли я понял что при наличии надежного хранилища событий, в идеале его можно сделать единственным и эксклюзивным хранилищем всей истории событий?
Даный подход открывает невероятное возможности в динамике конзумирующих сервисов в таком случае, что очень интересно.
П.С.
А при переходе на таку модель с чего-то исторического, надобно существующий статус как-то перевести в начальные события, что-бы отчего-то оталкиватся, без потери информации и возможнои истории, что может быть тоже не тривиально совершенно..
Месяца 3 назад бегло пробовал. Да тормозило сильно…
Но можно посерьезнее постмотреть и хитро пайпить… это верно.
да именно к нему присмариваюсь в часном проекте… Но на фирме там разные сложные констрейны с банковскими клиентами. так просто уйти в следующий клауд сервис да еще с логами не реально пока ;))
Не посоветуете что-то не тормозящее что может выкичивать из CloudWatch напрямую или переброс в S3 это стандартных подход к вопросу? Если да то как это делают?
Простите а виртуальная машина явы именно на них смотрит при планировании ресурсов?
У вас это тоже так ;)
Это закон мура… И я в нем не сомниваюсь после >12 лет проф. деятельности в различных ролях и фирмах
И это действительно могущественный вывод на опыте создания програмных систем. Который постоянно вплывает в разные контекстах и эпохах. Сейчас к примеру это микросервисы.
Контейнере в виртуалках самое распространенное явление.
Docker vs. VM
И похоже даже просто docker в swarm mode это в на базовом но в большинстве случаев достаточном уровне уже тоже научился…
В том то и дело…
Eclipse вполне можно без мыши работать как и в IDEA. Но на практике редко встретишь тех кто может это полностью без мыши в одной из них…
Но в целом вполне… Проблем с явой никаких которые можно было свести к eclipse. Но возможно ноут надо будет обновить — ему лет 7, хотя пока пофиг.