Invision & Mifka
Mifka
Я тут перечитывала легенду о фениксе и подумала, может, это поможет нам по-новому взглянуть на проектирование надёжных программных систем.
Invision
Привет! Знаешь, метафора с фениксом – просто идеально подходит для систем, которые умеют сами восстанавливаться и перестраиваться после сбоев. Представь себе ядро, которое может “возродиться” в новом контейнере или кластере, когда один из компонентов выходит из строя, и при этом не теряет данные. Главное – сначала проектировать с учетом плавного ухудшения работы, а потом уже сделать восстановление автоматическим. Так вся система сможет возродиться из пепла намного быстрее, чем если бы пришлось все вручную исправлять. С какого аспекта дизайна начнем разбираться?
Mifka
Я бы начала со слоя состояния – представь себе уголек, от которого возрождается феникс. Если мы сможем добиться автоматического «перерождения» состояния, остальная система просто оживет. Давай набросаем, как отделить состояние от исполняемого кода, может, через логи на основе обмена информацией, которые переживут гибель контейнера. Как тебе такая идея?
Invision
Отличный поворот! Давай будем рассматривать состояние как неизменяемый журнал, в который можно только добавлять записи, и который хранится в отдельном, реплицированном хранилище. Каждый узел подписывается на канал обмена информацией, получает последние записи и может восстановить свою локальную копию, воспроизводя их. Когда контейнер умирает, его реплика берет последнюю согласованную копию, а затем получает недостающие изменения из канала обмена информацией. Мы сохраняем код приложения без сохранения состояния, просто считывая данные из журнала, поэтому «возрождение» - это просто повторное подключение к тому же потоку. Самое сложное будет обеспечить, чтобы протокол обмена информацией гарантировал порядок и справлялся с перераспределением без потери записей. Готова проработать точную модель данных?
Mifka
Звучит как раз то, что я искала. Но нам нужна структура, которая будет учитывать тип события, монотонно возрастающую последовательность и хеш предыдущей записи – чтобы цепочка была защищена от изменений. Давай еще добавим небольшой блок метаданных с версией схемы приложения, чтобы новые узлы могли понимать старые события. Я набросаю формат JSON, потом подкорректируем, чтобы было компактно. Начинаем?
Invision
Конечно, давай сделаем это лаконично. Я бы начала, наверное, так:
{
"seq": 12345,
"type": "update",
"prevHash": "abcdef…",
"schemaVer": 2,
"payload": { … },
"meta": { … }
}
"Seq" – это монотонный счётчик, "type" обозначает событие, "prevHash" связывает его в цепочку, "schemaVer" говорит узлу, как расшифровать "payload", а "meta" содержит небольшой фрагмент – например, временную метку или ID узла. Это даст нам короткий, защищённый от изменений след, при этом позволяя новым узлам быстро подключаться. Как тебе такая идея?
Mifka
Это почти поэтично, знаешь... достаточно формальности, чтобы держать всё на верном пути, но при этом всё остаётся рабочим. Может, стоит заменить тип поля на перечисление, чтобы ускорить разбор, и пусть метаданные хранят примерный возраст в миллисекундах – на случай, если вдруг рассинхронизируемся. В остальном – отличная основа для "феникса".
Invision
Звучит надежно—перечисление позволяет легко разбирать данные, а возраст в миллисекунду даёт нам быстрый сигнал для синхронизации. Может, стоит добавить контрольную сумму к полезной нагрузке, на всякий случай, если данные повредятся при передаче. В остальном, думаю, мы уловили суть "феникса". Давай прототипируем и посмотрим, как будет себя вести уровень распространения информации в условиях постоянных изменений.
Mifka
Я добавлю поле контрольной суммы и настрою тестовую среду. Посмотрим, как там забурлит сплетня, когда узлы будут подключаться и отключаться, и проверим, выдержит ли цепочка. Готова увидеть, как всё возродится?