Как создать эффективную сеть API с помощью FASS?
имейте в виду, что то, что вы видите здесь, не является точным отражением реальности, это упрощенное объяснение конкретного варианта использования, в котором все возможные проблемы были сильно подчеркнуты, чтобы дать обзор проблемы сетевого взаимодействия, которые разработчики API должны учитывать при разработке API.
Мы хотим поговорить о приложении API / Dashboard, которое предоставляет журналы для ваших сервисов, чтобы вы могли иметь сервис или несколько сервисов.
В чем проблема?
Вы когда-нибудь задумывались, почему пользователи приложения жалуются? Почему это приложение медленное и неэффективное? и почему собственник беспокоится о расходах?
Начнем с декомпозиции сетевого вызова API, выполненного через мобильную сеть.
Первым шагом является подключение к серверу, на котором размещен API приложения, который состоит из различных действий, включающих качество Интернета пользователя, инициирование сетевого взаимодействия на низком уровне и шифрование. Мы предполагаем, что это всегда занимает около 300 мс, но знайте, что в зависимости от типа пользовательских сетей, таких как качество интернета и т. Д. (Это время часто называют задержкой)
Когда сервер получает запрос, он должен его обработать, загрузить журналы из базы данных и сгенерировать документ JSON. Предположим, что это занимает 20 мс, но фактическое время зависит от того, что запрашивается, и от возможностей сервера.
Наконец, четвертый шаг заключается в загрузке ответа сервера. Предположим, что размер сгенерированного документа JSON составляет около 32 КБ, поэтому для его загрузки требуется 200 мс со скоростью 160 КБ / с (что рекламируется как 1,3 МБ / с).
время одного этого запроса само по себе неплохо, но давайте посмотрим, что произойдет, когда приложение фактически использует API для заполнения экрана панели инструментов для простейшего варианта использования: пользователь, соответствующий одному владельцу, у которого есть одна учетная запись.
на картинке выше вы можете увидеть, какие вызовы API выполняются и как. Чтобы упростить объяснение, мы будем считать само собой разумеющимся, что пропускная способность сети составляет 160 КБ / с, задержка всегда составляет 300 мс, отправка запроса всегда занимает 0 мс, а для обработки запроса сервером всегда требуется 20 мс.
Для загрузки данных, отображаемых на экране панели инструментов, вся цепочка вызовов API состоит из пяти вызовов API, распределенных в три этапа благодаря параллельным вызовам. К сожалению, это занимает 1,2 с, что превышает 500 мс, верхний предел допустимого диапазона задержки . Теперь посмотрим, как обстоят дела с более сложным.
На картинке выше вы можете видеть, что приложение снова запускается со списка владельцев, но на этот раз их четверо. Поскольку приложение ограничено операционной системой до четырех одновременных HTTP-соединений, оно считывает подробную информацию для каждого из владельцев учетной записи, используя четыре параллельных запроса; после этого он перечисляет их счета, также параллельно. Обратите внимание, что если вся пропускная способность сети составляет 160 КБ / с, каждый параллельный запрос выполняется на четвертой части или 40 КБ / с. В зависимости от того, как часто пользователи / владельцы проверяют свои услуги, приложение может использовать от 60 до 90 МБ данных в месяц.
В настоящее время использование данных не является проблемой для большинства пользователей в большинстве стран, но не для всех пользователей во всем мире. Но помимо тарифного плана для передачи данных больше всего раздражает то, что все вызовы API, выполняемые на каждом экране, разряжают аккумулятор устройства, поскольку они поддерживают работу радио / Wi-Fi в течение более длительного периода времени. Понятно, что количество вызовов, их продолжительность и объем передаваемых данных могут вызывать беспокойство со стороны потребителя, но то же самое может относиться и к поставщику.
Допустим, API размещен на AWS. API реализован с использованием бессерверной службы (FAAS) под названием AWS Lambda.
Каждая цель кодируется независимо как функция, и вам больше не нужно беспокоиться о серверах, приложениях и масштабировании. Системы обрабатывают все, когда приходят вызовы, каждая соответствующая функция запускается. Стоимость услуги зависит от количества полученных вызовов, времени обработки и объема исходящих данных.
Кроме того, AWS Lambda предоставляет вам такие возможности, как онлайн-редактор и т. Д.
Есть только пример. API-интерфейсы могут иметь разные контексты, чем те, которые мы только что видели, но параметры эффективности сети обычно решаются вокруг следующих факторов: скорость, объем данных и количество вызовов. Мы должны осознавать это и пытаться найти баланс между потребностью в эффективности и идеальным дизайном.
Спасибо за чтение
Далее мы поговорим о балансе и оптимизации сетевых коммуникаций.
Ресурсы:
