서문에
전편 SSR 의 이점과 단점 에서 SSR 렌더링 모드의 6 대 난제를列举했습니다:
- 난제 1: 기존 CSR 코드를 어떻게 활용하여 동구를 실현할 것인가
- 난제 2: 서비스의 안정성과 성능 요구
- 난제 3: 부대시설의 건설
- 난제 4: 돈의 문제
- 난제 5: hydration 의 성��� 손실
- 난제 6: 데이터 요청
이러한 문제들은 SSR 이 지금까지 CSR 만큼 널리 응용되지 못했던 주된 이유이지만, 오늘날에 이르러, Serverless, low-code, 4G/5G 네트워크 환경이라는 3 대 기회로 인해 SSR 에 새로운 전환기가 찾아왔고,落地開花할 시기가 도래했습니다
##第一大 기회:Serverless
서버리스 컴퓨팅 (serverless computing) 은 서버 관련 설정 관리 작업을 모두 클라우드 공급자에게 맡겨 사용자의 클라우드 리소스 관리 부담을 경감합니다
클라우드 컴퓨팅 사용자에게 Serverless 서비스는 (자동으로) 탄력적 스케일링이 가능하며 명시적인 리소스 프로비저닝이 불필요하며, 클라우드 리소스 관리 부담을 면제할 뿐만 아니라 사용 상황에 따라 과금됩니다. 이 특징은 "난제 4: 돈의 문제"를很大程度上 해결합니다:
SSR 렌더링 서비스를 도입하는 것은 실제로 네트워크 구조에 하나의 노드를 추가하는 것이며, 대용량이 통과하는 곳에서는 모든 층이 돈입니다
컴포넌트 렌더링 로직을 클라이언트에서 서버로 변경하여 실행하는 것은 필연적으로 비용을 증가시키지만, Serverless 를 통해 그 비용을 최저로 낮출 수 있을 것으로 기대됩니다
다른 한편으로, Serverless Computing 의 핵심은 FaaS(Function as a Service) 로, 클라우드 함수가 일반 계산 능력을 제공합니다:
백엔드 코드를 직접 실행할 수 있으며, 서버 등의 계산 리소스나 서비스의 확장성, 안정성 등의 문제를 고려할 필요가 없고, 로그, 모니터링, 알람 등의 부대시설도开箱即用입니다
즉, FaaS 에 JavaScript 함수를 먹이면 고가용성 서비스를 온라인할 수 있습니다. 대용량 (수만 QPS) 을 어떻게 감당할지, 서비스의 안정성과 신뢰성을 어떻게 보장할지……걱정할 필요가 없습니다. 조금 시대를 초월한 것처럼 들리시나요? 실제로 AWS Lambda, 알리바바 클라우드 FC, 텐센트 클라우드 SCF 는 이미 성숙한 상업 제품이며, 무료 체험 도 가능합니다
스테이트리스한 템플릿 렌더링 작업은 특히 클라우드 함수 (React/Vue 컴포넌트를 입력하여 HTML 을 출력) 로 완료하는 데 적합하며, "난제 2: 서비스의 안정성과 성능 요구"가장 중요한 백엔드 전문성 문제가 해결되었고, SSR 이 직면한 기술적 난제는 고가용성 컴포넌트 렌더링 서비스에서 하나의 JavaScript 함수로 축소되었습니다:
클라이언트 프로그램과 비교하여, 서버 측 프로그램은 안정성과 성능에 대한 요구가 훨씬 엄격합니다. 예를 들어:
- 안정성: 이상 크래시, 무한 루프 (프론트엔드 담당자가自行 해결)
- 성능:
메모리/CPU 리소스 점유(FaaS 인프라스트럭처가 해결), 응답 속도 (네트워크 전송 거리 등도 고려해야 함)
대용량/고병발을 어떻게 대응할지, 고장을 어떻게 식별할지, 어떻게 다운그레이드/快速 회복할지(FaaS 인프라스트럭처가 해결), 어떤環節에 캐시를 추가해야 하는지, 캐시를 어떻게 업데이트할지……
FaaS 인프라스트럭처는 대부분의 성능 문제와 가용성 문제를 해결하며, 함수 내의 안정성 문제는 순수 프론트엔드 수단으로 해결할 수 있습니다. 나머지 응답 속도, 캐시/캐시 업데이트 문제에 대해서는 또 다른 클라우드 컴퓨팅 개념——엣지 컴퓨팅을 도입해야 합니다
엣지 컴퓨팅
소위 엣지 컴퓨팅이란, 계산과 데이터 스토리지를 사용자에게 더 가까운 (CDN) 노드 (또는 엣지 서버, Edge server 라고 함) 에 분산시켜, 대역폭을 절약하면서 사용자 요청에更快하게 응답하는 것입니다:
Edge computing is a distributed computing paradigm that brings computation and data storage closer to the location where it is needed, to improve response times and save bandwidth.
(Edge computing 에서 발췌)
전통적인 CDN 이 정적 콘텐츠와 최종 사용자 간의 물리적 거리를 단축하여 리소스 액세스를 가속화하고 동시에 애플리케이션 서버의 부하를 경감하는 것과 마찬가지로, 엣지 컴퓨팅을 지원하는 CDN 은 클라우드 함수를 엣지 노드에 배포하는 것을 허용하며, 서비스 응답을 가속화하고, 동시에 CDN 에 의거하여 캐시 전략을 쉽게 제어할 수 있으며, 심지어**동정분리의 엣지 플로우 렌더링 (ESR)**을 실현할 수 있습니다:
P.S. 엣지 컴퓨팅 기반 SSR 에 대한 자세한 정보는 프론트엔드 성능 최적화: 페이지 렌더링이 엣지 컴퓨팅을 만나다 참조
##第二大 기회:low-code
FaaS 가 SSR落地의 가장 핵심적인 서비스 가용성 문제를 해결하여 SSR 에 쌍익을插上했다면, low-code 는 SSR 이 천际冲向하는 것을 돕는 활주로입니다
왜냐하면low-code 는 나머지 모든 난제를 거의 해결했기때문입니다:
- 난제 1: 기존 CSR 코드를 어떻게 활용하여 동구를 실현할 것인가
난제 2: 서비스의 안정성과 성능 요구- 난제 3: 부대시설의 건설
난제 4: 돈의 문제- 난제 5: hydration 의 성능 손실
- 난제 6: 데이터 요청
소스 코드 개발 모드에서는 해결하기 어려운 문제가 low-code 모드에서는 다른 차원의 해법을 가지며, 마치 기하학적 방법으로 대수 문제를 해결하는 것과 같습니다
난제 1: 기존 CSR 코드를 어떻게 활용하여 동구를 실현할 것인가
기존 CSR 코드를 서버 측에서 실행하게 하려면 먼저 많은 문제를 해결해야 합니다. 예를 들어:
- 클라이언트 의존: API 의존과 데이터 의존 두 가지로 나뉘며, 예를 들어
window/document등의 JS API, 디바이스 관련 데이터 정보 (화면 너비 높이, 폰트 크기 등)
- 라이프사이클 차이: 예를 들어 React 에서
componentDidMount는 서버 측에서 실행되지 않습니다
- 비동기 작업이 실행되지 않음: 서버 측 컴포넌트 렌더링 프로세스는 동기이며,
setTimeout,Promise등은 기다릴 수 없습니다
- 의존 라이브러리의 적응:React, Redux, Dva 등, 심지어서드파티 라이브러리 등이 universal 환경에서 실행할 수 있는지 불확실하며, 환경을跨어 상태를 공유해야 하는지 여부. 상태 관리층을 예로 들면, SSR 은 그 store 가 직렬화 가능해야 한다고 요구합니다
- 양측에서 상태 공유: 공유가 필요한 모든 상태에 대해 (서버 측에서) 어떻게 전달할지, (클라이언트에서) 어떻게 수신할지 고려해야 합니다
먼저, low-code 모드는 소스 코드 개발과 다르며, 기존 CSR 코드를 직접 low-code 플랫폼으로 이식할 수 없습니다. 다음으로, low-code 설정화 개발 모드는天然的인 세밀한 입자도 로직 분할과 완전한 정밀 제어력을 제공합니다.体现在:
-
세밀한 입자도 로직 분할: 각 라이프사이클 함수를 독립적으로 설정
-
완전한 정밀 제어력: 의존 라이브러리, 라이프사이클, 비동기 작업, 공유 상태는 엄격히 제어되며, low-code 플랫폼이 기입된 코드의 컴파일 시, 런타임 환경을 전권 제어
클라이언트 의존은消除할 수 없지만, 함수형 프로그래밍에서의 부작용 처럼管控할 수 있으며, 예를 들어 특정 라이프사이클 함수 (componentDidMount) 에 제약하여 클라이언트에서만 실행되게 하여 서버 측에 영향을 주는 것을回避할 수 있습니다. 라이프사이클의 차이는 low-code 플랫폼을 통해 사용자에게 강한 인지를 생기게 할 수 있으며, 예를 들어 편집, 미리보기 등의環節에서 차이를 강화합니다. 지원되지 않는 비동기 작업에 대해서는 편집 단계에서 검증하고提示할 수 있습니다. 의존 라이브러리와 상태 공유 방식에 대해서는 low-code 플랫폼이 전권 제어하여 지원 범위 내에 제약할 수 있습니다
总之, low-code 는 소스 코드 개발 모드에서 골치 아픈 작성 방식을 어떻게 제약할지, 불확실성을 어떻게管控할지라는 문제를 쉽게 해결합니다
난제 3: 부대시설의 건설
SSR 의 가장 핵심적인 부분은 렌더링 서비스이지만, 그 외에도 고려해야 합니다:
- 로컬 개발 키트 (검증 + 구축 + 미리보기/HMR+ 디버깅)
- 배포 프로세스 (버전 관리)
한整套의 공정 시설은 SSR 모드에서는 모두 재고려해야 합니다
이러한 부대시설은 SSR 이 해결해야 할 문제이며, low-code 도 동일한 문제에 직면하고 있으므로, SSR 은ある程度上 low-code 가 제공하는 온라인 연구 개발 링크 지원을复用할 수 있으며, 그 일부環節만 확장하여 부대시설 건설 비용을 낮출 수 있습니다
난제 5:hydration 의 성능 손실
컴포넌트는 하나의 추상층으로서, 모듈화 개발, 컴포넌트复用 등의 공정 가치를 제공하는 동시에, 몇 가지 문제도 가져옵니다. 전형적으로, 인터랙션 로직과 컴포넌트 렌더링 메커니즘이绑定되어 있으며, 이것이 SSR 이 hydration 을 필요로 하는 근본적인 원인입니다:
클라이언트가 SSR 응답을 받은 후, (JavaScript 기반의) 인터랙션 기능을 지원하기 위해 여전히 컴포넌트 트리를 생성하여 SSR 이 렌더링한 HTML 과 연관시키고, 관련 DOM 이벤트를绑定하여 페이지를 인터랙티브하게 만들어야 합니다. 이 프로세스를 hydration 이라고 합니다
즉, 컴포넌트라는 추상층에 의존하는 한, hydration 의 성능 손실은 피할 수 없습니다. 소스 코드 개발 모드에서는 컴포넌트는 대체 불가능합니다. 그것과 동등한 추상 기술 형식이 없기 때문입니다. 그러나, low-code 모드에서는 그 출력 산물 (설정 데이터) 도 하나의 추상 기술 형식이며, 컴포넌트와 동등한 표현력을 가질 수 있다면, 컴포넌트라는 추상층을 완전히 제거할 수 있으며, 더 이상 hydration 의 성능 손실을 짊어질 필요가 없습니다
다른 한편으로, 인터랙션 없음 (순수 정적 표시), 약 인터랙션 (정적 표시에埋め込み/점프 포함) 의 편정적 장면에 대해, low-code 플랫폼도 정확하게 식별할 수 있으며, 불필요한 hydration 을回避할 수 있습니다
난제 6: 데이터 요청
서버 측 동기 렌더링은 먼저 요청을 보내고, 데이터를 받은 후에야 컴포넌트 렌더링을 시작하므로, 3 가지 문제에 직면합니다:
- 데이터 의존을 비즈니스 컴포넌트에서剥离해야 함
- 클라이언트 공参 (cookie 등 클라이언트가 기본적으로 붙이는 header 정보 포함) 이 결여
- 양측 데이터 프로토콜이 다름: 서버 측에는 더 효율적인 통신 방식이 있을 수 있음. 예를 들어 RPC
low-code 개발 모드에서는 데이터 의존이 설정화 형식으로录入되어天然的에剥离되며, 클라이언트 공参, 데이터 프로토콜 등은 low-code 플랫폼을 통해 설정할 수 있습니다. 예를 들어 HTTP, RPC 두 세트의 프로토콜을 설정하고, 환경에 따라 자동 선택합니다
##第三大 기회:4G/5G 네트워크 환경
모바일 시대 초기, 오프라인 H5 가 업계의 베스트 프랙티스였습니다. 온라인 페이지는 초 단위의 로드 시간을 의미하고, 오프라인 페이지는 거대한 로드 속도 우위를 가졌기 때문입니다
하지만 네트워크 환경의 발전에 따라, 오프라인 페이지의 로드 속도 우위는 이미 결정적 요인이 아니게 되었습니다 (미니 프로그램의 대폭발이 이를 충분히 설명합니다). 온라인 페이지의 동적화 특성이 주목받고, (SSR 이无能为力한) 오프라인 장면은 점점 줄어들며, SSR 의 출번은 점점 많아졌습니다
아직 댓글이 없습니다