В этой статье основное внимание будет уделено созданию системы аудита данных, которая является высокодоступной, горизонтально масштабируемой, отказоустойчивой, работает изолированно. Любой организации когда-нибудь понадобится такая система для управления изменениями данных, чтобы можно было легко отследить, кто изменил данные, каковы были существующие данные, что было изменено, например. у вас есть распределенная структура сканирования данных, в которой вы можете настроить конфигурацию сайта, и она используется внутри компании, конфигурация, связанная с продуктами в электронной коммерции, конфигурация прибыли / прибыли на уровне продукта и т. д. Все эти случаи очень важны, и мы должны быть в состоянии для отслеживания этих изменений в будущем, если что-то пойдет не так в вашей системе / или в целях аудита.

Итак, давайте определим здесь основную постановку проблемы.

1. Нам необходимо разработать систему аудита данных, которая будет высокодоступной, мы ни в коем случае не должны терять никаких изменений данных.

2. Если что-то пойдет не так в каком-либо одном компоненте, система все равно сможет выполнять то, что она делает. Допустим, любой узел хранилища данных или службы аудита выходит из строя, но мы по-прежнему хотим, чтобы все работало должным образом.

3. Мы должны иметь возможность получать доступ к данным аудита эффективным и быстрым способом с минимальной задержкой и временем отклика.

Итак, давайте начнем базовый дизайн, помня о приведенной выше постановке проблемы. Есть последовательные шаги, которые мы можем выполнить, чтобы решить данную проблему.

  1. Как узнать разницу между старым и новым объектом данных?

Есть несколько способов сделать это. Предположим, мы собираемся использовать общую библиотеку apache http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/Diff.html, чтобы увидеть разницу. Это позволяет нам определять поля, которые мы хотим проверять, вместо того, чтобы получать разницу для всех атрибутов данного объекта. Следовательно, здесь легко получить разницу / изменения данных для любого данного взаимодействия сущностей данных.

2. Следует ли нам сохранить его на уровне хранилища данных микросервисов или создать отдельный централизованный сервис для его обработки?

Здесь мы могли бы определить общую модель данных для каждой микрослужбы, преобразовать разницу в модель данных аудита и сохранить ее в базах данных. Это легко сделать, но влечет за собой небольшие последствия: мы нарушаем принцип DRY (не повторяйтесь). Мы не должны писать логику преобразования и сохранения для каждой службы, так как это трудное дублирование работы. Если в будущем мы поймем, что нам нужно что-то изменить в логике, придется писать это в нескольких местах. Поэтому всякий раз, когда мы видим, что пишем дубликаты, отделяйте эту часть. В будущем эту часть будет очень легко понять, расширить, масштабировать и управлять ею. Поэтому мы можем построить вокруг него отдельный микросервис, и он будет отвечать за управление всеми возможностями аудита.

3. Как мы должны определить взаимодействие между другими микросервисами и аудиторской службой?

Это другой вопрос, должно ли это быть синхронное или асинхронное общение. Если мы попытаемся сделать это синхронно, возникнет несколько проблем. Это может увеличить общее время отклика при взаимодействии с данными в других микросервисах, что совершенно неприемлемо. Как мы уже говорили ранее, мы ни в коем случае не можем позволить себе потерять какие-либо данные аудита. Так что, если это синхронизирующая связь, и система аудита не работает / или имеет некоторую проблему, мы застряли здесь, это также повлияет на вышестоящий сервис. Мы можем сделать их слабо связанными, поскольку они предназначены для выполнения двух разных вещей изолированно, не влияя друг на друга. Мы можем использовать асинхронное общение. Мы можем передать эти данные аудита в тему kafka, как только мы отправим их в kafka, kafka обеспечит доставку события аудита данных независимо от доступности системы аудита. Если система аудита недоступна, она обязательно передаст это событие в службу аудита, как только оно появится. Мы ни в коем случае не потеряем аудит данных. Есть еще одно преимущество использования этого подхода: мы можем создать несколько разделов в зависимости от требуемой пропускной способности после начального тестирования, здесь легко масштабировать без изменения кода, поскольку это горизонтально масштабируемая система. Нам нужно убедиться, что мы масштабируем наше хранилище данных аудита вместе с ним для операций чтения / записи.

4. Как мы должны обрабатывать эти данные в службе аудита данных?

