Интенсивное чтение «Что Serverless привносит во внешний интерфейс»

Serverless

1. Введение

Serverless — это «бессерверная архитектура», которая позволяет пользователям сосредоточиться на технологии бизнес-логики, не заботясь о среде выполнения программы, ресурсах и количестве.

Теперь, когда компания достигла DevOps и движется к бессерверной технологии, почему передний конец должен обращать внимание на бессерверную систему?

Для студентов, изучающих бизнес-процессы:

  1. Это изменит спецификации определения внешнего и внутреннего интерфейса.
  2. Это определенно изменит способ совместной отладки внешнего и внутреннего интерфейса, позволит фронтенду участвовать в разработке серверной логики и даже смешать Node и Java.
  3. Это значительно снижает порог обслуживания сервера Nodejs.Пока вы можете писать код JS, вы можете поддерживать службы Node без изучения знаний, связанных с DevOps.

Для внештатного разработчика:

  1. В будущем развертывание серверов станет более гибким и менее затратным.
  2. Развертывание выполняется быстрее и менее подвержено ошибкам.

Фронтенд-фреймворки всегда привносят внутреннее мышление, в то время как Serverless привносит внешнее мышление в работу и обслуживание серверной части.

Front-end разработчики на самом деле первыми пользуются преимуществами «бессерверных». Им не нужно иметь свои собственные службы или даже собственные браузеры, чтобы их код JS работал равномерно и с балансировкой нагрузки на компьютере каждого пользователя.

И браузер каждого пользователя, как и самый модный и зрелый бессерверный кластер, запускает холодный старт с удаленной загрузки JS-кода и даже лидирует в холодном старте: с помощью JIT-ускорения код достигает холодного старта на уровне миллисекунд. Мало того, браузер также является идеальной средой для служб BAAS.Мы можем вызвать любую функцию для получения файлов cookie пользователя, информации об окружающей среде и служб локальной базы данных, не заботясь о том, какой компьютер использует пользователь, к какой сети он подключен. или даже размер жесткого диска.

Это философия Serverless. С помощью FAAS (функция как услуга) и BAAS (бэкэнд как услуга) мы пытаемся создать среду разработки на стороне сервера, к которой привыкли фронтенд-разработчики, поэтому фронтенд-разработчики должны лучше понимать преимущества Serverless.

2. Интенсивное чтение

FAAS (Function as a Service) + BAAS (Background as a Service) можно назвать полной бессерверной реализацией.Кроме того, есть концепция PASS (Platform as a Service). Обычно среда платформы реализуется с помощью контейнерной технологии и, в конечном итоге, для достижения NoOps (автономная эксплуатация и обслуживание) или, по крайней мере, DevOps (разработка, эксплуатация и обслуживание).

Кратко представим эти термины, чтобы никто не запутался:

FAAS - Function as a service

Функция — это услуга, каждая функция — это услуга, функция может быть написана на любом языке, за исключением того, что не нужно заботиться о каких-либо деталях эксплуатации и обслуживания, таких как: вычислительные ресурсы, гибкое расширение и может оплачиваться по объему. и поддерживает управление событиями. Все основные поставщики облачных услуг в отрасли поддерживают FAAS, и у каждого есть набор рабочих мест или визуальных рабочих процессов для управления этими функциями.

BAAS - Backend as a service

Бэкэнд и сервисы — это интеграция многих промежуточных технологий, которые могут вызывать сервисы независимо от среды, такие как данные как сервис (сервисы базы данных), сервисы кэширования и т. д. Хотя есть еще многоXASS, но только FAAS + BAAS составляют концепцию Serverless.

PAAS - Platform as a service

Платформа как услуга, пользователи могут автоматически и непрерывно интегрировать и пользоваться услугами высокой доступности, пока они загружают исходный код.Если скорость достаточно высока, ее можно считать похожей на бессерверную. Однако с появлением контейнерной технологии, представленной Docker, развертывание PASS с контейнером в качестве гранулярности постепенно стало основным и наиболее часто используемым методом развертывания приложений. Например, промежуточное ПО, база данных, операционная система и т. д.

