Настройка моего сервера для активно используемого API
Я скоро куплю кучу серверов для приложения, которое собираюсь запустить, но меня беспокоит настройка. Я ценю любую обратную связь, которую я получаю.
У меня есть приложение, в котором будет использоваться написанный мной API. Другие пользователи / разработчики также будут использовать этот API. Сервер API будет получать запросы и передавать их рабочим серверам. API будет содержать только mysql db запросов для ведения журнала, аутентификации и ограничения скорости.
Каждый рабочий сервер выполняет другая работа и в будущем для масштабирования я добавлю больше рабочих серверов, которые будут доступны для выполнения заданий. Файл конфигурации API будет отредактирован с учетом новых рабочих серверов. Рабочие серверы будут выполнять некоторую обработку, а некоторые сохранят путь к изображению в локальной базе данных для последующего извлечения API для просмотра в моем приложении, некоторые будут возвращать строки результата процесса и сохранять их в локальной базе данных. .
Эта установка кажется вам эффективной? Есть ли лучший способ реструктурировать это? Какие вопросы мне следует рассмотреть? Пожалуйста, посмотрите изображение ниже, я надеюсь, что это поможет вам понять.
Более высокая доступность
Как упоминает Крис, ваш сервер API - это единственная точка отказа в вашем макете. Вы настраиваете инфраструктуру очередей сообщений, которую многие уже реализовали раньше.
Продолжайте идти по тому же пути
Вы упоминаете получение запросов на сервере API и вставляете задание в базу данных MySQL, работающую на каждом сервере. Если вы хотите продолжить этот путь, я предлагаю удалить уровень сервера API и спроектировать Workers так, чтобы каждый принимал команды непосредственно от ваших пользователей API. Вы можете использовать что-то столь же простое, как циклический DNS, чтобы распределить каждое соединение пользователя API напрямую на один из доступных рабочих узлов (и повторить попытку, если соединение не удалось).
Используйте сервер очереди сообщений
Более надежные инфраструктуры очередей сообщений используют программное обеспечение, разработанное для этой цели, например ActiveMQ. Вы можете использовать RESTful API ActiveMQ для приема запросов POST от пользователей API, а простаивающие рабочие могут ПОЛУЧИТЬ следующее сообщение в очереди. Однако это, вероятно, излишек для ваших нужд - он рассчитан на задержку, скорость и миллионы сообщений в секунду.
Используйте Zookeeper
В качестве компромисса вы можете посмотреть на Работник зоопарка, даже если это не сервер очереди сообщений. Мы используем at $ work именно для этой цели. У нас есть набор из трех серверов (аналогичных вашему серверу API), на которых работает серверное программное обеспечение Zookeeper, и есть веб-интерфейс для обработки запросов от пользователей и приложений. Веб-интерфейс, а также соединение бэкэнда Zookeeper с рабочими, имеют балансировщик нагрузки, чтобы гарантировать, что мы продолжаем обрабатывать очередь, даже если сервер отключен для обслуживания. Когда работа сделана, рабочий сообщает кластеру Zookeeper, что работа завершена. Если работник умирает, это задание будет отправлено на выполнение другой работы.
Другие проблемы
- Убедитесь, что работа завершена, если работник не отвечает
- Как API узнает, что задание выполнено, и извлечет его из базы данных рабочего?
- Постарайтесь уменьшить сложность. Вам нужен независимый сервер MySQL на каждом рабочем узле, или они могут взаимодействовать с сервером MySQL (или реплицированным кластером MySQL) на сервере (ах) API?
- Безопасность. Кто-нибудь может подать заявку на работу? Есть ли аутентификация?
- Какой работник должен получить следующую работу? Вы не упоминаете, займет ли задача 10 мс или 1 час. Если они быстрые, вам следует удалить слои, чтобы уменьшить задержку. Если они медленные, вы должны быть очень осторожны, чтобы более короткие запросы не застревали за несколькими долгими.
Самая большая проблема, которую я вижу, - это отсутствие планирования аварийного переключения.
Ваш сервер API - это большая единственная точка отказа. Если он выходит из строя, то ничего не работает, даже если ваши рабочие серверы все еще работают. Кроме того, если рабочий сервер выходит из строя, то предоставляемая сервером услуга становится недоступной.
Предлагаю вам взглянуть на проект Linux Virtual Server (http://www.linuxvirtualserver.org/), чтобы получить представление о том, как работает балансировка нагрузки и переключение при отказе, а также о том, как они могут принести пользу вашему проекту.
Есть много способов структурировать вашу систему. Какой способ лучше - это субъективный звонок, на который вы лучше всего ответите. Я предлагаю вам провести небольшое исследование; взвесить компромиссы различных методов. Если вам нужна информация о методе имплантации, задайте новый вопрос.