Мы запускаем своего рода сервисную службу портфолио с API (CakePHP, MySQL) и отдельными приложениями внешнего интерфейса (javascript), которые с ним связаны. API (назовем его Content API) довольно монолитен в том смысле, что он имеет дело с аутентификацией, хранением и извлечением всего контента, рассылкой электронных писем, в основном всего на стороне сервера. У нас небольшая команда, и наш сервис относительно небольшой (тысячи пользователей). В настоящее время мы работаем с одним экземпляром Amazon EC2, но в ближайшем будущем планируем масштабироваться.
Мы собираемся создать аналитическую систему, которая будет состоять из внешнего интерфейса, показывающего причудливые графики, и API, хранящего события и предоставляющего данные для вышеупомянутых графиков.
Теперь возникла дилемма, с которой я борюсь: создать отдельный API-интерфейс Google Analytics или интегрировать его функциональность с существующим API-интерфейсом для контента?
Я читал о преимуществах микросервисов, и поскольку аналитика - это такая отличительная особенность, я склонен думать, что она заслуживает наличия своего собственного API. Однако ...
Данные, с которыми мы имеем дело, не слишком сумасшедшие. Мы говорим о ГБ, а не о ТБ. Кроме того, аналитические данные довольно структурированы (тип события, datetime, user_id, content_id и тому подобное). Также мы не будем искать текстовые строки. Все это заставляет меня думать, что реляционная база данных более подходит, чем, скажем, эластичный поиск. Поскольку я уже знаю MySQL, я склонен также использовать MySQL для аналитики.
Кроме того, поскольку я уже знаю CakePHP, я склонен использовать CakePHP и для Google Analytics API. Хотя я все еще открыт для, возможно, более легкого PHP-фреймворка.
Теперь, как я уже говорил, API-интерфейсу Google Analytics необходимо будет хранить события (просмотры страниц и т. Д.). Но для этого также потребуются данные из нашего Content API (имена пользователей, имена файлов и т. Д.). Кроме того, я хочу использовать аутентификацию, которая также обрабатывается нашим Content API. Поэтому, если наш веб-интерфейс Analytics отправляет запрос нашему API-интерфейсу Google Analytics, API-интерфейсу Google Analytics придется выполнить один или несколько запросов к нашему API содержимого, прежде чем он сможет собрать ответ. По крайней мере, для аутентификации пользователя, а также для сбора частей данных, необходимых для графиков Google Analytics.
Одним из преимуществ микросервисов, которое часто упоминается, является то, что вы можете работать с ними независимо, добавляя и изменяя функциональность, возможно, переходя на совершенно новую платформу. Другой - масштабируемость: вы можете масштабировать один микросервис без необходимости масштабирования другого.
Однако, когда одному микросервису требуются данные от другого микросервиса (как в моей ситуации), разве эти преимущества не сводятся на нет? Всякий раз, когда я изменяю конечную точку в нашем Content API, мне нужно будет подумать о том, используется ли эта конечная точка нашим Analytics API. Нет юнит-тестов, чтобы покрыть это. А когда использование нашего API-интерфейса Google Analytics растет, я не могу просто масштабировать инфраструктуру Analytics, потому что Content API также будет попадать чаще.
Так что мне интересно, не будет ли монолитный подход больше иметь смысл в нашей ситуации? Или есть ли преимущества микросервисного подхода, которого я не вижу?