DAAS - Data as a service

Данные как услуга обеспечивают сбор данных, управление, агрегирование и услуги в одном пакете. Службы DASS могут применять бессерверную архитектуру.

IAAS - Infrastructure as a Service

Инфраструктура как услуга, такая как компьютерное хранилище, сеть, сервер и другие объекты инфраструктуры, предоставляется как услуга.

SAAS - Software as a Service

Программное обеспечение как услуга, такое как ERP, CRM, службы почтовых ящиков и т. д., предоставляет услуги с программным обеспечением в качестве степени детализации.

контейнер

Контейнер — это виртуальная среда выполнения программы, которая изолирует физическую среду, и эта среда может быть описана и перенесена. Более популярной контейнерной технологией является Docker.

По мере увеличения количества контейнеров появляются технологии управления кластерами контейнеров.Известной платформой для оркестрации контейнеров является Kubernetes. Контейнерная технология — это вариант реализации бессерверной архитектуры, а также основа для реализации.

NoOps

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

Беспилотная эксплуатация и обслуживание не означает отсутствие серверов.Бессерверные системы также могут нуждаться в эксплуатации и обслуживании человеком (по крайней мере, на данный момент), но разработчикам больше не нужно заботиться об окружающей среде.

DevOps

Автор считает, что это можно понимать как «разработка — это эксплуатация и обслуживание».В конце концов, если что-то пойдет не так, ответственность должна нести разработка, а зрелая система DevOps может позволить большему количеству разработчиков взять на себя обязанности ОП или более тесно сотрудничать. с ОП.

Back Serverless, будущее развитие серверной и клиентской части может быть похоже на:Вы не заботитесь о том, на каком сервере (браузере) работает код, не беспокоитесь о среде сервера (версия браузера), не беспокоитесь о балансировке нагрузки (фронтенд никогда не беспокоит), службы промежуточного программного обеспечения в любое время вызываются (LocalStorage, Service Рабочий).

Студенты, работающие с интерфейсом, должны быть особенно в восторге от Serverless. Возьмем в качестве примера собственный опыт автора.

от создания игры

Автор очень увлечен развивающими играми, наиболее распространенными развивающими играми являются создание ресурсов, сбор или вычисление ресурсов при зависании.Правила обратного отсчета. Когда автор разрабатывал игру, клиентский код и серверный код изначально были полностью разделены на два набора реализации:

// ... UI 部分，画出一个倒计时伐木场建造进度条
const currentTime = await requestBuildingProcess();
const leftTime = new Date().getTime() - currentTime;
// ... 继续倒计时读条
// 读条完毕后，每小时木头产量 + 100，更新到客户端计时器
store.woodIncrement += 100;

Для игрового опыта пользователи могут просматривать журнал хода строительства лесопилки, не обновляя браузер, и объявлять, что строительство завершено, и обнаруживать, что они получают еще 100 единиц древесины в секунду! Но когда лесопилкаОбновление браузера в любое время до, во время или после завершения построения должно поддерживать единую логику, а данные должны рассчитываться в автономном режиме на серверной части.На этом этапе нам нужно написать внутренний код:

// 每次登陆时，校验当前登陆
const currentTime = new Date().getTime()
// 获取伐木场当前状态
if ( /* 建造中 */) {
  // 返回给客户端当前时间
  const leftTime = building.startTime - currentTime
  res.body = leftTime
} else {
  // 建造完毕
  store.woodIncrement += 100
}

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

Настроить синхронизацию

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

export const buildings = {
  wood: {
    name: "..",
    maxLevel: 100,
    increamentPerLevel: 50,
    initIncreament: 100
  }
  /* .. and so on .. */
};

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

