Как разработчики могут безопасно полагаться на сторонние веб-сервисы, не жертвуя собственным SLA? Как только вы начнете использовать API, вы должны следить за ним. К сожалению, нет стандартного способа сделать это. Возможно, пришло время попросить поставщиков SaaS прояснить свой статус здоровья.
Эта проблема
Веб-приложения используют все больше сторонних веб-сервисов. В производстве они используются для аналитики, хранения журналов, A / B-тестирования, комментариев, поиска, отправки по электронной почте, мультимедиа, организации очередей и т. Д. В процессе разработки они предназначены для контроля версий, автоматической сборки, резервного копирования, аутентификации. Использование сторонних веб-сервисов ускоряет разработку, но также ослабляет приложения. Действительно, сбой в одном из сервисов может вызвать сбой всего приложения.
Разработчики должны реализовать сценарии сбоев в случае отказа сторонних сервисов. Но они также должны следить за этими услугами, чтобы получать уведомления, когда кто-то ломается. И именно здесь начинается проблема: каждый поставщик услуг предлагает свой способ определения статуса API — если таковой имеется.
Состояние Искусства
Большинство служб вообще не предоставляют никаких специальных функций проверки работоспособности. Вы просто должны доверять их способности быть на 100% времени. Те, кто предоставляет информацию о состоянии, делают это для людей, а не для машин. На их странице состояния обычно отображается история последних отключений, а также отображается общий статус платформы. Каждый сервис сообщает о состоянии и времени работы по-своему. Например, сравните следующие страницы состояния:
- Статус API Twitter: https://dev.twitter.com/status
- Статус Служб Google: http://www.google.com/appstatus
- Статус WebSolr: твиттер-аккаунт websolrstatus .
- Статус GitHub: https://status.github.com
Этот тип страницы — то, куда вы переходите, когда вы уже считаете, что у службы есть проблема. Эти страницы не помогают обнаруживать простои, а только подтверждают их. Если вам необходимо убедиться, что такая служба запущена и работает, и получать уведомления, когда ее нет, вы должны определить, какие ресурсы являются критическими для вашего использования, и регулярно проверять эти ресурсы. Страницы состояния не облегчают эту задачу — если только вы не хотите выполнять очистку веб-страниц для получения данных о времени безотказной работы из HTML.
Некоторые службы понимают это требование, а также предоставляют ресурс состояния , предназначенный для машин. Например, вот тип ответа, возвращаемого недавно выпущенным GitHub Status API :
GET /api/status.json
Host: status.github.com
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Content-Length: 55
{"status": "good","last_updated":"2012-12-11T08:14:17Z"}
К сожалению, этих API-интерфейсов состояния служб слишком мало. Хуже того: несколько сервисов, предлагающих такой API, имеют разный интерфейс.
У меня есть мечта
Было бы невероятно, если бы все сторонние веб-сервисы предоставляли стандартизированный API, позволяющий системам мониторинга проверять свое состояние работоспособности. Основные требования к этому API: простота запроса, легко декодируемый ответ и низкий объем HTTP.
Системы мониторинга должны знать, является ли ресурс полностью работоспособным и когда была выполнена последняя проверка работоспособности Это можно легко выразить, ответив на GETзапрос, например:
GET /up HTTP/1.1 Host: www.example.com
Если сервер возвращает HTTP-статус 200, это означает, что система запущена и работает. Last-ModifiedЗаголовок является идеальным местом , чтобы отметить последний раз , когда система фактически проверила свое собственное здоровье.
HTTP/1.1 200 OK Last-Modified: Sun, 09 Dec 2012 14:11:45 GMT
Любой другой тип ответа (500, тайм-аут …) означает, что система в какой-то степени страдает от сбоя. Ответ 404 означает, что поставщик не реализовал какой-либо ресурс состояния для компьютеров.
То, что находится в теле ответа, полностью зависит от поставщика услуг. Отчет HTML, объект JSON и документ XML … Я не думаю, что тело требует стандартизации, поскольку вся необходимая информация для машин уже находится в заголовке ответа HTTP. На самом деле, чтобы сделать вещи еще проще, поскольку ответу не нужно тело, HEADдля машин достаточно запроса. Давайте держать GETдля браузера и людей.
HEAD /up HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK Last-Modified: Sun, 09 Dec 2012 14:11:45 GMT
Как данная служба должна проверить свое здоровье? Реализация является обязанностью службы. Подлинная проверка работоспособности должна подразумевать инструмент удаленного мониторинга, такой как Pingdom или мой собственный Uptime . Информация также может поступать из ориентированной на пользователя аналитической службы, такой как Google Analytics . С другой стороны, серверный скрипт, проверяющий доступность компонентов внутренней инфраструктуры (база данных, хранилище, веб-сервер, процессор …), может справиться с задачей. Однако этот ресурс всегда должен быть динамичным и обеспечивать честную обратную связь о состоянии сервиса с точки зрения клиента.
Нам больше ничего не нужно. Если бы все веб-сервисы, которые мы используем в наших веб-приложениях, могли предоставить этот HEAD /upресурс, было бы легко отслеживать их все, и добавление новой зависимости к еще одной сервисе не потребовало бы повторного изобретения колеса.
Можем ли мы поговорить об этом?
Мне бы очень хотелось, чтобы HEAD /upресурс или что-то подобное стало широко доступным, например robots.txt, или favicon.ico. Если вы пользуетесь SaaS- провайдером, по моему мнению, вы должны предоставить такой инструмент своим клиентам.
Я написал Head-Upзапрос на комментарии на GitHub . Если вы обеспокоены этой проблемой, будь то с точки зрения клиента или с точки зрения поставщика SaaS , приходите и обсудите ее в соответствующей Head-Upгруппе Google . Вы можете обсудить множество вещей: обслуживание /upресурса с субдомена без GET /upфайлов cookie, добавление дополнительной информации о состоянии работоспособности в ответ на запрос, предоставление этих данных в формате JSON или XML … Обсуждение может длиться долго время. Или, поскольку у всех нас есть рабочие места, мы могли бы стремиться к быстрому и прагматичному консенсусу по очень небольшому набору функций и позволить реализациям начать быстро.
Если соглашение когда-либо будет найдено, это будет на благо. Я могу представить себе новые сервисы, которые собирают и сравнивают информацию о состоянии работоспособности многих API разумным образом (например, api-status.com, но с большим выбором сервисов). Общий эффект, вероятно, будет заключаться в повышении общего качества обслуживания платформ SaaS . Хорошо, я сплю. Но если вы разделяете ту же мечту, я с нетерпением жду вашей поддержки!