Предисловие
Чтобы решить различные проблемы, вызванные традиционной моделью веб -разработки, мы предприняли много попыток, но из -за физического разрыва между передним и задним концом решения, которые мы пробовали, похожи. Учившись на боли, сегодня мы переосмыслим определение «переднего и заднего коэффициента» и вводим Nodejs, который знаком студентам, пытаясь изучить совершенно новый режим разделения фронта.
С ростом различных терминалов (PAD/Mobile/PC) разработчики все более высокие требования. Отзывчивость чистого браузера больше не может соответствовать высоким требованиям пользовательского опыта. Нам часто нужно разработать индивидуальные версии для разных терминалов. Чтобы повысить эффективность развития, потребность в разделении передних и задних концов все чаще ценится. Задняя часть отвечает за интерфейсы бизнеса/данных, передний конец отвечает за логику отображения/взаимодействия, и мы можем настроить и разработать несколько версий одного и того же интерфейса данных.
Эта тема много обсуждалась в последнее время, и некоторые автобусы Alibaba также предпринимают некоторые попытки. После долгого обсуждения наша команда решила исследовать набор схемы разделения фронтальных и бэк-энда, основанную на Nodejs. В процессе было некоторое меняющееся понимание и мысли. Я записал это здесь. Я также надеюсь, что студенты, которых я видел, участвовали в дискуссии и помогли нам улучшить ее.
1. Что такое фронтальное разделение?
Во время первоначальной дискуссии в группе я обнаружил, что у каждого другое понимание фронтального разделения. Чтобы гарантировать, что они могут обсудить на том же канале, мы сначала достигнем соглашения о том, что такое «разделение на переднем крае».
Примером разделения переднего конца, с которым все согласны, является SPA (приложение для одного страницы). Все используемые данные презентации предоставляются бэкэнд через асинхронный интерфейс (AJAX/JSONP), а только фронтальный отображает его.
В некотором смысле, SPA действительно достигает разделения фронт-конце, но есть две проблемы с этим методом:
Среди веб -услуг SPA учитывает очень небольшую долю. Во многих сценариях также существует синхронная/синхронная + асинхронная гибридная режим, и SPA не может использоваться в качестве общего решения.
В текущей модели разработки спа -салона интерфейс обычно предоставляется в соответствии с логикой презентации. Иногда, чтобы повысить эффективность, бэкэнд поможет нам справиться с какой -то логикой презентации, что означает, что бэкэнд все еще участвует в работе слоя представления, а не на реальном разделении фронта и бэкэндов.
Отделение в стиле SPA отличается от физического слоя (думайте, что до тех пор, пока он является клиентом, фронт-конце, а бэк-энд-сервер). Эта классификация больше не может соответствовать нашим потребностям в фронтальном разделении. Мы считаем, что только разделив обязанности мы можем выполнить наши текущие сценарии использования:
Фронт-Энд: Отвечает за просмотр и контроллерные слои.
Бэкэнд: Отвечает только за уровень модели, бизнес -обработку/данные и т. Д.
Почему это разделение обязанностей будет обсуждаться позже.
2. Почему мы должны разделить передние и задние концы?
Что касается этой проблемы, в статье Ю -Бо очень всесторонне объясняет его в эволюции модели веб -исследований и разработок. Давайте кратко рассмотрим это:
2.1 Применимые сценарии для существующих моделей разработки
Модели разработки, упомянутые Yu Bo, у каждого есть свои применимые сценарии, и ни один из них не полностью заменит другой.
Например, для MVC, который в основном основан на бэкэнде, очень эффективно выполнять какой -то синхронный бизнес -бизнес, но при столкновении с синхронной и асинхронной страницей будет более хлопотно общаться с развитием бэкэнд.
Ajax является основной моделью разработки спа-салонов, которая более подходит для разработки сценариев типа приложений, но она подходит только для создания приложений, потому что SEO и другие проблемы трудно решить. Для многих типов систем этот метод разработки также слишком тяжелый.
2.2 Обязанности передней и задней части неясны
В системах со сложной бизнес -логикой мы больше всего боимся поддерживать код, смешанный с передним и задним концом. Поскольку не существует ограничений, код других слоев MVC может появляться в каждом уровне. Со временем не существует технического обслуживания вообще.
Хотя разделение передних и задних концов не может полностью решить эту проблему, это может быть значительно облегчено. Потому что это гарантировано с физического уровня, что вы не можете этого сделать.
2.3 Проблемы с эффективностью развития
Интернет Taobao в основном основан на Webx Mvc Framework, и архитектура определяет, что фронт может только полагаться на бэк-энд.
Таким образом, наша модель разработки по-прежнему заключается в том, что фронт-конце пишет статические демонстрации, а задняя часть переводит их в шаблоны виртуальных машин. Я не буду говорить о проблеме с этой моделью, и меня долгое время критиковали.
Также больно напрямую разрабатывать на основе среды, и это трудно настроить, устанавливать и использовать. Чтобы решить эту проблему, мы изобрели различные инструменты, такие как Vmarket, но фронт-энд все еще должен писать виртуальные машины и полагаться на данные о движении, поэтому эффективность все еще не высока.
Кроме того, бэкэнд не может избавиться от сильного фокуса на демонстрации и, таким образом, сосредоточиться на разработке слоя бизнес -логики.
2.4 Ограничения на эксплуатацию
Если оптимизация производительности выполняется только на передней части, нам часто нужно сотрудничество в бэкэнд, чтобы создать искры. Однако из -за ограничений бэкэнд -структуры нам трудно использовать Comet, Bigpipe и другие технические решения для оптимизации производительности.
Чтобы решить некоторые из упомянутых выше проблем, мы предприняли много попыток и разработали различные инструменты, но никогда не было большого улучшения, главным образом потому, что мы можем использовать только небольшой кусочек пространства, разделенного нами в бэкэнде. Только по -настоящему разделяя передние и задние концы, мы можем полностью решить вышеуказанные проблемы.
3. Как разделить передние и задние концы?
Как разделить переднюю и заднюю концы? На самом деле, в первом разделе есть ответ:
Фронт-Энд: Отвечает за просмотр и контроллерные слои.
Бэкэнд: Отвечает за модельный уровень, бизнес -обработка/данные и т. Д.
Представьте себе, что если передний интерфейс магистр контроллера, мы можем выполнить дизайн URL-адреса, мы можем решить, следует ли синхронизировать рендеринг на сервере в соответствии с сценой или вывести данные JSON на основе данных уровня представления, и мы также можем легко выполнить большую трубу, комету, гнездо и т. Д. В соответствии с потребностями уровня презентации. Это полностью метод использования, определяемый требованиями.
3.1 Разработка «Полный стек» на основе Nodejss
Если вы хотите реализовать наслоение приведенного выше рисунка, вам неизбежно понадобится веб-сервис, который поможет нам понять, что мы делаем до и после бэкэнда, так что есть заголовок «Разработка полного стека на основе Nodejs»
Эта картина выглядит просто и легко для понимания, но она не пробовала, и будет много вопросов.
В режиме спа -салона бэкэнд предоставил необходимый интерфейс данных, а фронта просмотра уже можно контролировать. Зачем добавлять слой Nodejs?
Как насчет добавления еще одного слоя?
Добавление еще одного слоя увеличит рабочую нагрузку на фронт?
Добавление еще одного слоя приведет к другому уровню риска. Как это сломать?
Nodejs может что -нибудь сделать, почему вам все еще нужна Java?
Нелегко объяснить эти проблемы четко. Позвольте мне поговорить о моем процессе понимания ниже.
3.2 Зачем добавлять слой Nodejs?
На этом этапе мы в основном разрабатываем модель MVC Backend. Эта модель серьезно препятствует эффективности фронт-элитной разработки и не позволяет концентрации сосредоточиться на развитии бизнеса.
Решение состоит в том, чтобы дать возможность передней части управлять уровнем контроллера, но трудно сделать это в рамках существующей технологической системы, потому что невозможно позволить всем фронтальным исследованиям изучать Java, установить среду развития среды и написать виртуальные машины.
Nodejs могут очень хорошо решить эту проблему. Мы можем сделать то, что разработка помогла нам делать раньше, и все кажется таким естественным.
3.3 Проблемы с производительностью
Слои включает в себя связь между каждым слоем, и определенно будут определенные потери производительности. Тем не менее, разумная стратификация может сделать обязанности четкими и совместными, что значительно повысит эффективность развития. Потери, вызванные стратификацией, определенно будут компенсированы в других аспектах.
Кроме того, как только мы решим связать, мы можем минимизировать потери, оптимизируя методы связи и протоколы связи.
Например:
После того, как страница «Детские данные» Taobao станет статичной, есть еще много информации, которую необходимо получить в режиме реального времени, такую как логистика, рекламные акции и т. Д. Поскольку эта информация находится в различных бизнес-системах, фронт-энд должен отправлять 5 или 6 асинхронных запросов, чтобы заполнить это содержание.
С Nodejs передний конец может прокси-сервер в этих 5 асинхронных запросах в Nodejs и может легко выполнять большую трубу. Эта оптимизация может значительно повысить эффективность рендеринга.
Вы можете подумать, что можно отправить 5 или 6 асинхронных запросов на ПК, но на беспроводной стороне очень дорого установить HTTP -запрос на мобильном телефоне клиента. С этой оптимизацией производительность в несколько раз улучшается.
Детали Taobao основаны на оптимизации Nodejs. Мы в процессе. После того, как он будет запущен, я поделюсь процессом оптимизации.
3.4 Увеличена ли передняя рабочая нагрузка?
По сравнению с просто разрезанием страниц/демонстраций, это должно быть немного больше, но в текущем режиме есть связи и связь. Этот процесс занимает много времени, склонна к ошибкам, и его трудно поддерживать.
Поэтому, хотя рабочая нагрузка немного увеличится, общая эффективность развития будет значительно улучшена.
Кроме того, затраты на тестирование можно много сэкономить. Интерфейсы, разработанные в прошлом, направлены на уровень презентации, и трудно написать тестовые примеры. Если разделение передней и задней части выполнено, даже тест может быть разделен. Одна группа людей специализируется на тестировании интерфейса, а другая группа людей фокусируется на тестировании пользовательского интерфейса (эта часть работы может быть даже заменена инструментами).
3.5 Как контролировать риски, приведенные путем добавления слоя узла?
Благодаря широкомасштабному использованию узла студенты из отделения системы/эксплуатации и технического обслуживания/безопасности обязательно присоединятся к строительству инфраструктуры. Они помогут нам улучшить возможные проблемы в каждой ссылке и обеспечить стабильность департамента.
3.6 Узел может сделать что -нибудь, почему вам все еще нужна Java?
Наше первоначальное намерение - отделить передние и задние концы. Если мы рассмотрим эту проблему, это будет немного противоречить нашему первоначальному намерению. Даже если мы используем узел для замены Java, мы не можем гарантировать, что мы не столкнемся с какими -либо проблемами, с которыми мы сталкиваемся сегодня, такие как неясные обязанности. Наша цель - развиваться многоуровневым образом, профессиональных людей и сосредоточиться на занятиях профессиональными вещами. Инфраструктура, основанная на Java, уже очень мощная и стабильная, и более подходит для того, чтобы делать то, что сейчас является архитектурой.
4. Отделение на основе узлов Taobao на основе узлов
Приведенная выше картина-это то, что я понимаю на фронтальном и контрольном разделении и наслоении Таобао, а также на сфере обязанностей узла. Краткое объяснение:
Верхняя часть - это сервер, который мы часто называем бэкэнд. Для нас бэкэнд представляет собой набор интерфейсов, а сервер предоставляет различные интерфейсы для нас. Поскольку есть слой узла, нет необходимости ограничивать, какую форму обслуживания он. Для разработки бэкэнд они используют только интерфейсы, которые заботятся о бизнес -коде.
Сервер находится под приложением узла.
В приложении узла есть уровень модели прокси, который связывается с сервером. Этот слой в основном используется для сглаживания того, как мы называем разные интерфейсы, и инкапсулируют некоторые модели, необходимые для слоя представления.
Узел узел также может легко достичь исходного VMCommon, TMS (цитируя систему управления контентом Taobao) и другие требования.
Какую структуру использовать для слоя узла зависит от разработчика. Тем не менее, рекомендуется использовать комбинацию Express + xtemplate, которая может быть использована для передней и задней части.
Все решают, как использовать узел, но увлекательно, что мы можем, наконец, использовать узел, чтобы легко реализовать метод вывода, который мы хотим: JSON/JSONP/RESTFUL/HTML/BIGPIPE/COMET/SOCKET/SYNCHRONOUS и Asynchrony. Это может быть сделано все, что вы хотите, и это определяется полностью на вашем сценарии.
Уровень браузера не изменился в нашей архитектуре, и мы не хотим менять ваше предыдущее понимание развития в браузере из -за введения узла.
Внедрение узла просто для того, чтобы передать переднюю часть управления, которая должна контролироваться передней частью.
У нас есть два проекта в разработке в этой модели. Хотя они еще не были запущены, мы уже попробовали сладость с точки зрения эффективности разработки и оптимизации производительности.
5. Что еще нам нужно сделать?
Интегрируйте процесс разработки узла в существующий процесс SCM от Taobao.
Строительство инфраструктуры, такая как сеанс, логист и другие общие модули.
Лучшие методы развития
Истории успеха в Интернете
Понимание каждого концепции разделения узлов спереди и задних концов
Безопасность
производительность
…
Не будет слишком много технологий, которые нуждаются в инновациях и исследованиях, и было много готового накопления. Фактически, ключом является открытие некоторых процессов и накопление общих решений. Я считаю, что при большей практике проекта эта область постепенно станет стабильным процессом.
6. "Midway Island"
Хотя модель «Полная разработка, основанная на Nodejs», является захватывающей, еще предстоит преобразовать разработку полного стека на основе узла в то, что каждый может принять. Наш постоянный проект «Midway» предназначен для решения этой проблемы. Хотя мы не долго, мы становимся ближе и ближе к нашей цели! !