Создание игр в бессерверной среде

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

// 根据建筑建造时间判断建筑状态
export const getBuildingStatusByTime = (instanceId: number, time: number) => {
  /**/
};

// 判断建筑生产量
export const getBuildingProduction = (instanceId: number, lastTime: number) => {
  const status = getBuildingStatusByTime(instanceId, new Date().getTime());
  switch (status) {
    case "building":
      return 0;
    case "finished":
      // 根据 （当前时间 - 上次打开时间）* 每秒产量得到总产量
      return; /**/
  }
};

// 前端 UI 层，每隔一秒调用一次 getBuildingProduction 函数，及时更新生产数据
// 前端入口函数
export const frontendMain = () => {
  /**/
};

// 后端 根据每次打开时间，调用一次 getBuildingProduction 函数并入库
// 后端入口函数
export const backendMain = () => {
  /**/
};

С помощью службы PASS логика интерфейса и сервера записывается вместе, аgetBuildingProductionФрагмент функции загружается в сервис FAAS, так что логика внешнего и внутреннего интерфейса может использоваться одновременно!

В представлении папок вы можете выполнить следующее структурное планирование:

.
├── client    # 前端入口
├── server    # 后端入口
├── common    # 共享工具函数，可以包含 80% 的通用游戏逻辑

Некоторые люди могут спросить: совместное использование внешнего и внутреннего кода возможно не только с бессерверной версией.

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

перспектива спереди и сзади

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

Упрощенные фоновые службы

Когда арендуется традиционный сервер ECS, выбора среды CentOS и AliyunOS достаточно, чтобы раздражать. Для отдельных разработчиков нам очень сложно построить полноценный сервис непрерывной интеграции, и есть много вариантов, от которых голова кружится:

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

Даже стабильность сервера требует для управления такими инструментами, как PM2. Когда сервер сталкивается с атаками, перезапусками и сбоями диска, его можно восстановить, только открыв сложный верстак или войдя в оболочку. Как это заставляет людей концентрироваться на том, что они должны делать?

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

На самом деле, до появления Serverless многие бэкэнд-команды использовали концепцию FAAS для упрощения процесса разработки.

Чтобы уменьшить влияние среды и проблем развертывания при написании внутренней бизнес-логики, многие команды разбивают бизнес-логику на блоки, соответствующие фрагментам или блокам кода.Blockly, эти блоки могут независимо поддерживаться, освобождаться и, наконец, внедряться в основную программу или загружаться динамически. Если вы привыкли к такому способу разработки, проще принять Serverless.

более толстые фоновые сервисы

С закулисной точки зрения все становится сложнее. Вместо предоставления простых серверов и контейнеров теперь необходимо оградить среду исполнения от пользователей и сделать сервисы более толстыми.

Из некоторых статей автор узнал, что реализация Serverless по-прежнему сталкивается со следующими проблемами:

  • Существует множество типов бессерверных реализаций от разных поставщиков, и чтобы достичь мультиоблачного развертывания бизнеса, необходимо сгладить различия.
  • Зрелый сервис PASS на самом деле является псевдо-бессерверным, как его стандартизировать в будущем.
  • Холодный запуск FAAS требует перезагрузки кода и динамического распределения ресурсов, что приводит к медленному холодному запуску.Помимо предварительного прогрева, также требуется экономическая оптимизация.
  • Для приложений с высокой степенью параллелизма (таких как двойные 11 пиков) очень опасно не требовать оценки емкости, но если это может быть полностью гибким, неприятная оценка емкости будет опущена.
  • Как перенести существующие приложения. Большинство поставщиков бессерверных услуг в отрасли не решили проблему миграции стандартных приложений.
  • Бессерверные характеристики ведут к безгражданству, а сложные интернет-приложения сохраняют состояние, поэтому задача состоит в том, чтобы поддерживать состояние без изменения привычек разработки.

