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

Кроме того, если сохранять информацию о том, какие события уже были обработаны, мы сможем просто обработать новое событие сразу же по его поступлении, предполагая при этом, что старые события уже были отображены на систему создания отчетов. Это означает, что внедрение будет более эффективным, поскольку нам нужно лишь отправить различия. Аналогичные действия можно выполнить и с программой перекачки данных, но управлять этим придется самостоятельно, принимая во внимание абсолютно временный характер потока событий (x случается с меткой времени y), что существенно нам поможет.

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

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

Перекачка данных на основе систем резервного копирования

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

Компания Netflix решила использовать базу данных Cassandra в качестве стандартного резервного хранилища своих многочисленных сервисов. Netflix потратила немало времени на создание средств, облегчающих работу с Cassandra, многими из которых компания делится с остальным миром посредством ряда проектов с открытым кодом. Конечно же, необходимость резервного копирования тех данных, которые хранятся в Netflix, вполне очевидна. Для резервного копирования данных, хранящихся в базе данных Cassandra, стандартным подходом является создание копий поддерживающих ее файлов и сохранение их в безопасном месте. Netflix сохраняет эти файлы, известные как SSTables, в принадлежащем компании Amazon хранилище объектов S3, твердо гарантирущем долговечность хранения данных.

Netflix нуждается в отчетах по всем этим данным, но с учетом задействованных масштабов решить эту задачу нелегко. В выбранном компанией подходе применяется среда Hadoop, которая использует резервные копии SSTable в качестве источника для своих заданий. Напоследок компания Netflix завершила реализацию конвейера, способного с использованием рассматриваемого подхода обрабатывать большой объем данных, которые она затем превратила в проект с открытым кодом под названием Aegisthus. Но как и при использовании программ перекачки данных, при применении этой модели мы по-прежнему сталкиваемся с наличием связанности с целевой схемой составления отчетов (или с целевой системой).

Возможно, применение аналогичного подхода, то есть систем отображения, создающих резервные копии, позволит выработать вполне работоспособное решение и в других контекстах. А если вы уже используете базу данных Cassandra, то компания Netflix сделала основную часть работы за вас!

Переход к реальности

Многие из ранее выделенных моделей представляют собой различные способы получения большого объема данных из множества различных мест и помещения их в одно место. Но неужели идея создания всех отчетов из одного места по-прежнему имеет право на существование? У нас имеются отчетные данные, выводимые на панель управления, разного рода предупреждения, финансовые отчеты, аналитика, связанная с пользовательской активностью, — и все это предъявляет различные требования к точности и своевременности, что может найти выражение в выборе различных технических приемов для их получения. В соответствии с уточнениями, которые даются в главе 8, мы перемещаем все больше и больше данных по направлению к универсальным системам обработки событий, способным направлять данные в несколько разных мест в зависимости от наших потребностей.

Цена внесения изменений