타오바오 홈페이지 기본지식
타오바오 홈페이지에 대한 기본지식
많은 분들이 타오바오를 이용하시지만, 타오바오 홈페이지에 대해 잘 모르시는 분들이 많은데요. 타오바오 홈페이지 디자이너의 설명을 가져오면 좋겠습니다. 타오바오 홈페이지에 대한 기본적인 이해를 하시면 도움이 될 것입니다.
1. 관련 배경 소개
타오바오 홈페이지는 타오바오의 정면으로, 트래픽과 주문이 많은 거의 모든 타오바오 사업체의 입구를 전달합니다. 수십억의 크기 단위. 최근에는 무선 단말기의 등장으로 사업의 중심이 무선 단말기로 옮겨가기 시작했고(지금은 전환이라고 할 수 없고 기본적으로 무선임) 타오바오 PC 홈페이지의 트래픽도 줄어들었지만, 그럼에도 불구하고 일일 평균 PV는 여전히 상당히 높습니다.
타오바오 홈페이지는 항상 내부 플랫폼과 기술의 시험장이었고, 항상 변화하고 있습니다. 최신 프레임워크와 시스템이 타오바오 홈페이지에서 시범적으로 운영될 예정입니다. 추진해야 할 특정 업그레이드나 최적화 조치가 타오바오 홈페이지에 출시되어 좋은 데이터와 안정성이 확보되었다면 왜 다른 기업에서 이를 사용하지 않겠습니까? 시도와 변화는 어떤가? 동시에 작년에 타오바오의 프론트엔드를 담당했던 기술 아키텍처 팀이 자연스럽게 사업에 실험적인 콘텐츠를 추진하게 됐다.
너무 바빠요. 실제로 대부분의 페이지는 내부 구축 플랫폼(모듈 구성을 통한 운영 또는 프런트엔드)을 기반으로 구축되며, 프런트엔드 초점은 플랫폼 자체의 구축과 플랫폼의 다양성 및 재사용률 보장에 있습니다. 물론 모듈과 일부 엔지니어링 관련 내용도 포함됩니다.
빌딩 플랫폼을 사용하여 구축된 페이지의 경우 프런트엔드는 페이지를 구성하는 원자 모듈의 개발만 고려하면 됩니다. 전체 렌더링은 빌딩 플랫폼에서 제공하는 통합 스크립트를 전적으로 담당합니다. . 타오바오 홈페이지에서는 엄청난 수의 페이지 모듈과 적은 양의 부서 간, 팀 간 커뮤니케이션을 고려하여 렌더링 모델이 약간 다릅니다.
2. 타오바오 홈페이지의 전체적인 변화
배경에서도 언급했듯이 타오바오 홈페이지는 내부 구축 플랫폼에 의존하고 있으며, 그 변화는 자연스럽게 구축 시스템의 변화를 따르게 됩니다.
1. PHP 기반의 타오바오 홈페이지
타오바오 홈페이지를 인수한 지 얼마 되지 않아 연간 개정판이 나왔습니다. 당시에는 여전히 PHP 환경에서 운영되고 있었습니다. 여기서 설명해야 할 것은 타오바오 홈페이지의 모든 코드는 프런트 엔드에 의해 완전히 제어된다는 것입니다. 프런트 엔드는 데이터베이스를 직접 처리하지 않으며 데이터 소스가 두 부분으로 나누어져 있습니다.
데이터 소스
먼저 작업을 통해 채워지는 데이터입니다. 프론트엔드 굴착 형태에서는 운영자가 데이터를 획득하고 채울 수 있도록 구덩이가 예약되어 있습니다.
운영자가 이러한 구덩이를 채우면 이 PHP 템플릿에 해당하는 데이터가 생성되고 최종 렌더링이 이루어집니다. 완전한 HTML 조각(실시간 렌더링)이 됩니다.
이전 버전의 빌딩 시스템에서는 서브모듈이 이런 방식으로 구성되었습니다. 아주 간단하게 설명했지만 플랫폼으로서는 데이터 순서 제어, 출시 예정, 롤백 메커니즘, 필터링 메커니즘, 데이터 동기화, 데이터 업데이트, 버전 제어, 권한 제어, 다른 시스템에 대한 참조 등 많은 것을 고려해야 합니다. .
두 번째는 백엔드나 개인화 플랫폼에서 제공하는 데이터입니다. 기업마다 요구 사항이 다릅니다. 일부 기업은 자체 백엔드를 가지고 있으며 자체 기업에서 생성된 데이터를 사용해야 합니다. 일부 기업은 사용자가 다른 콘텐츠를 보기를 희망하고 일부 기업은 판매자와 직접 거래하고 사용할 것으로 기대합니다. 투자 촉진 데이터; 그리고 일부 기업은 데이터 풀에서 필터링된 데이터를 사용할 것으로 예상합니다... 간단히 말해서, 타오바오의 홈페이지는 다양한 시스템과 연결되어야 하고 많은 인터페이스를 가지고 있습니다. 동적 데이터 소스의 통합에 대해서는 나중에 언급하겠습니다.
그리고 이러한 시스템에 해당하는 도메인 이름이 다르기 때문에 자연스럽게 JSONP 형식이 첫 번째 선택이 됩니다.
그러나 광고와 같은 일부 특수 시스템의 경우 렌더링은 단순한 JSONP 요청이 아니며 JS 로드 및 렌더링 제어 전달과 같은 전체 광고 렌더링 프로세스에 개입할 수도 있습니다.
페이지 구조
위에서는 데이터 소스와 하위 모듈의 구조를 소개했는데, 전체 페이지는 어떻게 구성되나요? 모듈 구성에는 두 가지 유형이 있는데 하나는 시각화입니다. 빌드, 운영 또는 프런트엔드는 개발된 모듈(또는 모듈 라이브러리에서 선택한 모듈)을 컨테이너에 끌어다 놓아 페이지를 구성할 수 있습니다.
물론 위 그림은 모델일 뿐입니다. 시스템 요구 사항 페이지 레이아웃, 다중 터미널 적응, 모듈 임시 숨기기, 위치 조정, 스킨 선택, 모듈 복제 등과 같이 고려해야 할 더 많은 문제가 있습니다.
모듈 ID를 통해 모듈을 소개하고 지연 로드와 같은 태그를 추가하여 렌더링 리듬 및 데이터 입력을 쉽게 제어할 수 있습니다. 소스 코드 구성과 모듈 구성의 차이점은 전자가 모듈의 구조와 모듈의 렌더링 순서를 제어하기가 더 쉽다는 것입니다.
동적 데이터 소스
홈페이지는 수많은 인터페이스와 플랫폼에 직면해 있으며 수십 개의 비즈니스 당사자를 연결합니다. 인터페이스는 백엔드 시스템의 차이로 인해 큰 문제입니다. , 기본적으로 해결책은 없습니다. 데이터 소스의 형식을 통일하십시오. 운영자가 갑자기 사용하기 편하거나 데이터가 더 좋은 시스템으로 변경하려고 하면 프런트엔드와 백엔드가 통신하고 연결되어야 할 것입니다. 여러 번.
플랫폼에는 데이터 소스에 액세스할 수 있는 기능이 있습니다. 즉, 우리가 파는 구덩이를 통해 작업이 데이터를 채울 수 있을 뿐만 아니라 다양한 데이터 소스에서 데이터를 직접 가져올 수도 있습니다. 여기에는 필드 매핑 변환이 필요합니다.
바인딩 후 데이터는 동기식 또는 비동기식으로 출력될 수 있습니다. 이는 플랫폼에서 제공하는 기능입니다. 이 솔루션은 기본적으로 백엔드 시스템/인터페이스 변경 문제를 해결하고 프런트엔드와 백엔드 간의 통신 비용을 절감합니다.
그러나 여기서 주목해야 할 점은 페이지의 인터페이스가 플랫폼을 통해 통합되어 있더라도 이는 페이지에 대한 모든 요청이 먼저 플랫폼을 통해 흐른 다음 다양한 사용자에게 배포된다는 의미이기도 합니다. 플랫폼은 스트레스를 견디는 능력을 매우 요구합니다.
2. PHP에서 Node로의 전환
Taobao 홈페이지의 일일 평균 요청은 10~20개 이상의 서버에서 감당할 수 없습니다. 이를 지원하려면 A 서비스 클러스터가 있어야 합니다. .
각 CDN 노드에는 PHP 렌더링 기능이 있습니다. 페이지가 게시되면 페이지의 모든 모듈과 데이터가 모든 CDN 노드에 동기화됩니다. 꽤 괜찮아 보이지만 일정 기간의 운영 및 유지 관리 후에 많은 보안 및 성능 문제가 서서히 나타났습니다.
성능 문제. 각 PHP 페이지에는 여러 하위 모듈이 포함되어 있으며 하위 모듈은 다른 하위 모듈을 참조할 수도 있습니다. 각 참조는 디스크 IO이며 수천 개가 렌더링 노드에서 실행됩니다. 동시성이 높을 때 효율적입니다.
푸시 메커니즘 문제입니다. 파일 동기화는 다소 역겨운 메커니즘입니다. 우선, 시간에 대한 통제가 없습니다. 파일은 몇 초 또는 1~2분 안에 모든 노드에 동기화될 수 있습니다. 또한 동기화 프로세스가 실패할 수 있으며 상태 테스트 비용도 상당히 높습니다. 높은. 릴리스가 비교적 컴팩트하면 동기화해야 하는 파일이 많아 큐가 쉽게 누적되고 열악한 동기화 환경이 악화될 수 있습니다.
강력한 실시간 요구 사항과 관련된 문제. 파일이 푸시되기 전에 일부 프런트엔드 시스템을 거칠 수도 있습니다. 게시 링크가 길어질수록 온라인 유효 시간이 느려지므로 이러한 지연이 적용되는 데 약 5분이 소요됩니다. -시간적 성능(예: 플래시 세일)은 수요 측면에서 전혀 허용되지 않습니다.
물론 운영 및 유지 관리 비용 증가, 보안 위험 증가, PHP 수석 인재 보유 부족 등 많은 문제가 있습니다. 따라서 PHP 렌더링 컨테이너의 운명은 종료되는 것입니다.
서비스 클러스터는 Cache CDN입니다. 정적 파일 처리 기능만 있고 PHP/노드의 렌더링 기능은 없습니다. 따라서 처리 효율성이 높고 성능이 좋으며 압력 저항이 강합니다. 서비스를 구매하고 캐시 클러스터를 확장하는 데 돈을 쓸 수 있습니다.
사용자가 접속하면 Nginx는 Cache CDN으로 갑니다. 캐시에 적중이 없으면 바로 원본 서버로 반환됩니다. 원본 서버는 모듈 렌더링 기능을 갖춘 노드 서비스입니다.
· 캐시 응답 헤더를 제어하고 최대를 통해 클라이언트와 캐시에서 페이지의 캐시 시간을 제어합니다. age 및 s-maxage. 캐시 시간은 주요 프로모션 기간 동안 더 긴 시간으로 늘리는 등 필요에 따라 언제든지 조정할 수 있습니다.
· 내부 및 외부 네트워크 환경을 제어합니다. 및 AB 테스트 상태
· 통합 탐지, 압축, 필터링 등과 같은 프런트엔드 관련 도구 체인.
여기에 나열되지 않은 많은 장점이 있습니다. 이 모델은 또한 재해 복구 계층을 추가합니다. 원본 서버는 정기적으로 캐시와 동일한 컴퓨터실에 있는 백업 서버에 데이터를 푸시합니다. 원본 서버에 장애가 발생하면 재해 복구가 자동으로 백업 데이터로 전송될 수 있습니다.
모델의 변화는 운영 및 유지 관리에 획기적인 변화를 가져왔을 뿐만 아니라 CDN이 공격을 받을 때의 보안 위험도 줄여주며 동기화에 필요한 다양한 탐지 메커니즘이 필요 없어 수백만 달러를 절약해 줍니다. 연간 비용 위의 장점은 매우 분명합니다.
3. 노드, 다양한 모드
위의 PHP 모듈에서는 HTML과 데이터 부분에 대해서만 이야기했습니다. 주의 깊은 독자라면 CSS와 JS와 같은 정적 리소스가 언급되지 않았지만 페이지는 어떻게 렌더링되나요?
이전 버전의 PHP 페이지에서는 CSS와 JS를 직접 도입했습니다. Taobao는 git 버전 반복 릴리스를 사용하며 이러한 정적 리소스가 배치되어 있습니다. git 저장소에서 직접. 즉,
git 파일을 게시할 때마다 PHP 버전 번호를 수정한 다음 PHP 코드를 게시하세요. 물론 git을 출시할 때 버전 번호를 자동으로 업데이트하는 등 관련 최적화도 이루어졌습니다.
CSS/JS와 모듈의 템플릿을 함께 놓고 CSS/JS와 페이지에 있는 다른 모듈의 정적 리소스는 서로 독립적이기를 바라는 것입니다. 완전히 실행하면 모듈 재사용에 더 도움이 됩니다.
모듈 파기는 템플릿과도 독립적이며 데이터 형식은 JSON 스키마 형식으로 정의됩니다.
모듈은 독립적이고 서로 격리되어 있으므로 어느 정도의 불일치가 있을 수 있지만 모듈 분리의 이점은 이러한 중복보다 훨씬 큽니다. 실제로 우리는 창고를 통해 개별 모듈을 관리합니다. 페이지 렌더링은 비교적 간단합니다. 소스 노드 컨테이너는 모든 index.xtpl을 하나의 page.xtpl로 병합합니다. 페이지 요청을 줄이기 위해 CSS와 js도 하나의 파일로 결합됩니다.
다음 번에 시스템에 들어가면 모듈과 페이지를 업그레이드해야 하는지 묻는 메시지가 표시됩니다.
3. 타오바오 홈페이지 성능 최적화
홈페이지 모듈이 너무 많아서 단숨에 뱉어내면 DOM 개수가 4k를 넘어야 하는데, 결과적으로는 첫 화면 시간이 너무 길다. TMS 개발 사양에 따르면 각 TMS 모듈에는 index.js와 index.css가 포함되어 있으며 마지막으로 js와 css의 두 가지 콤보가 표시됩니다. 홈페이지가 로드되면 모든 index.js가 한꺼번에 실행되지 않습니다. 그렇지 않으면 초기에 페이지 차단이 매우 심각해집니다.
페이지 렌더링 논리
· 모든 TMS 모듈(J_Module 후크 포함)을 탐색합니다.
· 일부 TMS 모듈에는 JS 콘텐츠가 없지만 하나는 인덱스가 로드됩니다. .js, 모듈의 JS 실행을 건너뛰는 데 사용되는 tb-pass 클래스를 모듈에 추가합니다.
· 페이지를 두 부분으로 나누면 첫 번째 화면이 하나이고, 첫 번째가 아닌 화면은 두 번째 블록입니다. 먼저 지연 로딩 모니터링에 첫 번째 화면 모듈을 추가합니다.
· 첫 번째 화면 모듈이 로드된 후 또는 사용자가 페이지 상호 작용(스크롤, 마우스 이동, 등), 지연 로딩 모니터링에 첫 번째 화면이 아닌 모듈을 추가합니다.
· 창에 들어가기 전에 수백 픽셀을 로딩하기 시작하는 일부 특수 모듈을 처리합니다. 스크롤을 모니터링하고 위 로직에 따라 모듈을 렌더링합니다.
p>
· 일부 모듈이 실행되더라도 내부에 이벤트 모니터링이 추가되지 않아 렌더링되지 않을 수 있습니다. 콘텐츠를 렌더링하기 전에 mouseover/onload 이벤트가 트리거될 때까지 기다리는 것과 같은 모듈입니다.
코드 성능 최적화는 최적화되지 않은 거대한 페이지에서 성능 최적화를 수행하려는 경우 코드 재구성에 직면할 수 있습니다. 위 기사에서는 페이지 내부 세부 사항의 최적화에 대해 언급했지만 개발 과정의 표준화 및 표준화는 물론 온라인 액세스 경로의 각 링크 최적화에 대해서는 언급되지 않았습니다.
4. 타오바오 홈페이지의 안정성 보장
트래픽이 많으면 작은 문제도 큰 문제로 확대되므로 개발 과정에서 가끔 발생하는 문제는 해결해야 합니다. 주의. 그러나 지역 관련 문제(예: 상하이의 CDN 노드가 다운됨), 사용자 속성 문제(예: 마지막 닉네임이 문자 s인 사용자 페이지 채광창) 등 많은 산발적인 문제를 우리 테스트 환경에서 찾을 수 없습니다. , 브라우저 플러그인 문제, 사업자 광고 삽입 문제 등
온라인에 접속하기 전에 모든 문제를 고려하기는 어렵지만 반드시 잘 수행해야 할 두 가지가 있습니다. 바로 재해 복구 및 모니터링과 조기 경보입니다.
1. 전체 재해 복구 메커니즘
전체 재해 복구에는 두 가지 수준의 고려 사항이 있습니다.
· 인터페이스 데이터 형식 오류를 포함한 비동기 인터페이스 요청 오류 인터페이스 요청 시간 초과 등
· 동기 렌더링, 원본 페이지 렌더링 오류.
비동기 인터페이스 요청에는 주로 백엔드 시스템이 포함됩니다. 각 시스템에는 서로 다른 안정성과 압력 저항이 있습니다.
각 데이터 요청은 로컬로 캐시되며 각 인터페이스에 대해 하드 바텀이 제공됩니다. 또 다른 옵션은 요청이 한 번 실패하면 "재시도"하는 것입니다.
동기 렌더링의 경우 페이지 템플릿과 동기화 데이터만 필요합니다. 둘 중 하나에 오류가 있으면 원본 사이트에서 오류를 보고하며 원본으로 다시 반환되는 콘텐츠는 다음과 같습니다. 상태 코드가 5xx인 오류 페이지. 이 오류는 반드시 개발자의 문제로 발생하는 것은 아닙니다. 동기화 이상이거나 시스템 링크의 회로 차단 문제일 수 있습니다.
원본 사이트에 이상이 생기면 Nginx는 Cache CDN과 같은 컴퓨터실에 있는 홈페이지 미러로 이동합니다. 이 미러의 내용은 타오바오 홈페이지의 HTML 백업 소스코드입니다.
2. 모니터링 및 조기 경고 메커니즘
모니터링에는 두 가지 수준도 있습니다.
· 모듈 수준 모니터링, 인터페이스 요청 배치, 모듈 채광창 감지 등. ;
· 페이지 모니터링, 페이지에 특수 태그 추가, 정기적으로 모든 CDN 노드로 돌아가 특수 태그가 있는지 확인합니다.
모듈 수준 모니터링에는 모니터링 지점이 많을수록, 세부적일수록 문제를 찾는 효율성이 높아집니다. 예를 들어 약간 복잡한 모듈에서는 그렇습니다. , 묻겠습니다. 이러한 모니터링 지점은 다음과 같습니다.
· 인터페이스 요청 형식 오류, 요청 실패, 요청 시간 초과, 최소 3개의 숨겨진 지점
· 하드커버 데이터 요청 실패 숨겨진 지점;
· 모듈이 5초 이내에 렌더링되지 않았습니다.
· 모듈의 링크가 이미지의 흑백 목록과 일치합니다.
모니터링의 일부는 명확한 오류도 자동으로 처리합니다. 예를 들어 http 이미지가 https 페이지에 나타나는 경우 이러한 문제는 자동으로 즉시 처리됩니다.
3. 온라인에 접속하기 전 자동화된 테스트
이는 Taobao의 전체 엔지니어링 환경인 프런트엔드 자동화 테스트의 일부입니다. 일반적으로 이러한 문제는 온라인에 접속하기 전에 처리됩니다.
· HTML이 사양을 준수하는지 감지
· https 업그레이드 상황 감지
· 감지 링크의 적법성
· 정적 리소스의 적법성 감지
· JavaScript 오류 감지
· 페이지를 방문할 때 팝업 상자가 있는지 감지 로드됨
· 페이지가 콘솔을 호출하는지 감지합니다. *
· 페이지 JS 메모리 기록
물론 다음과 같은 테스트 사례를 직접 추가할 수도 있습니다. 인터페이스 데이터 형식, 모듈 채광창 문제 등을 감지합니다. 자동 감지는 상대적으로 안전한 예정된 회귀를 설정할 수도 있습니다.
5. 타오바오 홈페이지에 대한 민첩한 조치
1. 상태 점검
모든 작은 변화를 추적할 수 있도록 많은 페이지 모듈이 있습니다. 페이지의 한 지점에서 요청 및 렌더링의 모든 측면에 대한 자세한 통계가 작성됩니다.
인터페이스 요청이 실패하거나 인터페이스가 재해 복구 논리를 잃거나 모듈이 5초 이상 렌더링되면 콘솔에 노란색 경고가 표시됩니다. 물론 이때 경고 통계에는 서버에도 전송되었습니다.
2. 인터페이스 허브
인터페이스 허브는 데이터 요청을 관리하는 도구입니다.
페이지의 많은 모듈을 렌더링하려면 두 개 이상의 데이터 소스가 필요합니다. 작업 피드백 페이지 렌더링 데이터가 비정상적인 경우 허브를 통해 직접 데이터를 찾아 버그 위치의 효율성을 높일 수 있습니다. 동시에 Hub는 환경을 전환하고 일일 또는 시험판 환경에서 인터페이스에서 인터페이스로 요청을 전환하는 데에도 사용할 수 있습니다. 디버깅을 위한 강력한 도구입니다.
3. 빠른 채널
페이지 스크립트 실행 전후에 스타일 혼란, 오버플로, 인터페이스 오류 등 긴급 온라인 문제가 발생하면 빠른 작업 채널을 두었습니다. 채광창 등을 유발하는 경우 바로가기 채널을 통해 페이지의 CSS, JS를 직접 수정하면 2분 안에 온라인 상태가 됩니다.
그러나 이런 유형의 채널은 긴급한 문제를 해결하는 데에만 적합합니다. 결국 JS 코드를 마음대로 삽입하는 것은 매우 위험합니다. ;