К счастью, эти проблемы активно решаются, и многие решения уже реализованы.

Преимущества бессерверной обработки для серверной части намного перевешивают проблемы:

  • Продвигайте интерфейсную и внутреннюю интеграцию. Это еще больше снижает порог для Node для написания кода на стороне сервера и устраняет затраты на обучение работе приложения. Автор столкнулся с прерыванием службы приложения, вызванным службой базы данных, которую я подал заявку на миграцию в другие машинные залы. Мне больше не нужно беспокоиться об этом в будущем, потому что база данных является службой BAAS. выполните миграцию.
  • Повысить эффективность использования ресурсов. Устраните эксклюзивные ресурсы приложения, замените их на загрузку ненужного потребления ресурсов по запросу и поместите службу на каждую машину кластера, уровень воды ЦП плоского кластера.
  • Снизить порог использования облачных платформ. Отсутствие необходимости в эксплуатации и обслуживании, гибкое расширение, услуги на основе ценности и высокая доступность.Несмотря на то, что эти возможности привлекают больше клиентов, функция полностью выставления счетов по требованию также снижает накладные расходы пользователей и обеспечивает беспроигрышную ситуацию.

Используйте Serverless, чтобы попробовать открыть службу

Автор отвечает за построение масштабной платформы BI-анализа в компании.Одной из базовых возможностей платформы BI-анализа является визуализация.

Так как же открыть возможности построения визуализации? Что сейчас проще сделать, так это открыть компоненты, в конце концов, дизайн интерфейса может быть относительно отделен от дизайна сервера, а система загрузки AMD относительно зрелая.

Одной из проблем, с которыми приходится сталкиваться сейчас, является открытость серверных возможностей, поскольку при наличии индивидуальных требований к возможностям выборки может потребоваться настройка логики внутренней обработки данных. В настоящее время что можно сделать, так это использовать maven3 и jdk7 для создания локальной среды разработки для тестирования.Если вы хотите выйти в интернет, вам понадобится помощь студентов, изучающих бэкэнд.

Если уникальная бессерверная служба BAAS построена на серверной части, онлайн-кодирование, отладка и даже выпуск в градациях серого могут выполняться так же, как внешние компоненты для предварительного тестирования. Теперь, когда было проведено много зрелых исследований в области разработки клиентских облачных сред, Serverless может объединить опыт разработки клиентских и серверных кодов в облаке, не заботясь об окружающей среде.

Архитектура бессерверного приложения

Прочитав несколько диаграмм архитектуры бессерверных приложений, я обнаружил, что большинство предприятий могут применять такую ​​архитектурную диаграмму:

Абстрактируйте бизнес-функции в функции FAAS, а абстрагируйте сервисы, такие как база данных, кэш и ускорение, в сервисы BAAS.

Верхний уровень обеспечивает вызовы механизма запуска Restful или события, соответствующие различным терминалам (ПК, мобильные).

Если вы хотите расширить возможности платформы, вам нужно только открыть терминал (компонентный доступ) и сервис FAAS (бэк-энд доступ).

Преимущества и проблемы

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

Преимущество 1: интерфейс более сосредоточен на технологии интерфейса, не требуя слишком много знаний управления приложениями.

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

Если вы вспомните свой самый гордый опыт работы, возможно, вы овладели знаниями в области эксплуатации и обслуживания приложений Node, построения интерфейсных инженерных систем, оптимизации эффективности НИОКР, формулирования стандартов и спецификаций и т. д.Но та часть, которая действительно работает для бизнеса, — это именно бизнес-код, который, по вашему мнению, меньше всего заслуживает упоминания.. Внешний интерфейс тратит слишком много времени на периферийные технологии и снижает количество мыслей о бизнесе и взаимодействии.

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

Serverless может эффективно решить эту проблему.Студентам фронтенда нужно только уметь писать код JS без каких-либо знаний по эксплуатации и обслуживанию, и они могут быстро реализовать свой собственный набор идей.

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

