Эта статья представляет собой текстовую версию контента, представленного системой Midway Serverless на конференции Alibaba Cloud Native Microservices в конце августа, и представляет новое решение Midway Serverless для бессерверной разработки, похожее на React Hooks.Нажмите здесь, чтобы испытать это сейчас.

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

Меня зовут Фаньи. В настоящее время я работаю в технологическом отделе отдела Alibaba-Amoy, в команде архитектуры внешнего интерфейса. также отвечает за архитектуру сценария интеграции с облачной средой Midway Serverless.

контур

Этот обмен я начну со следующих 4 частей:

• Статус бессерверного строительства Alibaba Node.js

• Представляем Midway Serverless

• Новое поколение интегрированных в облако решений для исследований и разработок

• план на будущее

Статус бессерверного строительства Alibaba Node.js

В прошлом 2019 году Комитет по развитию экономики Али предложил четыре основных технических направления. Они есть:

• Сервис сборки

• Serverless

• Умный

• Web IDE

Бессерверный и внешний интерфейс

Впервые Serverless как техническое направление было указано в качестве основного исследовательского направления фронтенд-комитета. Этому есть причина.

Первый находится в Alibaba Group, у нас есть более 1600 приложений node.js, но коэффициент использования ЦП приложения очень низкий, большая часть использования ЦП составляет

С технической точки зрения обслуживание Node.js на самом деле представляет определенную сложность, в процессе разработки мы столкнемся с проблемами, которые не были обработаны до фронтенда. Например, Docker, ограничение тока, журнал, межъязыковой вызов и т.д. Эта серия проблем будет стоить очень дорого.

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

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

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

Результаты бессерверного лендинга

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

Во-первых, мы достигли бессерверного пола в нескольких BU, получили двойное и стабильное продвижение. Эти BU вы можете быть хорошо знакомы, такие как: Департамент Сямэнь, новый ритейл, Flying Pig, ICBU, Lynx и другие эльфы.

И это снижение эффективности бизнеса, серверу, также оживляет производительность.

С точки зрения эффективности машин стоимость наших традиционных бизнес-машин снизилась примерно на 30 %, а стоимость средних и серверных бизнес-машин — примерно на 87 %. проблема низкой загрузки сервера в определенной степени.

С точки зрения эффективности человека, общая эффективность использования функций человеком повышается примерно на **48%. **Эта часть рассчитывается на основе встроенного инструмента пользователя + продолжительности звонка + количества кода.

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

Введение в бессерверную систему Midway

Мы разрабатывали на основе нашей платформы Midway Serverless на протяжении всего процесса внедрения Node FaaS. Поэтому, прежде чем я расскажу об облачной интеграции, я также представлю вам всю систему Midway Serverless.

Введение

В качестве примера возьмем вызов запроса.Вы видите, что в процессе обработки запроса среда выполнения облачной платформы разработки загрузит index.js, а index.js выполнит наш Midway Serverless Framework, и, наконец, фреймворк выполнит код пользователя. , возвращает результат.

система

И во всей системе Midway Serverless. У нас есть следующие три части:

• набор инструментов

• Рамка

• стандартизация

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

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

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

Новое поколение интегрированных в облако решений для исследований и разработок

В этой части мы познакомим вас с интегрированным облачным решением для НИОКР нового поколения.Что касается того, почему это новое поколение, то здесь сначала есть неопределенность, о которой будет сказано позже.

Проблемы у нас есть

Бессерверная практика в Alibaba не была гладкой, и мы также столкнулись со многими трудностями.

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

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

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

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

Определение облачной интеграции в сообществе

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

Архитектура Перспектива

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

Код Перспектива

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

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

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

Решение для бессерверной облачной интеграции Midway

В связи с этим мы также предложили собственное облачное решение. Новое решение определяется как: совместная облачная разработка и бесшовная интеграция.

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

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

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

• Простота развертывания: клиентская и серверная часть представляют собой склад.В одном выпуске мы можем одновременно выпустить переднюю и заднюю части, что снижает стоимость развертывания.

Возможности интеграции с бессерверным облаком Midway

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

• Функциональные решения для НИОКР: Функции — это интерфейсы. Мы используем функции для унификации внешнего и внутреннего интерфейса, сокращения ненужного шаблонного кода и ускорения разработки приложений.

• Вызов «все в одном» (API не требуется): больше не нужно вызывать API вручную. В новом фреймворке вы можете импортировать функции прямо с сервера и вызывать их так же, как обычные функции.

• Хуки (с использованием Node.js, например React Hooks): разрабатывайте приложения Node.js с помощью хуков. Это новый опыт и синтаксис, с которым вы знакомы. Более функциональная разработка обеспечивает идеальную поддержку возможностей

• Прогрессивная разработка: простые и сложные сценарии берут на себя все. Благодаря поддержке IoC мы можем повторно использовать лучшие практики сложных приложений Alibaba Node.js для поддержки разработки приложений корпоративного уровня.

Функциональные исследования и разработки: функциональные решения для исследований и разработок

Текущий режим разработки интерфейса поставщика облачных услуг

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

Например, все три облачные платформы Alibaba Cloud, Tencent Cloud и AWS имеют разные входные данные. Различное участие означает, что разработчики должны сами понимать различия между различными платформами, а стоимость обучения высока.

Подумав об этом, мы чувствуем, что стоимость этой модели разработки слишком высока, так что есть ли более простой путь?

Разрабатывайте интерфейсы максимально лаконично

Ответ положительный.

