Вы изучили BFF и Serverless?

внешний интерфейс
❝

Frontier: Некоторое время назад я поделился знаниями и опытом BFF и бессерверных приложений внутри компании, от концепций, функций и сценариев применения до простых практик. Сегодня я пользуюсь этой возможностью, чтобы поделиться с вами тем, что такое BFF и бессерверные решения?

❞

1.BFF

❝

Прежде чем мы поговорим о Serverless, давайте поговорим о BFF, Как следует из названия, BFF — этоBackend For Frontend, объяснил по-китайски, что серверная часть обслуживает переднюю часть, так почему же там BFF?

❞

У студентов Front-end и Back-end есть свои причины.Есть ли решение для разрешения этой неловкой сцены, так что есть BFF?

1.1 Введение

❝

Первоначальное намерение слоя BFF состоит в том, чтобы добавить слой между фоновым сервисом и внешним интерфейсом (клиентом).Далее, давайте посмотрим на следующее изображение.

❞
❝

👦А Куан спросил: Какую роль играет BFF?

❞

ответ:用户体验适配层和API聚合层: в основном отвечает за быструю последующую итерацию пользовательского интерфейса, Сервис конечного интерфейса объединяется и обрабатывается, а данные обрезаются, форматируются, агрегируются и т. д.

Ниже уровня BFF находятся различные серверные микросервисы, а на верхнем уровне BFF находятся различные интерфейсные приложения (мультитерминальные приложения), которые вызывают вниз серверную часть как услугу, предоставляют интерфейсные услуги клиенту вверх. , а серверная часть обеспечивает внешний интерфейс уровня BFF. Уровень BFF напрямую вызывает интерфейс RPC сервера для получения данных и обрабатывает данные по мере необходимости для завершения замкнутого цикла всего BFF (в основном Node + GraphQL стек технологий)

❝

👧 А Дай спросил: Кто будет разрабатывать слой BFF?

❞

Следование принципу сервисной автономии, кто использует, кто разрабатывает, означает, что спровоцировать эту важную задачу могут только фронтенд-студенты, и в то же время это на шаг дальше от «инженеров полного стека». Я не знаю, должен ли 🤷‍♂️ радоваться или огорчаться

Можно ли сделать BFF бэкендом? Конечно можно, но если это приносит новые проблемы, то всегда забивает интерфейс, что будет ограничивать улучшение личных способностей.

❝

🙆Ах Ю спросил: Ты пропустил шлюз API?

❞

хороший вопрос BFF и шлюз — две важные концепции в архитектуре микросервиса, см. следующий простой пример 👇

❝

Поделитесь тем, что однажды сказал Ю Бо, руководитель отдела технологий взаимодействия Ant Financial: «Модель BFF — это не просто техническая архитектура. С точки зрения социального разделения труда BFF — это многоуровневая архитектура, ориентированная на множество ценностей».

❞

1.2 Преимущества БФФ

Основные преимущества следующие👇

  • Затраты на связь могут быть снижены: студенты, изучающие бэкенд, стремятся к отделению, надеясь, что клиентские приложения и внутренние микросервисы не связаны друг с другом. Благодаря внедрению среднего уровня BFF обе стороны могут меняться независимо друг от друга.
  • Адаптация многотерминального приложения: отображать разные (или меньшие) данные. Например, API дизайна страницы на стороне ПК должен поддерживать мобильный терминал. Обнаружено, что существующий интерфейс тесно связан с требованиями к отображению пользовательского интерфейса рабочего стола от дизайна. к реализации и не могут быть легко адаптированы к мобильному терминалу. , точно так же, как интерфейс рекомендации новостей на стороне ПК, поля интерфейса требуются на стороне ПК, но не на мобильном терминале H5.В это время корректировки выполняются на уровне BFF в соответствии с разными терминалами и разными (или меньше) также могут быть сделаны вызовы API (агрегация) для уменьшения HTTP-запросов.
❝

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

❞

1.3 Болевые точки BFF

  • Повторная разработка: при разработке приложения BFF для каждого устройства оно также столкнется с некоторыми повторяющимися проблемами разработки и увеличит стоимость разработки.
  • Проблемы с обслуживанием: Необходимо поддерживать различные приложения BFF. В прошлом интерфейсу не нужно было заботиться о параллелизме, но теперь давление параллелизма сосредоточено на BFF.
  • Сложные ссылки: процесс становится громоздким.После введения BFF, интерфейсные и серверные процессы исследований и разработок должны выполняться одновременно, многосторонняя публикация и взаимозависимость, что приводит к громоздким процессам.
  • Пустая трата ресурсов: если слоев BFF слишком много, занятость ресурсов станет проблемой, и ресурсы будут потрачены впустую, если не будет гибкого масштабирования и расширения.

Я видел «счастливую беду» под слоем BFF на предыдущем PPT.

1.4 Какие решения могут решить болевые точки традиционных BFF?

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

ответ:Serverless

2.Serverless

❝

мы можем поставитьServerlessОн разбирается на два слова «сервер» и «меньше», что буквально означает «менее серверный или бессерверный», что ослабляет концепцию серверной части, эксплуатации и обслуживания. Текущие зрелые бессерверные облачные продукты в основном включают Amazon Lambda, Google Cloud Function, Azure Function, AliCloud Функции вычислений, Tencent CloudBase и т. д.

❞

2.1 Эволюция бессерверных технологий