Эволюция языков, эволюция браузеров, эволюция серверов — это все процессы от сложного к простому и снизу к инкапсуляции, а бессерверность — это процесс дальнейшей инкапсуляции бэкенда + эксплуатация и обслуживание в целом.

Преимущество 2. Код, полученный в результате логической оркестровки, часто используется повторно и удобен в сопровождении, а также расширяет возможности облака и терминала.

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

Раньше многие команды пытались использовать Graphsql, чтобы сделать интерфейс «более гибким», и Serverless — более тщательное решение.

Моя собственная команда попробовала решение Graphsql, но поскольку бизнес очень сложный, трудно описать требования всех сценариев с помощью стандартной модели, поэтому использовать Graphsql нецелесообразно. Это именно блочная визуальная платформа разработки серверной части, которая сохранилась и достигла удивительной эффективности разработки. Этот набор абстракций обобщения Blockly может быть почти заменен Serverless. Таким образом, Serverless может решить проблему повышения эффективности внутренних исследований и разработок в сложных сценариях.

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

Автор использовал эту платформу для расчета офлайн-логов в команде обработки рекламных данных Baidu.После визуализации каждого вычислительного узла MapReduce можно легко увидеть, какой узел заблокирован при возникновении сбоя, а также увидеть самую длинную ссылку на выполнение. Каждый узел перераспределяет веса выполнения. Даже если логическая оркестровка не может решить все болевые точки разработки, она определенно может изменить ситуацию в конкретном бизнес-сценарии.

Задача 1: Может ли Serverless полностью удалить пороговое значение от внешнего интерфейса к внутреннему?

Самая распространенная ошибка, которую допускают студенты, работающие с фронтендом, при написании кода Node — это переполнение памяти.

Браузер + вкладка — это, естественно, сцена, которая закрывается после использования, а компоненты и логика пользовательского интерфейса создаются и уничтожаются очень часто, поэтому фронтенд-студентов мало, и им не нужно заботиться о проблемах GC. GC — это давняя привычка в сценариях серверной разработки, поэтому наиболее серьезной проблемой является переполнение буфера программы Nodejs.

Бессерверные приложения загружаются динамически и будут освобождены, когда они не используются в течение длительного времени, поэтому, вообще говоря, вам не нужно слишком беспокоиться о проблеме GC, даже если память переполнится, процесс может быть освобожден раньше память заполнена, или обнаружена аномалия, и процесс принудительно завершается.

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

Таким образом, несмотря на то, что бессерверная система упрощает работу и обслуживание, базовые знания о сервере по-прежнему необходимо понимать, и необходимо понимать, что код выполняется во внешнем или внутреннем интерфейсе.

Задача вторая: проблемы с производительностью

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

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

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

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

Задача 3: Как обеспечить переносимость кода

Вот очень классическая схема описания бессерверного позиционирования:

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

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

Спецификации службы BAAS, предоставляемые разными облачными платформами, могут различаться, а методы входа и выполнения FAAS также могут различаться.Если вы хотите внедрить развертывание в нескольких облаках, вы должны решить эту проблему.

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

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

3. Резюме

Ценность Serverless намного выше, чем проблема, и его концепция может фактически решить многие проблемы эффективности исследований и разработок.

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

Может быть, через 3-5 лет эти ямы будут заполнены, поэтому вы выбираете присоединиться к армии заполнения ям или выбираете подходящий сценарий для использования Serverless?

Адрес обсуждения:Интенсивное чтение «Что привносит Serverless во внешний интерфейс» · Выпуск №135 · dt-fe/weekly

Если вы хотите принять участие в обсуждении, пожалуйста,кликните сюда, с новыми темами каждую неделю, выходящими по выходным или понедельникам. Интерфейс интенсивного чтения — поможет вам отфильтровать надежный контент.

Категории