Создание микросервисов

И вот здесь вы можете возразить: «Сэм, ты же говорил, что лучше не использовать программы, интегрированные посредством базы данных!» По крайней мере, я надеюсь на такое ваше замечание, учитывая настойчивость, с которой я высказывал возражения по данному вопросу! Этот подход при надлежащей реализации является весьма интересным исключением, в котором недостатки связанности более чем компенсированы легкостью создания отчетов.

Для начала программы перекачки данных должны создаваться и управляться той же командой, которая управляет сервисом. Она должна быть такой же простой, как программа командной строки, запускаемая с помощью Cron. Эта программа должна довольно много знать и о внутренней базе данных для сервиса, и о схеме для создания отчетов. Задача перекачки данных заключается в отображении одного на другое. Мы постараемся сократить проблемы со связанностью за счет того, что перекачкой и сервисом будет управлять одна и та же команда. Фактически я хочу предложить, чтобы управление версиями этих средств велось совместно и чтобы сборки программы перекачки данных создавались в виде дополнительного побочного продукта и являлись частью сборки самого сервиса в предположении, что при развертывании одной из этих сборок происходит развертывание и другой сборки. Поскольку об их совместном развертывании и о недопустимости открытия доступа к схеме где-либо за пределами команды сервиса мы сделали явное заявление, многие из традиционных проблем интеграции на основе использования баз данных значительно смягчаются.

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

Рис. 5.14. Использование материализованных представлений для создания единой монолитной схемы создания отчетов

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

Альтернативные направления

В одном из проектов с моим участием мы использовали серии программ перекачки данных для заполнения JSON-файлов в AWS S3, эффективно применяя S3 для маскировки огромной ярмарки данных! Этот подход работал весьма исправно до тех пор, пока нам не потребовалось расширить данное решение, и на момент написания книги мы искали, чем заменить программы перекачки, чтобы вместо этого заполнить куб, который мог быть интегрирован со стандартными средствами создания отчетов, такими как Excel и Tableau.

Перекачка данных на основе событий

В главе 4 упоминалась идея микросервисов, выдающих события на основе изменения состояния тех объектов, которыми они управляли. Например, наш клиентский сервис может выдавать событие при создании, или обновлении, или удалении клиента. Для микросервисов, выставляющих напоказ выдачу событий, имеется вариант написания своего подписчика на события, который перекачивает данные в отчетную базу данных (рис. 5.15).

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

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