Архитектура системы. 
Разработка сервиса агрегации открытых данных и данных из социальных сетей

При построении программного обеспечения крайне важно выбрать правильную архитектуру. От того, какая будет выбрана архитектура, зависит не только то, как компоненты программы будут взаимодействовать между собой, как будут распределяться потоки данных, но и насколько надежная и отказоустойчивая будет система в целом. Классическим решением среди больших программных комплексов в индустрии является построение единого монолита. Другими словами, программа поставляется как единый скомпилированный модуль, который достаточно запустить в нужной среде для работы программы. Достоинства такой архитектуры обуславливают популярность среди поставщиков программного обеспечения индустрии. К ним можно отнести единую доменную модель, то есть все типы объектов будут написаны только один раз, что влечет за собой отсутствие дубликатов кода, исключает возможность несоответствия версий и повторное использование кода. Наряду с этим, как правило, используется единая шина данных для передачи информации между частями программы. Поскольку система состоит только из одного модуля, это значительно упрощает взаимодействие между ними, а также снижает время, затраченное на передачу данных. Для приложений, к которым представлены жесткие требования по скорости передачи данных, это крайне важно, так как большие объемы информации могут передаваться по сети с ограниченной скоростью. Получается, что для таких систем скорость обмена данными является узким местом в построении архитектуры. Создание приложения как единого модуля может помочь избавиться от подобной проблемы[16].

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

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

Существует и другой подход к построению программного обеспечения. Это, так называемая, микросервисная архитектура[11]. Ее характерной особенностью является тот факт, что каждая логическая часть системы должна быть выполнена в виде отдельного программного модуля. Все модули представляют собой исполняемый файл или архив, который можно запустить независимо от других частей системы. Основная идея микросервисной архитектуры состоит в том, что каждый отдельный модуль должен выполнять одну единственную задачу. Когда программа отвечает только за одну задачу, гораздо выше вероятность того, что она выполняет ее хорошо. Такой подход известен еще с публикации философии UNIX, который гласил примерно схожую идею. Таким образом, система состоит из нескольких независимых модулей, которые должны взаимодействовать между собой. Здесь могут быть использованы любые протоколы передачи данных, которые лучше всего подходят под определенные требования. Также могут использоваться любые шины данных для обмена сообщениями между модулями, поскольку выбор не ограничен целостностью системы. Из этого всего можно выделить следующие преимущества микросервисной архитектуры:

• · Всегда проще разрабатывать небольшой сервис, который ответственен за решение одной задачи. Такой модуль легко покрывать тестами и поддерживать;
• · Возможность использовать любые протоколы передачи данных между сервисами системы;
• · Поскольку при такой архитектуре каждый модуль является независимым, существует возможность распараллеливания разработки сервисов между разработчиками;
• · Небольшие изолированные сервисы легко масштабируются, таким образом можно создать распределенную систему из отдельных микросервисов;
• · Для каждого сервиса можно выбирать любую технологию и язык программирования, которая лучше всего подходит под решение конкретной задачи;
• · Некоторые микросервисы, такие как веб-серверы, нет необходимости разрабатывать самому, поскольку они уже существуют в открытом доступе;
• · При обновлении отдельных сервисов не возникает проблем с единой точкой отказа системы, остальные части работают бесперебойно.

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