Безсерверные в середине, бэкенд и фронтэнд все еще могут играть так

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

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


14-е | Сессия по развитию и продвижению интерфейса, 8-29 будет в прямом эфире, 9 лекторов (Ant Financial Services / Tax Friends и т. д.),Нажмите на меня, чтобы сесть в машину 👉 (Адрес регистрации):


Текст выглядит следующим образом

эта статьяЯвляется 44-м лектором, который говорил рано во фронт-энде, также является шестой сессией - Бессерверная сессия, которой поделился Гуан И из команды 1688 - краткая отредактированная версия речи (пожалуйста, смотрите записанное видео и PPT для полной версии, включая демо):


Введение

Обо мне, конкретное название нашей команды: Технологический отдел Alibaba CBU — Experience Technology — Marketing & Engineering Team Вся команда отвечает за интерфейсную инженерную инфраструктуру и DevOps во всем нашем CBU BU, а также за разработку весь интерфейсный маркетинг и сценарии руководства по покупкам.

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

2. Фон

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

Статус-кво мидл- и бэк-офисов, с которым мы сталкиваемся

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

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

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

Введение в бессерверные технологии

Перед концепцией Serverless г-н Чжао Бин также отметил, что она фактически разделена на две основные структуры: FaaS и BaaS.архитектура продуктаЕго можно свести к 4 характеристикам:

  • оттовар,ЭтоОн выступает за выделение ресурсов по запросу, что может полностью улучшить использование ресурсов..
  • отАрхитектура, он поддерживает вычислительный контейнер без сохранения состояния, который вы помещаете в Serverless. Например, на уровне FaaS он поддерживает функцию без сохранения состояния для функции FaaS, потому что ей удобнее расширяться и сжиматься. Таким образом, когда он расширяется и сжимается по горизонтали, это не повлияет на доступность функций в процессе расширения и сжатия из-за наличия большого количества состояний в приложении.
  • отчеловеческая точка зрения, От тенденции развития всего стека, когда все постепенно используют Node для разработки на стороне сервера, по сути, будет следовать общая тенденция, от инструментов, которые все использовали для написания CLI до появления различных веб-фреймворков. Веб-разработка.
  • отС точки зрения поставщика облачных услуг, до сих пор крупные поставщики облачных облачных услуг также начали запускать свои бессерверные решения, такие как AWS, Google, Microsoft, эти ведущие поставщики будут создавать свои собственные бессерверные решения.

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

Возможности, предоставляемые решением Gingko, очень низкоуровневы, в основном они сосредоточены на решении задач распределения и планирования всего контейнера, а также на проблемах его расширения и сжатия. На уровне доступа предоставляются три типа триггеров: RPC, HTTP и MQ. Он также поддерживает сообщения, кэш и промежуточное ПО RPC, но не имеет возможности чтения и записи собственной базы данных. Более того, возможности слоя доступа находятся внизу, аналогично унифицированной аутентификации входа, а пользовательские доменные имена, которые распространены в мидл- и бэк-офисе, не полностью поддерживаются, поэтому наша конструкция ориентирована на решение этих проблем.

3. Введение в программу

подразделение

Как показано на рисунке, фокус всего решения делится на три части:

  • Первый — построить независимый шлюз в соответствии с нашими потребностями;
  • Во-вторых, создать онлайн-платформу унифицированных процессов НИОКР;
  • В-третьих, дополнить некоторые из их существующих возможностей BaaS, которые нам нужны.

Каков поток двух основных типов пользователей в рамках этого решения?

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

В частности, давайте посмотрим, что мы сделали в середине.

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

Во-вторых, возможность предоставить ему общий внешний сервер.

В-третьих, это возможность его синхронизации и сообщений.

В соответствии с формой функций, на самом деле, это соответствует типам функций, которые поддерживают различные функции на всем Ginkgo, такие как HTTP и тип, запускаемый промежуточным программным обеспечением сообщений, Кроме того, HTTP может быть изменен для поддержки приложений. Рамки этого режима. Затем на основе этого анализа мы окончательно сформулировали такие 4 подходящие модели функций для всего среднего и закулисного сценариев. Вся функциональная модель находится во всем бессерверном.Если это рассматривать как разные слои в контейнере, то трафик сначала будет поступать на прокси-слой всего входа в контейнер, а затем в контейнере будет унифицированная среда выполнения для адаптации к нему. , Функция и связь с ним следующего контейнера обеспечивают чистый и унифицированный слой, на котором могут быть представлены разные фреймворки, а поверх этого фреймворка весь код пользователя может быть размещен в этом прогоне внутри.

После того, как весь процесс НИОКР будет иметь законченную прикладную модель, как определить, что необходимо для всего процесса НИОКР?

Обзор

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

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

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

В процессе выпуска функции может возникнуть необходимость в оттенках серого, и наверняка будет сосуществовать несколько версий.Как мы определяем, эффективна ли текущая версия? Мы разработали механизм, основанный на CommitId. Когда этой функции потребуется итерация, она обязательно изменит свой код. Весь код обязательно будет иметь уникальный CommitID на GitLab, который однозначно идентифицирует его текущее время. Итерация , может стать родословной -как вещь, чтобы отметить текущую версию.

