Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Навык разработки сервис-ориентированной системы

Anna | 31.05.2014 | нет комментариев

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

До тех пор, пока у нас не было большого числа всевозможных данных, мы не имели каких-то нестандартных задач и все решения были довольно откровенными. Но план разрастался, и размер собираемой информации, правда вначале и не дюже стремительно, но все же возрастал. Росла и кодовая база. И через некоторое время мы поняли крайне грустный факт — из-за каждых костылей и стремительно-фиксов мы нарушили примерно все допустимые тезисы проектирования. И если вначале организация кода была не столь главна, то со временем стало ясно, что без классного рефакторинга вдалеке мы не уедем.

Позже обсуждений и размышлений было решено, что для наших целей зодчество “парсилки” интернетов в первую очередь должна быть сервис-ориентированной(SOA). Дальше мы отталкивались от этого подхода и выделили три осноных части грядущей системы, отвечающих за следующие задачи:

  1. Приобретение содержимого страниц, данных из разных сервисов через API, данных из структурированных файлов
  2. Классификация полученной информации
  3. Обзор статистики и создание рекомендаций

В итоге такого распределения обязаны были получиться три самостоятельных обслуживания: Fetch Service, Parse Service и Analyze Service

* Тут и дальше буду применять некоторые англоязычные наименования для большего комфорта воспринятия и краткости

Дальше встал вопрос о том, как эти сервисы будут общаться друг с ином. Определяя всеобщий механизм было решено применять доктрину конвейерной обработки(pipeline). Довольно внятный и примитивный подход, когда необходимо ступенчато обработать какую-либо информацию, передавая её от одного узла к иному. В качестве коммуникационной шины был выбран механизм очередей на базе RabbitMQ.

image

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

Компоненты сервисов и спецтехнологии

Давайте немножко побеседуем о спецтехнологиях, которые применяются внутри всякого отдельного обслуживания. В данной статье я в основном буду описывать то как работает Fetch Service. Впрочем остальные сервисы имеют аналогичную архитектуру. Ниже опишу всеобщие моменты, а вернее основные компоненты. Каждого их четыре.

1-й — это модуль обработки данных(proccessing module), тот, что содержит всю основну логику работы с данными. Представляет из себя комплект воркеров, которые исполняют задачи. И заказчиков, которые эти задачи создают. Тут применяется Gearman в качестве сервера задач и соответственно его API. Сами воркеры и заказчики являются отдельными процессами, которые контролируются с поддержкой Supervisord.

Дальнейший компонент — хранилище итогов. Которое является базой данных в MongoDB. В основном данные извлекаются из веб-страниц, либо через разные API, возвращающие JSON. И MongoDB довольно комфортна для хранения такого вида информации. Помимо того, конструкция итогов может меняться, могут возникать новые метрики и тд. И в данном случае мы можем легко вносить метаморфозы в конструкцию документов.

И наконец, 3-й компонент системы — очереди. Есть два типа очередей. Первые занимаются тем, что служат для передачи запросов к сервисам от других сервисов либо же от внешних заказчиков(не путать с Gearman-заказчиками). Такие очереди именуются как Request Queues. В случае с упомянутым ранее сервисом приобретения контента (Fetch Service) в очередь такого типа поступает JSON строка. Она содержит URL требуемой страницы либо параметры для запроса к стороннему API.

2-й тип очередей — это очереди уведомлений(Notifications Queues). В очередь такого типа сервисы помещают информацию о запросах, которые были обработаны и итог может быть получен из хранилища. Таким образом реализуется асинхронность выполнения запросов на приобретение, обработку и обзор данных.

В качестве брокера сообщений был выбран RabbitMQ. Это отменное решение, работает отменно, хоть и с некоторыми заморочками.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB