предисловие

Недавно я ударился о стену, в новом проекте, разработанном компанией, я смело предложил полностью разделить фронт и бэкенд, и использовать шаблонизатор JavaScript, ajax, маршрутизацию и другие технологии для замены громоздкого фронтенда и бэкенда. смешанная бизнес-логика На полпути к проекту старшие предложили Мощь внешнего интерфейса сама по себе не может удовлетворить требования компании к поисковой оптимизации. Отказаться от предыдущей работы и переключиться на серверный механизм шаблонов скорости для рендеринга страницы и перенести фокус работы на серверную часть Java, или придерживаться полного пути разделения, но найти другой способ? В конце концов, было принято еще одно смелое решение использовать nodeJS для создания промежуточного слоя для рендеринга данных, чтобы компенсировать работу, оптимизированную для SEO, которую не могут выполнять внешние шаблонизаторы и маршрутизация. Молодой не является обязательным, ха-ха ^_^

Разделение фронтенда и бэкэнда (см. Taobao)

Что такое переднее разделение

Примером разделения фронтенда и бэкенда, с которым все согласны, является SPA (одностраничное приложение).Все используемые отображаемые данные предоставляются бэкендом через асинхронный интерфейс (AJAX/JSONP), а интерфейс просто отображает его. В некотором смысле SPA разделяет переднюю и заднюю часть, но на этом пути есть две проблемы:

• В WEB-сервисах доля класса SPA очень мала. Также во многих сценариях есть синхронный/синхронный + асинхронный гибридные режимы, и SPA не может использоваться как общее решение.

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

Разделение front-end и back-end в стиле SPA отличается от физического уровня (считается, что до тех пор, пока клиент является front-end, а server-end — back-end), этот метод разделения больше не может соответствовать нашим требованиям по разделению front-end и back-end. Мы считаем, что разделение ответственности возможно только в соответствии с нашими текущими сценариями использования:

• Внешний интерфейс: отвечает за уровни представления и контроллера.
• Серверная часть: отвечает только за уровень модели, бизнес-обработку/данные и т. д.

Зачем разделять перед и зад?

Применимые сценарии для существующих моделей развития

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

• Например, MVC на основе бэкенда очень эффективен для некоторых синхронных презентаций, но при столкновении со страницами, которые сочетают в себе синхронные и асинхронные функции, взаимодействие с бэкенд-разработкой будет более проблематичным.
• Ajax — это основная модель разработки типа SPA, которая больше подходит для разработки сценариев типа APP, но подходит только для создания приложений, потому что SEO и другие проблемы трудно решить, и этот метод разработки слишком тяжел для многих типов. систем.

Обязанности переднего и заднего плана неясны

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

Вопросы эффективности разработки

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

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

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

Ограничения на интерфейсную игру

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

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

Как разделить переднюю и заднюю части

Внешний интерфейс: отвечает за уровни представления и контроллера. Серверная часть: отвечает за уровень модели, бизнес-обработку/данные и т. д.

Представьте, если фронтенд осваивает Контроллер, мы можем делать дизайн URL, мы можем решить синхронно рендерить на сервере в соответствии со сценой или выводить данные json в соответствии с данными слоя представления, мы также можем легко сделать Bigpipe, Comet , Socket и т.д., полностью определяется спросом.

На основе разработки NodeJS с полным стеком

Если мы хотим добиться многоуровневости изображения выше, нам нужен веб-сервис, который поможет нам понять, что делал предыдущий бэкэнд, поэтому в заголовке упоминается «полная разработка стека на основе NodeJS».

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

• В режиме SPA серверная часть предоставила необходимый интерфейс данных, а внешний вид представления уже можно контролировать Зачем добавлять дополнительный уровень NodeJS?
• Добавьте еще один слой, как насчет производительности?
• Добавляя еще один слой, увеличивается ли нагрузка на интерфейс?
• Еще один слой — это еще один слой риска, как его сломать?
• NodeJS может все, зачем JAVA?

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

Зачем добавлять слой NodeJS?

На данном этапе мы в основном разрабатываем в back-end модели MVC, что серьезно снижает эффективность front-end разработки и не позволяет back-end сосредоточиться на развитии бизнеса.

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

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

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

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

Например:

После того, как страница сведений о Taobaobaobei статична, все еще остается много информации, которую необходимо получить в режиме реального времени, например, логистика, рекламные акции и т. д. Поскольку эта информация находится в разных бизнес-системах, передний конец должен отправить 5 или 6 асинхронные запросы для заполнения этого содержимого.
С NodeJS внешний интерфейс может проксировать эти 5 асинхронных запросов в NodeJS и может легко выполнять Bigpipe.Эта оптимизация может значительно повысить общую эффективность рендеринга.
Вы можете подумать, что отправка 5 или 6 асинхронных запросов на ПК — это нормально, но на беспроводной стороне создание HTTP-запроса на мобильном телефоне клиента очень дорого, с такой оптимизацией производительность повышается в несколько раз.

Увеличилась ли нагрузка на переднюю часть?

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

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

Кроме того, стоимость тестирования может сэкономить много. Все интерфейсы, разработанные в прошлом, предназначены для уровня представления, и писать тестовые примеры сложно. Если разделить front-end и back-end, можно разделить даже тесты: одна группа людей занимается тестированием интерфейса, а другая — тестированием UI (эту часть работы можно даже заменить по инструментам).

Как контролировать риски, связанные с увеличением уровня Node?

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

Node может все, зачем JAVA?

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

Разделение интерфейсной и серверной части Taobao на базе Node

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

• Под сервером находится приложение Node.

• В приложении Node есть слой Model Proxy для связи с сервером. Этот уровень в основном предназначен для сглаживания того, как мы вызываем различные интерфейсы, и для инкапсуляции некоторых моделей, требуемых уровнем представления.

• Уровень Node также может легко реализовать исходный vmcommon, tms (справочная система управления контентом Taobao) и другие требования.

• Какой фреймворк использовать для уровня Node, решать разработчику. Однако рекомендуется использовать комбинацию express+xTemplate, а xTemplate можно совместно использовать между интерфейсом и сервером.

• Каждый решает, как использовать Node, но самое интересное заключается в том, что мы, наконец, можем использовать Node для простого достижения желаемого метода вывода: JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/синхронный, асинхронный, любой, какой вы хотите. отрегулируйте это полностью зависит от вашей сцены.

• Уровень браузера не изменился в нашей архитектуре, и мы не хотим менять восприятие, которое вы использовали для разработки в браузере, из-за введения Node.

• Внедрение Node просто передало часть внешнего управления интерфейсному управлению.

Что еще нам нужно сделать?

• Интегрируйте процесс разработки Node в существующий процесс SCM Taobao.
• Создание инфраструктуры, такой как сеанс, регистратор и другие общие модули.
• лучшие практики разработки
• Истории успеха в Интернете
• Все понимают концепцию разделения клиентской и серверной частей Node.
• Безопасность
• представление

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

Суммировать

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

@ слайд-шоу«Практика разделения внешнего и внутреннего интерфейса Taobao»