Тогда как эта версия может быть воспринята снаружи? Мы используем способ определить маршрут по умолчанию во всем Framework, прочитать файл по заранее определенному пути, и этот файл будет содержать информацию о всей версии. Следующим наиболее важным шагом является их соединение. Весь процесс конструирования и весь процесс R&D связаны между собой.Во время всего процесса конструирования код развертываемой версии может быть вытащен вниз, а его коммит-информация может быть получена каким-то образом, а затем запихнута в соответствующее место. идти. При развертывании через URL-адрес, к которому можно получить доступ из внешней общедоступной сети, очень удобно знать, является ли текущая версия той версией, которую мы ожидали.

Еще одно очень распространенное требование заключается в том, чтобы локальная разработка поддерживала удаленную отладку. К счастью для разработки JS, Chrome предоставляет очень хороший режим поддержки точек останова, а NodeJS также предоставляет базовые возможности для разработчиков, чтобы они могли пользоваться этим удобством. Как сделать так, чтобы разработчики могли пользоваться этим удобством при разработке функций? Оглядываясь назад на многоуровневую модель функций, упомянутую выше, функции основаны на среде выполнения, а затем есть App Framework, Расширяемая платформа может облегчить нам выполнение многих задач.

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

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

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

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

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

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

Во-вторых, в промежуточных и закулисных сценариях, которые мы рассматриваем, его трафик на самом деле не так уж велик, поэтому всей их архитектуре, возможно, не нужно учитывать слишком много, например, соображения высокой доступности и экстремальной производительности, в основном это для решения проблемы. нашей сцены того времени. Так что на этой основе мы фактически позаимствовали его зрелые возможности, такие как RPC, и построили функцию на основе всего RPC.Функция может получить доступ к шлюзу всей базы данных через RPC, а затем и ко всей базе данных.Например, на Node самые базовые возможности инкапсулированы очень тонко.Это дает вам возможность удаленно выполнять кусок SQL через RPC, а затем инкапсулирует на этой основе больше возможных ORM и разных типов SQL.SDK для запросов ORM, SDK берет предыдущий пример, что нам нужно единообразно обрабатывать информацию для входа и вызывать разные промежуточные программы, инкапсулировать эти возможности в SDK, а затем встраивать в шаблон всей функции, чтобы каждый мог ее использовать.Очень унифицировано и удобно.

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

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

4. Последующее планирование

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

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

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

В этом режиме далее рассматриваем, ранее взакулисная сценаэто можем быть мыПервая другая логика,Затем определите такую ​​модель предметной областивесь процесс может быть таким, но вСцена с гидом по магазинамВ этом режиме направление нашего мышления может быть изменено на противоположное, потому что прежде всего оноуже есть такая модель,НАСЗнайте, какие модели нужны, то эту модель мы могли быНужно знать, какие поля естьА потом поверх этого поля мыЗатем используйте функциональный режим, чтобы объединить его вид на переднем плане.Что ему нужно в этом сценарии? Таким образом, эта сцена в BFF может быть более склонна быть чем-то вродеСоздать функцию из моделиРежим может быть режимом, который может сделать весь процесс разработки BFF быстрее, чем средний и фоновый.

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

Затем, например, модель, ее модель и ее многоуровневость, DDD выступает за многоуровневость модели, и какую модель мы выбираем, из нижней части всей инфраструктуры, мы сделали весь процесс раньше Весь процесс исследований и разработок всего уровня доступа функции можно отнести к уровню всей инфраструктуры, что решает задачу развития всей функции на техническом уровне. Вдобавок ко всему, вся основа лежит в домене модели домена, Прежде всего, это такой домен, который распространен в разных компаниях электронной коммерции.Различные модели могут быть определены поверх домена.,в этотповерх модели, нам нужно перейти кразрешить внешнему миру использовать эту моделькогда это может бытьдве разные идеи, первыйПредоставить сторонний пакетТочно так же SDK делает место использования зависимым от SDK. Также есть режим, который можноЕдиный режим вызова, своего родаФорма ПКР, а затем можно настроить унифицированным способом, не сильно полагаясь на этот режим SDK. Помимо всего этого вызывающего метода, это среда, в которой выполняется вся функция. На рисунке справа показан пример функции генерации функции с помощью модели, которую мы представили ранее.

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

В этой модели это в конце концов, что это внутри? Первая - очень чистая модель, например, вроде этой очень чистой товарной бизнес-модели, она не требует большой внутри бизнес-логики, ему потребуется очень четкое определение информации для каждого поля и поля, на поле некоторые очень распространенные Метод, эта модель чистого домена, а затем на вершине этого есть модель, нам нужно сделать это, чтобы порезать модель под разными сценариями View? Но процесс резания, это может быть вторичное повторное использование, это очень распространенный рисунок.

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

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

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

представление команды

Далее, давайте поиграем в рекламу. Я могу представить нашу команду как отдел технологий опыта. Отдел технологий опыта CBU на самом деле является нашим отделом перед всем CBU. Наш отдел обычно проводит много мероприятий.

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

Это может быть мисс Батиан, которую все очень любят, и она тоже входит в нашу команду. Мы на самом деле очень активны внутренне, на самом деле есть более активные одноклассники, такие как мисс Батиан.

Это до того, как мы пойдем на тимбилдинг.

Это ежедневная деятельность, и мы также будем проводить некоторые мероприятия во время Дня программиста 1024 года.

Это наше внутреннее соревнование по программированию искусственного интеллекта для автомобиля-робота на 1024. Такая ситуация во время соревнования.

В дни рождения проводится множество мероприятий.

Если вы знакомы со вторым измерением, в нашей команде также есть много учеников, которые очень скользко играют во второе измерение вот так.

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

Моя доля здесь!

В этой статье используетсяmdniceнабор текста