Suning Tesco: Размышляя о разделении интерфейсной и серверной архитектуры

Разделение фронтенда и бекенда — это, по сути, уточнение должностных обязанностей. Призывы к разделению back-end и back-end за последние два года стали звучать громче, и главная причина в том, что back-end инженеры не могут просто доделать front-end работу. Во фронтенде бесконечным потоком появлялись новые технологии, в этом случае бэкенд не может просто освоить фронтенд технологии, да и фронтенд несет определенную нагрузку.

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

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

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

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

Для компаний электронной коммерции им приходится каждый год иметь дело с различными видами деятельности, такими как Double 11, Double 12 и 418. В этом случае скорость итерации бизнеса очень высока, а обработка структуры будет очень сложной. . Еще одна проблемная технология — поддержка SEO, многие технологии SEO не поддерживаются, например нельзя использовать MVVM-фреймворки, такие как vue и react.

В основном мы используем четыре технических решения: фронтенд-шаблон (Ajax + string template), MVVM (Vue, React), Node template (Express + ejs), SSR (Node + Vue SSR). Самым старым из них является шаблонизация строк Ajax +, который, по сути, объединяет строки.

Будь то рендеринг на сервере или обычный рендеринг, поддерживается IE6+, и использование SSR или Node для рендеринга будет слабее с точки зрения совместимости с браузером. Техническое решение, основанное на современном фреймворке MVVM, также находится в невыгодном положении и не может быть использовано в случаях с высокими требованиями к совместимости браузеров.

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

Среди различных текущих технических решений очевидно, что использование Node является самым быстрым для трудоемкой отрисовки первого экрана. В конце концов, это рендеринг на стороне сервера, а данные получает сервер Node от поставщика услуг. Рендеринг SSR занимает на 30-50% больше времени, чем Node. И веб-шаблоны, и Vue считывают данные, а затем загружают их, а рендеринг Vue занимает больше времени. В целом, фреймворк MVVM является самым медленным с точки зрения трудоемкости рендеринга первого экрана.

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

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

Как промежуточная платформа, Node должен заботиться не только о front-end CDN, но и о том, не возникнут ли проблемы с сервером Node, чтобы каждая дополнительная ссылка была хуже с точки зрения высокой доступности. SSR не только предъявляет высокие требования к доступности на Node, но также вводит изоморфизм внешнего и внутреннего кода, изоморфный код может вызывать различные проблемы на Node. Исходя из этой ситуации, мы считаем, что SSR является худшим с точки зрения высокой доступности.

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

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

Говоря о внедрении фреймворка, у меня всегда возникает три вопроса: первый вопрос — нужно ли вашему проекту SEO. Если вам это нужно, Node.js — лучший выбор, но вы также должны столкнуться с рисками Node.js.В настоящее время в Node.js крайне не хватает инструментов корпоративного уровня, трудно отлаживать ошибки, меньше, чем у основных языков.

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

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

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

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

Для активных отображаемых страниц с высокими требованиями к совместимости браузера постепенно переходите с веб-шаблонов на шаблоны Node. Веб-страницы основных приложений, страницы, где преобладают требования к удобству использования, переход на решение Node + Vue.js. Некоторые страницы, ранее написанные на Vue, теперь можно постепенно перевести на решение SSR, если они совместимы с SEO и предъявляют высокие требования к производительности.

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