2.2 Что такое бессерверное

❝

Serverless = Faas (Function as a service) + Baas (Backend as a service)

❞

2.3 Облачные функции (Faas)

❝

FaaS (Function-as-a-Service) — это платформа, на которой поставщики услуг предоставляют пользователям функции разработки, запуска и управления этими функциями без создания и поддержки базовой структуры.

❞

Учащиеся, работающие с клиентами, вызывают сервисы Faas так же просто, как вызов локальных функций. Как показано ниже, это простая демонстрация облачной разработки апплета в Tencent Cloud. cloudfunction — это метод, используемый для определения облачных функций.

2.4 Бэкенд как услуга (BaaS)

❝

Бэкэнд BaaS (Backend-as-a-Service) как услуга, включая компоненты серверной службы, это сторонняя служба на основе API, используемая для реализации основных функций в приложениях, включая часто используемые базы данных, хранилище объектов, очереди сообщений, услуги по регистрации и т.д.

❞

Например, следующие сервисы в разработке Tencent Cloud 👇:

2.5 Бессерверная архитектура

2.6 Преимущества бессерверного доступа

  • Унифицированная среда: нет необходимости создавать серверную среду, поддерживать согласованность среды каждой машины. Механизм бессерверной обработки может воспроизводиться естественным образом
  • Pay-as-you-go: мы платим только тогда, когда код работает, без траты неиспользуемых ресурсов
  • Богатый SDK: существуют полные вспомогательные службы, такие как облачная база данных, облачное хранилище, облачная очередь сообщений, облачное аудио и видео, облачные службы ИИ и т. д.
  • Эластичное масштабирование: нет необходимости оценивать трафик, заботиться об использовании ресурсов, резервировать аварийное восстановление, расширять машины и динамически увеличивать пиковый трафик в соответствии с трафиком.
❝

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

❞

2.7 Недостатки бессерверных технологий

  • Сильная привязка облачных производителей: они часто привязаны к другим облачным продуктам производителя, таким как хранилище объектов, очередь сообщений и т. д., а это означает, что вам нужно одновременно активировать другие службы, а стоимость миграции высока. Если вы хотите мигрировать основную исходную логику, вы не можете это сделать. , питомник должен быть рефакторинг
  • Не подходит для длинных задач: функции облачной платформы будут ограничивать время выполнения функции, например, когда функция Ali cloud вычисляет максимальную продолжительность выполнения 10 мин.
  • Время холодного запуска: когда функция запущена, выполнение контейнера и среды занимает определенное время. Для HTTP-запросов это может увеличить задержку ответа.
  • Отладка и тестирование: разработчикам необходимо постоянно корректировать код, распечатывать журналы и отправлять их на функциональную платформу для запуска тестов, что приведет к затратам на разработку и затратам.

2.8 Сценарии бессерверных приложений

  • Сценарий 1: нагрузка имеет пики и спады

Во время пиков и спадов машинные ресурсы должны быть заранее запланированы в соответствии с пиковым спросом, например, при регистрации в больнице.Предполагая, что прием назначается на 10:00 каждый день, пик будет в 10:00. одновременность этого пика, соответствующая производительность (Однако коэффициент использования машины значительно падает во время провала, что приводит к потерям из-за невозможности повторного использования ресурсов, в то время как бессерверные не нужно готовиться к пику, не нужно держать уровня воды и поддерживает эластичное масштабирование и расширение, которое может выполняться во время вашего пика.

  • Сценарий 2: Запланированные задачи (отчет статистики и т. д.)

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

  • Сценарий 3: Разработка мини-программы (облачная разработка)

Например, при фактической разработке апплета WeChat, если мы не используем процесс получения openid для облачной разработки, а используем традиционный метод, вы знаете, что получение openid — очень громоздкий процесс, и внешний интерфейс должен получить значение кода через wx.login (зависит от времени). Затем перейдите в фоновый режим и используйте appsecret для вызова openid через значение кода.

❝

Поскольку облачная функция развернута в Tencent Cloud, Tencent Cloud эффективно инкапсулирует аутентификационную часть облачного вызова, так что ваш интерфейс может легко реализовать защиту аутентификации без необходимости поддерживать сложный механизм аутентификации, так что авторы личных разработок и небольшие команды могут легче разрабатывать апплеты

❞

3 Резюме

❝

Эта статья знакомит с концепцией, позже будет представлена ​​​​дополнительная практика бессерверных технологий, студенты, заинтересованные в углубленном изучении, могут сначала понять следующую личную рекомендуемую литературу.

❞
  • Yuque на «облачной» стороне: создание коммерческих приложений с полным стеком JavaScriptчитать
  • Руководство по разработке приложений для бессерверной архитектурычитать
  • Бессерверные технологии запускают новые технологические изменения во внешнем интерфейсечитать
  • Начало работы с Serverless для фронтенд-инженеровчитать
  • Как мы перешли от передовых технологий к опытным технологиям?читать

🌲Предыдущие статьи Соуса:

Пожалуйста, выпейте 🍵 Не забудьте подключиться три раза~

1. После прочтения не забудьте поставить лайк 🌲 соусу, там есть 👍 и мотивация

2. Обратите внимание на интересные вещи в интерфейсе официального аккаунта и пообщайтесь с вами об интересных вещах в интерфейсе.

3. Статья размещена на GithubfrontendThingsСпасибо, Стар✨

Категории