Автор: Сюн Хуали (Цзянсю)
Долгосрочный план Xianyu предусматривает использование Flutter и FaaS для построения будущей системы разработки технологий. Поначалу новые технологии могут показаться запутанными, поэтому их нужно постоянно обдумывать и исследовать. Более того, только практика позволит постепенно очертить контуры применения таких технологий. В этой статье излагаются наши взгляды на будущие формы программирования на основе комбинации FaaS и Flutter, а также представлены наши предварительные практики.
Интегрируйте Flutter и FaaS с Xianyu
Xianyu уже давно изучает и практикует интеграцию технологий. Мы надеемся использовать единый язык и стек технологий, чтобы инженеры-разработчики могли выполнять бизнес-разработку в любом сценарии. Таким образом, мы можем интегрировать модель разработки и стек технологий. Этот подход отражает наше стремление к эффективности разработки и расширяет возможности разработчиков, позволяя нам лучше использовать возможности наших сотрудников и стимулировать рост бизнеса.
Xianyu использовала мощные кросс-стековые возможности Flutter для унификации технологических стеков в приложениях. Такой подход уже дал предварительные результаты. Исходя из этого, мы хотим дальше интегрировать интерфейс и серверную часть и использовать Flutter для создания единого технологического стека. Развитие функции как услуги (FaaS) открывает перед нами новые перспективы и возможности. В сценариях серверной разработки FaaS отделяет среду выполнения, развертывание и O&M от рутинной разработки, позволяя разработчикам больше сосредоточиться на создании ценности для бизнеса и снижении сложности внутренней разработки. Xianyu уже создает интегрированную систему разработки Flutter + FaaS на основе этого подхода.
По мере развития технологии текущее решение будет постоянно абстрагироваться, обобщаться и уточняться. Постепенно отделяя изменяющиеся части от постоянных, разработчики могут более тщательно сосредоточиться на тех частях, которые могут быть изменены, повышая свою производительность. Таким образом, мы можем разбить систему на разные уровни и постепенно погружать нижние уровни в инфраструктуру. Это соответствует общей схеме развития технологических систем, показанной на Рисунке 1–1.
Что касается технического решения Flutter + FaaS, мы построим новый уровень инфраструктуры для интегрированной разработки поверх существующей инфраструктуры среднего уровня, чтобы сосредоточить развитие бизнеса на верхних уровнях. В этом процессе нам необходимо рассмотреть два основных вопроса:
- Какие возможности должна обеспечивать техническая система Flutter + FaaS в качестве инфраструктуры, поддерживающей интегрированную разработку?
- В какой форме будет развиваться бизнес на базе новой интегрированной инфраструктуры?
Фактически, оба вопроса представляют собой две стороны одной медали. Как только мы сможем ответить на один вопрос, станет ясен ответ на другой. Здесь мы исследуем второй вопрос.
Развитие бизнеса на базе интегрированной технической системы Flutter + FaaS
Чтобы попытаться ответить на этот вопрос, нам нужно сначала попытаться разработать абстрактное определение, реализовать его на практике, а затем обобщить и уточнить наш подход на основе итерационных практик. После этого мы можем улучшить наше абстрактное понимание проблемы и повторять процесс до тех пор, пока проблема постепенно не окажется в центре внимания.
Во-первых, давайте взглянем на текущую модель развития бизнеса, показанную на рис. 2–1. Основными проблемами в текущем шаблоне являются обработка данных, сетевая связь, управление состоянием и рендеринг пользовательского интерфейса. Исходя из этих четырех пунктов, мы можем рассмотреть изменения, которые произойдут в новом интегрированном сценарии:
- Обработка данных: относится к традиционным серверным REST API. В интегрированном сценарии обработка данных выполняется функциями FaaS. Фактически, обязанности и позиционирование этого компонента остались прежними. Вместо этого изменился только формат организационной коммуникации. При традиционной разработке разработку страницы выполняют серверные и клиентские группы. В будущем интегрированная внутренняя и внешняя разработка может выполняться одним разработчиком. Закон Конвея указывает на то, что дизайн программного обеспечения имеет тенденцию отражать коммуникационную структуру организации, поэтому мы можем увидеть серьезные изменения в этом отношении. Однако сначала мы увидим изменения в методе взаимодействия с клиентом, то есть в способе сетевой коммуникации.
- Сетевое взаимодействие. В интегрированном сценарии разработка внешнего интерфейса и внутреннего интерфейса выполняется одним человеком, поэтому в рамках проекта можно использовать одни и те же языки. В результате сетевое взаимодействие станет легким, безопасным и интуитивно понятным. Это будет напоминать обычные вызовы функций. Для этого компонента одним из возможных изменений является то, что модель взаимодействия может выйти за рамки модели клиент-сервер. В «сеансе связи» клиент и сервер смогут более естественно звонить друг другу в «одноранговом разговоре». Это заменит традиционную модель, в которой клиент отправляет запросы, а сервер отвечает на эти запросы. По мере совершенствования сетевого оборудования улучшаются возможности подключения к сети и снижаются расходы на связь. Это открывает много возможностей для инноваций.
- Управление состоянием: состояния приложения - это особые данные, кэшируемые на клиенте. Из-за изолированности технических систем, затрат на коммуникацию при разработке и затрат на сетевую связь ранее было необходимо кэшировать информацию о состоянии на клиенте. Однако в интегрированном сценарии влияние этих факторов уменьшается или устраняется. Поэтому мы хотим дополнительно удалить состояния, минимизировать усилия по управлению состоянием и перенести как можно больше управленческой работы на нижележащий уровень.
- Визуализация пользовательского интерфейса. Это область, на которую может влиять Flutter. Предлагаемый реактивный стиль и пользовательские интерфейсы, управляемые данными, соответствуют нашим идеям. Это также тенденция для фреймворков разработки пользовательского интерфейса в отрасли.
В интегрированной технической системе Flutter + FaaS разработка приложений проще, с меньшей разницей между интерфейсом и серверной частью, более легким и естественным взаимодействием и более точными обязанностями, как показано на рис. 2–2.
Интегрированные методы проектирования каркаса
В интегрированном сценарии один член бизнес-команды может выполнять как внешнюю, так и внутреннюю разработку, сводя к минимуму затраты на общение и совместную работу. Хотя крупным предприятиям неизбежно требуется сотрудничество, методы сотрудничества несколько изменятся. Вместо традиционного горизонтального разделения внешнего и внутреннего интерфейса, сотрудничество будет включать вертикальное разделение труда, основанное на интеграции внешнего интерфейса и внутреннего интерфейса, как показано на рис. 3–1. Изменения в способах сотрудничества также повлияют на наши дизайнерские идеи.
А теперь давайте представим, как мы могли бы разработать фреймворк на основе предыдущего обсуждения. Во-первых, давайте назовем бизнес, который мы хотим разработать, «История». Здесь история представляет товарный бизнес и разделена по вертикали вышеупомянутым образом. Эти вертикальные подразделения будут называться сценами. Концептуально сцена соответствует странице в традиционной разработке, но не имеет однозначного соответствия со страницей в процессе разработки продукта, как показано на рис. 3–2- (1). Сцена - это виртуальная концепция, которая объединяет фронтенд и бэкэнд-разработку, а не физический объект во время выполнения. Сцена состоит из трех частей, как показано на Рисунке 3–2- (2). Часть Model обрабатывает бизнес-данные (RawData). Конвертер преобразует бизнес-данные в данные, используемые для рендеринга (Состояние). Наконец, Render использует данные визуализации для создания и визуализации интерфейса. Модель и конвертер развертываются на сервере и выполняются в функциях FaaS. Для сравнения, Render работает на клиенте, и поток данных между ними является односторонним. В логической обработке события используются централизованно. Эти события обрабатываются локально и затем перенаправляются на другой конец. Если другой конец не обрабатывает их, события отбрасываются. Это показано на Рисунке 3–2- (3).
Сегодня истории уже используются в бизнесе Сяньюй. В следующем разделе мы рассмотрим результаты на практике.
Трудности и выводы на практике
Построить и усовершенствовать интегрированную техническую систему непросто, и на практике возникают определенные проблемы. Хорошая новость заключается в том, что FaaS и стоящая за ним бессерверная концепция уже являются тенденциями в отрасли и широко используются на практике. Интерфейсный персонал Alibaba сосредоточил свои усилия на бессерверных методах работы. Хотя это не совсем то же самое, что интеграция, многие идеи, связанные с интегрированными техническими сценариями, могут быть проверены на бессерверной практике, и это помогает оттачивать друг друга.
- Набор инструментов для разработки и развертывания. Интеграционный проект Xianyu опирается на поддержку базового набора инструментов для разработки и развертывания, который является частью инфраструктуры. Развертывание также является ключевым фактором бессерверной системы, и мы можем наблюдать соответствующие инструменты, плагины и платформы в практике фронтенд-разработчиков. Xianyu предоставляет как прямую платформу, так и собственные плагины. В долгосрочной перспективе он будет постепенно стандартизировать свою систему.
- Сквозное отслеживание и мониторинг: этот компонент является обязательным для инженеров. Xianyu напрямую извлекает выгоду из платформы Alibaba Group, но также планирует создать свои собственные инструменты для особых сценариев, таких как изучение возможностей горячего обновления функций Flutter и интегрированная локальная отладка.
Судя по всему, Xianyu также исследует другие области самостоятельно:
- Сетевое взаимодействие. Многие из наших идей предъявляют высокие требования к сетевому взаимодействию. Несомненно, мы ожидаем, что качество сети продолжит улучшаться, а затраты продолжат снижаться. Однако всегда будут сценарии, связанные с плохим подключением к сети. Таким образом, обеспечение стабильности и доступности услуг остается проблемой. Интеграция ослабит восприятие сети командой разработчиков и предоставит новые способы использования сети.
- Разделение компонентов. В компаниях Xianyu мы всегда должны рассматривать сложные страницы. В предыдущем дизайне для этой цели мы оставили часть преобразователя. Однако мы все еще изучаем, как абстрагироваться от компонентов, используемых при интеграции интерфейса и серверной части, и как их комбинировать и повторно использовать.