Мы обнаружили, что можем достичь своей цели, используя нативные функции JavaScript. На следующем рисунке показан пример: левый — метод разработки интерфейса Get, а правый — метод разработки интерфейса Post.

Когда функция не имеет параметров, HTTP-метод интерфейса — Get, а когда интерфейсу необходимо передать параметры — это интерфейс Post.Весь метод разработки является естественным и полностью соответствует опыту разработки функций JavaScript.

Пишите интерфейсы, подобные функциям JavaScript.

метаинформация функции

Используя функции JavaScript, можно описать информацию функции.

Отношение отображения между функциями JavaScript и метаинформацией интерфейса выглядит следующим образом:

• путь: имя файла + имя функции

• HTTP-метод: есть ли у функции параметры

• Тело HTTP-запроса: параметры функции

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

Встроенный вызов: API не требуется

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

Интегрированный вызов, показанный далее, покажет вам, как мы решили эту проблему и в полной мере использовали преимущества функций.

Измените интерфейс вызовов

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

В сценарии разработки, интегрированном в облако, мы надеемся изменить способ вызова всего интерфейса, действительно добиться интеграции с облаком и забыть о вызовах Api и Ajax.

Встроенный вызов: самый простой способ запросить интерфейс

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

Вызов интерфейса так же прост, как вызов обычной функции.

Получить вызов интерфейса

Постинтерфейсный вызов

Пишите интерфейсы, как обычные функции, и вызывайте интерфейсы, как обычные функции.С этого момента забудьте об Ajax и вызовах API.

Примеры внешних и внутренних вызовов

Принцип реализации

Принцип реализации встроенного вызова не сложен, мы разработали плагин компиляции на основе Webpack и Babel для преобразования внешней ссылки на функцию в HTTP-запрос.

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

Хуки: использование Node.js как React Hooks

Почему крючки

В традиционной разработке веб-приложений нам нужны не только параметры функции, но и много информации о контексте запроса, такой как заголовок запроса, метод и т. д.

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

Получить контекст запроса через хуки

Изучив опыт React Hooks, мы решили использовать Hooks для решения проблемы получения контекста запроса.

Весь API очень прост:

const ctx = useContext()

Благодаря useContext этот режим разработки и API Hook дают следующие три преимущества:

• Решена проблема получения контекста запроса в функции

• Нет необходимости вручную вводить параметры, без ущерба для связи

• Следуя методу разработки React Hooks Style, интеграция облачной интеграции — это не только интеграция структуры каталогов проекта и вызова интерфейса, но и интеграция ума разработчиков.

Вот несколько простых примеров:

С помощью Hooks мы можем разрабатывать веб-сервисы так же, как писать React Hooks.

Многоразовые крючки

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

Принцип реализации и решение проблем с производительностью

На самом деле при реализации поддержки синтаксиса Hooks есть свои нюансы.

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

• Модуль API нестабилен

• Серьезные проблемы с производительностью

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

Потеря производительности, вызванная асинхронными хуками, очень поразительна.

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

Теория компилятора не сложна, в основном следующими двумя точками:

• Получить контекст запроса: преобразовать в ссылку на этот

• Call Hooks: преобразовать в связывающий вызов, передать это вниз

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

Поскольку мы используем TypeScript, изменения в исходном коде в процессе компиляции повлияют на генерацию Source Map, поэтому мы также разработали компилятор Midway mwcc, который не только решает проблемы генерации Source Map, но и предоставляет аналогичные Babel + Babel Опыт разработки Traverse + Plugin, заинтересованные студенты могут узнать об этом самостоятельно ~

Прогрессивное развитие: Прогрессивное развитие

Когда Alibaba внедряет Node.js, она столкнется со многими сложными бизнес-сценариями. В этой части будут представлены наши методы и решения в разработке приложений уровня предприятия Node.js, а также способы повторного использования в сценарии функциональной разработки. Используйте этот раздел для ознакомления с передовыми практиками.

Практика разработки приложений Node.js корпоративного уровня Alibaba

При проектировании всего фреймворка Midway мы задумывались над вопросом: «Как решать сложные бизнес-задачи»? Ответ, который мы даем, заключается в том, чтобы обратиться к классическим принципам проектирования программного обеспечения: принципам проектирования программного обеспечения SOLID и принципу инверсии зависимостей.

В то же время мы также сослались на многие отраслевые практики и обнаружили, что зрелая конструкция IoC способна решать сложные бизнес-задачи, включая Spring Java, Nest.js/TypeOrm сообщества JS и т. д., все они используют методы реализации на основе IoC. .

Поэтому мы решили решить проблему сопровождения сложных приложений с помощью собственной разработки IoC framework в качестве ядра системы Midway.

Функциональные исследования и разработки — это решение для системы Midway, поэтому в начале проектирования мы рассмотрели интеграцию функций и системы Midway IoC, чтобы функциональные исследования и разработки могли повторно использовать лучшие практики IoC.

Объединение функционала и IoC

Здесь мы по-прежнему используем хуки для решения этой проблемы.

Мы предоставляем API useInject для использования IoC в функции через этот хук.

Таким образом, мы достигаем бесшовного сочетания функционала и IoC, от простых до сложных сценариев.

Внутренняя посадочная ситуация

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

График проекта следующий

• 2020.02: Презентация идеи и презентация POC

• 2020.03: Подтверждение основной функции и подтверждение API

• 2020.04: Приземлился первый бизнес

• 2020.05 – Сейчас: внедрены и используются несколько бизнес-процессов, и он постоянно совершенствуется.

БУ с внутренней посадкой

перспективы на будущее

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

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

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