Базовая концепция архитектуры

011 012

Требовалось создать платформу с динамической структурой данных, 013 которая, к тому же, будет изменяться в процессе эксплуатации, 014 притом на "горячую", т.е. нужна возможность изменять структуру 015 данных во время работы с этими данными, т.е. 016 добавления/изменения/удаления оных. И, при этом, обеспечивать 017 высокую нагрузку.

018 019

Логически платформа представляет набор бизнес-объектов (БО), у 020 которых есть поля различных типов. У каждого бизнес-объекта можно 021 создавать инстанции - данные. Значения полей инстанций в 022 последствии можно менять. Инстанции могут быть помечены как:

023 024

1) Актуальные - первичное состояние после создания. В этом 025 состоянии инстанция находиться при работе с ней.

026 027

2) Удалённые - такие инстанции считаются удалёнными - они не 028 участвуют в работе системы. Так же есть возможность удалить 029 физически инстанции.

030 031

3) Архивные - давно не используемые инстанции, ушедшие в 032 архив.

033 034

4) Тестовые - инстанции, которые используют для тестирования 035 системы.

036 037

Для этого были выбраны системы управления баз данных, которые 038 поддерживают масштабирование "в ширину". А именно:

039 040

1) MongoDB

041 042

2) Apache Kafka

043 044

3) ElasticSearch

045 046

4) PostgreSQL

047 048

5) Apache Zookeeper

049 050

MongoDB - главное оперативное хранилище

051 052

Главной базой данных является MongoDB. В ней хранятся все данные 053 системы в оперативном режиме.

054 055

В оперативном режиме - это значит, что, например, если у клиента 056 фамилия поменялась с "Иванова" на "Сидорова", то в MongoDB остаётся 057 только "Сидорова", а "Иванова" стирается бесследно.

058 059

Более того, база данных MongoDB используется только в режиме 060 Key-Value-Storage, это обозначает, что платформа в неё делает 061 запросы только по идентификаторам с ожиданием единичного документа 062 по этому идентификатору.

063 064

На платформе часто требуется получить списки - использовать для 065 этого MongoDB запрещено, чтобы не нагружать её. Для этого 066 используется ElasticSearch.

067 068

ElasticSearch - получение информации 069 списками

070 071

ElasticSearch используется для получения оперативной информации 072 в виде списков, которые отфильтрованы и отсортированы по желанию 073 пользователя в режиме постраничной загрузки.

074 075

В ElasticSearch тоже хранится только оперативная информация.

076 077

Для того чтобы синхронизировать данные в ElasticSearch и MongoDB 078 используется ApacheKafka.

079 080

Apache Kafka - синхронизация данных + 081 хранение истории изменений данных

082 083

Apache Kafka на платформе MyBPM используется для двух целей:

084 085

1) Хранение исторической информации;

086 087

2) Синхронизация данных между различными компонентами 088 системы.

089 090

Все изменения в данных системы сбрасывается в Kafka в виде 091 дельты данных. В дельте данных содержится только та информация, 092 которая изменилась в данный момент в системе. А именно, например, 093 если у клиента сорок полей, а изменилось только фамилия, то в 094 дельту попадёт только эта фамилия, при том, только новое значение 095 этого поля. Так же в дельте будут координаты того, что изменилось - 096 идентификатор инстанции. А также кто и когда это изменил. Резюмируя 097 сказанное, в дельте содержится следующая информацию:

098 099

1) Новые значения полей, которые изменились

100 101

2) Координаты того, что изменилось: идентификатор инстанции 102 бизнес-объекта + идентификатор самого бизнес-объекта

103 104

3) Идентификатор пользователя, кто сделал это изменение

105 106

4) Дата и время этого изменения

107 108

Дальше Kafka-Consumer-ы подгружают эти изменения и применяют их 109 для соответствующих компонентов системы. Например, соответствующий 110 Consumer обновляет данные в ElasticSearch тем самым синхронизируя 111 их с оригиналом в MongoDB.

112 113

Apache Kafka - как база исторических 114 данных

115 116

К Apache Kafka следует относиться как к базе данных, в которой 117 храниться история всех изменений системы.

118 119

На платформе Apache Kafka организована динамическая система 120 получения отчётов.

121 122

Вначале пользователь подготавливает структуру отчёта и сохраняет 123 её в БД MongoDB. Далее платформа создаёт в PostgreSQL таблицы для 124 получения данного отчёта, но эти таблицы пустые. Так как в Apache 125 Kafka храниться вся история изменений, то можно пройтись по ним и 126 подготовить данные в этих таблицах, что и делается. Эти таблицы 127 заполняются и отчёт готов для эксплуатации. Далее Kafka-Consumer 128 отслеживает дальнейшие изменения и держит таблицы в актуальном 129 состоянии.

130 131

Для того чтобы данная функциональность работала, необходимо 132 исторически данные держать постоянно в Apache Kafka и не стирать 133 их. В Apache Kafka для это есть весь необходимый инструментарий - 134 репликация, партиции и прочее доступные из коробки.

135 136

Следует отметить, что платформа MyBPM позволяет разделять данные 137 инстанций БО на разные Kafka Topic-и. Это позволяет зачищать те БО, 138 которые сильно растут в размере. При этом по ним теряется 139 историческая информация. А это означает, что по ним не должно быть 140 отчётов с исторической информацией.

141 142

Предназначение PostgreSQL

143 144

PostgreSQL используется для решения сложных логических задач. 145 Например, в PostgreSQL хранятся ловушки событий, которые 146 срабатывают, если наступает заранее ожидаемое событие, например 147 ожидание сохранение определённой инстанции БО, чтобы запустился 148 конкретный скрипт в бизнес-процессе.

149 150

Предназначение Apache Zookeeper

151 152

В Apache Zookeeper платформа MyBPM хранить всю конфигурационную 153 информацию - параметры доступа, таймауты, размеры буферов и 154 прочее.

155 156

В дальнейшем планируется перенести всю эту конфигурацию в БД 157 MongoDB и управлять ей через интерфейс.

158