Это еще один интересный вопрос. Поскольку здесь нам необходимо поддерживать чтение из огромных данных, было бы немного сложно добиться этого с помощью одной только базы данных, поскольку данные будут расти слишком быстро, может быть трудно получить чтение с требуемой производительностью с некоторыми критериями / фильтрами поиска. Итак, мы можем подумать об использовании эластичного поиска или solr здесь. Предположим, мы используем эластичный поиск для хранения этих данных. Здесь мы будем запускать несколько узлов службы аудита на основе того, что у нас нет разделов на уровне kafka для темы аудита, эти узлы будут действовать как потребители в группе потребителей. Это нам очень поможет с точки зрения масштабирования в дальнейшем, поскольку оно построено эластичным образом. Как только мы получим это событие на уровне службы аудита, мы можем запустить базовую проверку, сохранить его в первичном хранилище данных, например: mongodb (с шардингом или перейти к записи тяжелых баз данных, например: cassandra, Dynamo, эта система будет писать тяжелую систему) , и проиндексируйте эти данные как эластичные. Не рекомендуется использовать хранилище данных поиска в качестве основного источника истины, поэтому мы сохраняем mongodb в качестве основного источника данных, а затем выполняем операцию обновления на эластичном сервере. Поскольку объем данных будет расти слишком рано, мы должны использовать n шардов, мы можем получить это число после первоначального расследования.

5. Как мне открыть интерфейс чтения для данных аудита?

Теперь у нас есть данные аудита, хранящиеся в базе данных, и на уровне эластичного поиска, мы можем создать api, который принимает параметры / фильтры поиска и соответственно получает данные аудита. С эластичным поиском это сделать очень просто. Мы можем формировать запрос динамически, разговаривать с эластичным и получать необходимые данные. Сделать это с хорошей производительностью будет очень легко, ведь у нас уже есть базовые вещи в службе аудита. Это единый интерфейс для операций чтения из службы аудита. Мы также можем следовать шаблону CQRS (разделение ответственности за запросы команд), чтобы у нас были отдельные задачи чтения и записи, и оба могут работать отдельно, поскольку мы уже разделили наши хранилища данных для чтения / записи здесь, мы можем легко расширять, масштабировать и управлять ими.

6. Что делать, если службе данных не удалось отправить событие данных аудита в kafka?

Это очень редко, но, поскольку мы говорим о том, чтобы не потерять данные любой ценой, можете подумать об этом варианте использования. Мы можем сделать небольшое изменение, чтобы справиться с этим на уровне службы данных. Как только мы найдем данные аудита, сохраните их в базе данных этой службы данных. А затем передайте его в тему аудита kafka и очистите его из базы данных. Если что-то пойдет не так с отправкой данных аудита в kafka. У нас будут хранилища сбоев в базе данных, мы можем часто запускать планировщик, который будет читать данные из таблицы данных сбоев и пытаться их повторно опубликовать.

7. Как внешний мир / панель управления / пользовательский интерфейс увидят эти данные?

Мы можем настроить шлюз API для взаимодействия с этой конечной точкой чтения API, а затем он может взаимодействовать со службой аудита. Таким образом, пользовательский интерфейс будет разговаривать со шлюзом, который извлекает эти данные из системы аудита и передает их обратно.

8. Когда нужно архивировать данные аудита?

Очень важно иметь эту функцию в нашей системе, поскольку объем данных будет расти слишком быстро, а хранение данных связано с расходами. Это полностью зависит от бизнес-сценария использования. Мы можем обсудить с бизнесом и придумать какой-то срок. Как только мы пересечем этот срок, нам нужно заархивировать данные из обоих хранилищ данных, например: я хочу поддерживать данные аудита только за последние 3 года, у нас может быть механизм истечения срока действия, размещенный на уровне документа аудита данных, который будет архивировать данные из обоих хранилищ. хранилища данных.

Итак, у нас есть готовая базовая система аудита данных, которая позаботится о базовых вещах. Могут быть и другие области улучшения, которые мы могли бы добавить сюда, но я попытался выделить базовые вещи, которым мы, по крайней мере, можем следовать при разработке аналогичной системы, и мы можем всегда расширяйтесь по мере продвижения вперед.

Спасибо, что прочитали статью, я люблю обсуждать проектирование системы, распределенную систему. Вы можете обратиться ко мне за любыми предложениями / улучшениями. Буду продолжать писать на подобные темы в будущем.

Спасибо.

[email protected]

Linkedin: https://www.linkedin.com/in/bhagwati-malav-684b6a5a/