머리말
전통적인 웹 개발 모델로 가져온 다양한 문제를 해결하기 위해 많은 시도를했지만 앞면과 후면 사이의 물리적 차이로 인해 우리가 시도한 솔루션은 비슷합니다. 고통으로부터 배우면서 오늘 우리는 "프론트 엔드"의 정의를 다시 생각하고 프론트 엔드 학생들에게 친숙한 새로운 프론트 엔드 분리 모드를 탐색하려는 Nodejs를 소개합니다.
다른 터미널 (PAD/Mobile/PC)이 증가함에 따라 개발자는 점점 더 높은 요구 사항을 가지고 있습니다. 순수한 브라우저 측의 응답 성은 더 이상 사용자 경험의 높은 요구 사항을 충족시킬 수 없습니다. 우리는 종종 다른 터미널을 위해 맞춤형 버전을 개발해야합니다. 개발 효율성을 향상시키기 위해 전면 및 후면의 분리의 필요성이 점점 더 가치가 있습니다. 백엔드는 비즈니스/데이터 인터페이스를 담당하며 프론트 엔드는 디스플레이/상호 작용 로직을 담당하며 동일한 데이터 인터페이스의 여러 버전을 사용자 정의하고 개발할 수 있습니다.
이 주제는 최근에 많이 논의되었으며 일부 알리바바 버스도 약간의 시도를하고 있습니다. 긴 토론 후, 우리 팀은 NodeJS를 기반으로 한 프론트 엔드 및 백엔드 분리 체계 세트를 탐색하기로 결정했습니다. 그 과정에서 변화하는 이해와 생각이있었습니다. 나는 그것을 여기에 기록했다. 또한 내가 본 학생들이 토론에 참여하고 우리가 그것을 개선하는 데 도움이되기를 바랍니다.
1. 프론트 엔드 분리 란 무엇입니까?
그룹 내에서의 초기 토론에서 나는 모든 사람들이 프론트 엔드 분리에 대해 다른 이해를 가지고 있음을 발견했습니다. 동일한 채널에서 논의 할 수 있도록 먼저 "전면 백 렌트 분리"에 대한 계약에 도달 할 것입니다.
모든 사람이 동의하는 프론트 엔드 분리의 예는 SPA (단일 페이지 응용 프로그램)입니다. 사용 된 모든 프리젠 테이션 데이터는 비동기 인터페이스 (AJAX/JSONP)를 통해 백엔드에 의해 제공되며 프론트 엔드는이를 표시합니다.
어떤 의미에서 SPA는 프론트 엔드 분리를 달성하지만이 방법에는 두 가지 문제가 있습니다.
웹 서비스 중 스파는 매우 적은 비율을 차지합니다. 많은 시나리오에는 동기/동기 + 비동기 하이브리드 모드도 있으며 SPA는 일반적인 솔루션으로 사용할 수 없습니다.
현재 스파 개발 모델에서, 인터페이스는 일반적으로 프리젠 테이션 로직에 따라 제공됩니다. 때로는 효율성을 향상시키기 위해 백엔드가 일부 프리젠 테이션 로직을 처리하는 데 도움이 될 것입니다. 즉, 백엔드는 여전히 전면 및 백엔드의 실제 분리가 아니라 뷰 레이어의 작업에 관여합니다.
스파 스타일의 프론트 엔드 분리는 물리적 레이어와 구별됩니다 (클라이언트, 프론트 엔드 및 백엔드가 서버라고 생각합니다). 이 분류는 더 이상 프론트 엔드 분리에 대한 우리의 요구를 충족시킬 수 없습니다. 우리는 책임을 분할하여 현재 사용 시나리오를 충족시킬 수 있다고 생각합니다.
프론트 엔드 :보기 및 컨트롤러 레이어를 담당합니다.
백엔드 : 모델 계층, 비즈니스 처리/데이터 등을 담당합니다.
이 책임 부서가 나중에 논의되는 이유는 무엇입니까?
2. 왜 우리는 앞면과 후면을 분리해야합니까?
이 문제와 관련하여 Yu Bo의 기사는 웹 R & D 모델의 진화에서 매우 포괄적으로 설명합니다. 간단히 검토합시다 :
2.1 기존 개발 모델에 대한 적용 가능한 시나리오
Yu Bo가 언급 한 개발 모델은 각각 고유 한 적용 가능한 시나리오를 가지고 있으며, 그 중 어느 것도 완전히 대체하지 않습니다.
예를 들어, 주로 백엔드를 기반으로하는 MVC의 경우 동기식 디스플레이 비즈니스를 수행하는 것이 매우 효율적이지만 동기 및 비동기 페이지를 만나면 백엔드 개발과 통신하는 것이 더 번거 롭습니다.
Ajax는 주요 스파 개발 모델로 앱 유형 시나리오를 개발하는 데 더 적합하지만 SEO 및 기타 문제를 해결하기가 어렵 기 때문에 앱을 만드는 데만 적합합니다. 많은 유형의 시스템 에서이 개발 방법도 너무 무겁습니다.
2.2 프론트 엔드 책임은 불분명합니다
복잡한 비즈니스 논리가있는 시스템에서는 전면 및 후면 끝과 혼합 된 코드를 유지하는 것을 가장 두려워합니다. 제약이 없기 때문에 MVC의 다른 레이어 코드가 각 층에 나타날 수 있습니다. 시간이 지남에 따라 유지 보수가 전혀 없습니다.
전면 및 후면의 분리 가이 문제를 완전히 해결할 수는 없지만 크게 완화 될 수 있습니다. 물리적 수준에서 보장되기 때문에이 작업을 수행 할 수 없기 때문입니다.
2.3 개발 효율성 문제
Taobao의 웹은 기본적으로 MVC 프레임 워크 Webx를 기반으로하며, 아키텍처는 프론트 엔드가 백엔드에만 의존 할 수 있다고 결정합니다.
따라서 우리의 개발 모델은 여전히 프론트 엔드가 정적 데모를 쓰고 백엔드가 VM 템플릿으로 변환하는 것입니다. 나는이 모델의 문제에 대해 이야기하지 않을 것이며 오랫동안 비난을 받았습니다.
또한 백엔드 환경을 기반으로 직접 개발하는 것이 고통스럽고 구성, 설치 및 사용이 어려운 문제입니다. 이 문제를 해결하기 위해 vmarket과 같은 다양한 도구를 발명했지만 프론트 엔드는 여전히 VM을 작성하고 백엔드 데이터에 의존해야하므로 효율성은 여전히 높지 않습니다.
또한 백엔드는 디스플레이에 대한 강력한 초점을 없애고 비즈니스 로직 계층의 개발에 중점을 둘 수 없습니다.
2.4 프론트 엔드 성능에 대한 제한
성능 최적화가 프론트 엔드에서만 수행되면 종종 스파크를 만들기 위해 백엔드 협력이 필요합니다. 그러나 백엔드 프레임 워크의 한계로 인해 혜성, BigPipe 및 기타 기술 솔루션을 사용하여 성능을 최적화하기가 어렵습니다.
위에서 언급 한 몇 가지 문제를 해결하기 위해 많은 시도를하고 다양한 도구를 개발했지만, 우리는 백엔드에서 우리로 분할 된 작은 공간 만 사용할 수 있기 때문에 크게 개선되지 않았습니다. 앞면과 후면을 진정으로 분리함으로써 만 위의 문제를 완전히 해결할 수 있습니다.
3. 전면과 후면을 분리하는 방법은 무엇입니까?
전면과 후면을 분리하는 방법은 무엇입니까? 실제로 첫 번째 섹션에는 답이 있습니다.
프론트 엔드 :보기 및 컨트롤러 레이어를 담당합니다.
백엔드 : 모델 계층, 비즈니스 처리/데이터 등을 담당합니다.
프론트 엔드가 컨트롤러를 마스터하고 URL 디자인을 수행 할 수 있다면 장면에 따라 서버의 렌더링을 동기화할지 또는 뷰 레이어 데이터를 기반으로 JSON 데이터를 출력할지 여부를 결정할 수 있으며 프리젠 테이션 레이어의 요구에 따라 BigPipe, Comet, Socket 등을 쉽게 수행 할 수 있습니다. 전적으로 요구 사항에 의해 결정된 사용 방법입니다.
3.1 Nodejs를 기반으로 한 "풀 스택"개발
위의 그림의 레이어링을 구현하려면 백엔드 전후에 수행 한 작업을 실현하는 데 도움이되는 웹 서비스가 필요하므로 "Nodejs를 기반으로 한 풀 스택 개발"이 있습니다.
이 사진은 간단하고 이해하기 쉽지만 시도하지 않았으며 많은 질문이있을 것입니다.
SPA 모드에서 백엔드는 필요한 데이터 인터페이스를 제공했으며 View Frontend를 이미 제어 할 수 있습니다. Nodejs 레이어를 추가하는 이유는 무엇입니까?
레이어를 하나 더 추가하는 것은 어떻습니까?
하나 더 층을 추가하면 프론트 엔드의 워크로드가 증가할까요?
하나 더 층을 추가하면 또 다른 위험이 있습니다. 그것을 깨는 방법?
nodejs는 무엇이든 할 수 있습니다. 왜 여전히 Java가 필요합니까?
이러한 문제를 명확하게 설명하는 것은 쉽지 않습니다. 아래의 이해 과정에 대해 이야기하겠습니다.
3.2 왜 nodejs 층을 추가합니까?
이 단계에서 우리는 주로 백엔드 MVC 모델을 개발합니다. 이 모델은 프론트 엔드 개발의 효율성을 심각하게 방해하고 백엔드가 비즈니스 개발에 중점을 두지 못하게합니다.
솔루션은 프론트 엔드가 컨트롤러 계층을 제어 할 수 있도록하는 것이지만, 모든 프론트 엔드가 Java를 배우고 백엔드 개발 환경을 설치하고 VM을 쓰는 것은 불가능하기 때문에 기존 기술 시스템에서 수행하기가 어렵습니다.
Nodejs는이 문제를 매우 잘 해결할 수 있습니다. 우리는 개발이 우리가 이전에하는 일을 할 수 있으며 모든 것이 자연스럽게 보입니다.
3.3 성능 문제
레이어링에는 각 계층 간의 통신이 포함되며, 특정 성능 손실이 분명히있을 것입니다. 그러나 합리적인 계층화는 책임을 명확하고 협력 할 수있어 개발 효율성을 크게 향상시킬 수 있습니다. 계층화로 인한 손실은 다른 측면에서 확실히 보상 될 것입니다.
또한 일단 연결하기로 결정하면 통신 방법 및 커뮤니케이션 프로토콜을 최적화하여 손실을 최소화 할 수 있습니다.
예를 들어:
Taobao 베이비 세부 사항 페이지가 정적 인 경우 물류, 프로모션 등과 같이 실시간으로 얻어야하는 많은 정보가 여전히 있습니다.이 정보는 다른 비즈니스 시스템에 있기 때문에 프론트 엔드는 5 개 또는 6 개의 비동기적인 요청을 이러한 내용을 역류하기 위해 보내야합니다.
Nodejs를 사용하면 프론트 엔드는 Nodejs에서 이러한 5 개의 비동기 요청을 프록시 할 수 있으며 쉽게 큰 파이프를 수행 할 수 있습니다. 이 최적화는 전체 렌더링 효율을 많이 향상시킬 수 있습니다.
PC에서 5 개 또는 6 개의 비동기 요청을 보내는 것이 좋다고 생각할 수도 있지만 무선 측면에서는 고객의 휴대 전화에서 HTTP 요청을 설정하는 데 비용이 많이 듭니다. 이 최적화를 통해 성능이 여러 번 향상됩니다.
Taobao 세부 사항은 NodeJS 최적화를 기반으로합니다. 우리는 진행 중입니다. 출시 후 최적화 프로세스를 공유하겠습니다.
3.4 프론트 엔드 워크로드가 증가 했습니까?
페이지/데모를 절단하는 것과 비교할 때 조금 더 있어야하지만 현재 모드에는 연결 및 통신이 있습니다. 이 과정에는 많은 시간이 걸리고 버그가 발생하기 쉬우 며 유지하기가 어렵습니다.
따라서 워크로드가 약간 증가하지만 전반적인 개발 효율이 크게 향상됩니다.
또한 테스트 비용을 많이 절약 할 수 있습니다. 과거에 개발 된 인터페이스는 모두 프레젠테이션 계층을 목표로하며 테스트 케이스를 작성하기가 어렵습니다. 프론트 및 백엔드 분리가 완료되면 테스트조차 분리 할 수 있습니다. 한 그룹의 사람들이 인터페이스 테스트를 전문으로하고 다른 그룹의 사람들은 UI 테스트에 중점을 둡니다 (이 부분은 도구로 대체 될 수 있음).
3.5 노드 레이어를 추가하여 가져 오는 위험을 제어하는 방법은 무엇입니까?
노드를 대규모로 사용하면 시스템/운영 및 유지 보수/보안 부서의 학생들은 인프라 구성에 확실히 참여할 것입니다. 그들은 각 링크에서 가능한 문제를 개선하고 부서의 안정성을 보장하는 데 도움이됩니다.
3.6 노드는 무엇이든 할 수 있습니다. 왜 여전히 Java가 필요합니까?
우리의 원래 의도는 전면과 후면을 분리하는 것입니다. 이 문제를 고려하면 원래 의도와 약간 상반됩니다. 우리가 노드를 사용하여 Java를 대체하더라도, 우리는 불분명 한 책임과 같은 오늘날에 발생하는 문제에 직면하지 않을 것이라고 보장 할 수 없습니다. 우리의 목표는 층상, 전문가, 전문적인 일에 집중하는 것입니다. Java를 기반으로 한 인프라는 이미 매우 강력하고 안정적이며 현재 아키텍처를 수행하는 데 더 적합합니다.
4. Taobao의 노드 기반 프론트 엔드 분리
위의 그림은 노드를 기반으로 Taobao의 프론트 엔드 및 백엔드 분리 및 레이어링과 노드의 책임 범위에서 이해하는 것입니다. 간단한 설명 :
상단은 서버입니다. 우리가 종종 백엔드라고 부르는 것입니다. 우리에게 백엔드는 인터페이스 모음이며 서버는 우리가 사용할 다양한 인터페이스를 제공합니다. 노드 레이어가 있으므로 서비스 형태의 서비스를 제한 할 필요가 없습니다. 백엔드 개발을 위해서는 비즈니스 코드에 관심이있는 인터페이스 만 사용합니다.
서버는 노드 애플리케이션 아래에 있습니다.
노드 애플리케이션에는 서버와 통신하는 모델 프록시 레이어가 있습니다. 이 레이어는 주로 다른 인터페이스를 부르는 방식을 부드럽게하고 뷰 레이어에 필요한 일부 모델을 캡슐화하는 데 사용됩니다.
노드 레이어는 원래 Vmcommon, TMS (Taobao Content Management System 인용) 및 기타 요구 사항을 쉽게 달성 할 수 있습니다.
노드 레이어에 사용할 프레임 워크는 개발자에게 결정됩니다. 그러나 전면 및 후면에 사용할 수있는 Express + Xtemplate의 조합을 사용하는 것이 좋습니다.
모든 사람이 노드를 사용하는 방법을 결정하지만 흥미로운 점은 결국 노드를 사용하여 원하는 출력 방법을 쉽게 구현할 수 있다는 것입니다. 원하는대로 수행 할 수 있으며 시나리오를 기반으로 전적으로 결정됩니다.
아키텍처에서 브라우저 레이어가 변경되지 않았으며 노드 도입으로 인해 브라우저의 개발에 대한 이전 이해를 변경하고 싶지 않습니다.
노드를 소개하는 것은 프론트 엔드에 의해 제어되어야하는 프론트 엔드 제어 부품을 넘겨주는 것입니다.
이 모델에는 두 가지 프로젝트가 개발되었습니다. 그들이 아직 출시되지는 않았지만, 우리는 이미 개발 효율성과 성능 최적화 측면에서 단맛을 맛 보았습니다.
5. 우리는 또 무엇을해야합니까?
노드의 개발 프로세스를 Taobao의 기존 SCM 프로세스에 통합하십시오.
세션, 로거 및 기타 일반 모듈과 같은 인프라 구성.
최고의 개발 관행
온라인 성공 사례
노드 전면 및 뒷부분 분리 개념에 대한 모든 사람의 이해
안전
성능
…
혁신과 연구가 필요한 기술은 너무 많지 않을 것이며, 기성품 축적이 많이있었습니다. 실제로, 핵심은 일부 프로세스를 개방하고 일반 솔루션의 축적입니다. 나는 더 많은 프로젝트 관행을 통해이 분야는 점차 안정적인 과정이 될 것이라고 생각합니다.
6. "미드웨이 섬"
"Nodejs를 기반으로 한 풀 스택 개발"모델은 흥미 진진하지만, 노드를 기반으로 풀 스택 개발을 모든 사람이 받아 들일 수있는 것으로 바꾸는 것이 여전히 많습니다. 우리의 진행중인 "미드웨이"프로젝트는이 문제를 해결하는 것입니다. 우리는 얼마 지나지 않지만 목표에 점점 더 가까워지고 있습니다! !