Baidu 검색 디스플레이 서비스 재구성: 진행 및 최적화

저자 | 르둥

소개 

본 글에서는 검색 및 디스플레이 서비스의 개발 과정과 현재 직면한 세 가지 주요 과제인 높은 연구 개발 난이도, 아키텍처 역량 부족, 재사용성 부족에 대해 간략하게 소개하고, 마지막으로 핵심 솔루션 아이디어와 구체적인 방안을 제시하겠습니다. 시행계획을 숙지하시고 많은 분들이 참고하시길 바라겠습니다.

전체 텍스트는 4736 단어이며 예상 읽기 시간은 12분입니다.

01 배경

Baidu 검색 표시 서비스의 주요 책임은 검색 시스템에 결과를 요청하고 템플릿 선택, 실시간 요약 보완, 데이터 적응 및 결과 렌더링을 순차적으로 수행하여 검색 결과가 사용자에게 풍부하고 정확하게 표시될 수 있도록 하는 것입니다. 다양한 형태. 초기에는 C 언어를 기반으로 개발된 서비스여서 반복 효율성이 만족스럽지 못했습니다. 제품의 빠른 반복화와 지속적인 비즈니스 확장으로 인해 R&D 효율성의 문제가 점차 부각되고 있으며, 이러한 병목 현상을 해결하기 위해 검색 및 디스플레이 서비스는 PHP에서 개발하고 HHVM에서 운영하는 서비스로 진화했습니다. 현재 검색 디스플레이 서비스는 수십 개의 제품 라인과 수백 개의 R&D RD가 공동으로 개발하여 수백 가지의 세련된 비즈니스 디스플레이 전략을 담고 있습니다. 그러나 검색 비즈니스의 복잡성이 증가하고 대규모 생성 모델이 증가함에 따라 검색 디스플레이 서비스도 연구 개발의 어려움 증가, 아키텍처 기능 부족, 재사용성 저하 등 여러 가지 문제에 직면하기 시작했습니다. 구체적인 성능은 다음과 같습니다.

[연구 개발 난이도 높음]: 검색 표시 서비스는 프로세스 관리를 기반으로 하며 복잡한 논리를 가지고 있습니다. 여러 정책 프레임워크가 코드의 다양한 단계에 배포되어 있습니다. 단순화된 관리 및 사용 편의성에 대한 여러 기업의 요구를 충족할 수 없습니다. 확장된 효율성 요구 사항

[아키텍처 기능 부족]: hhvm 인프라 유지 관리가 중단되었으며 비동기/멀티 스레딩 및 기타 기능에 대한 지원이 상대적으로 제한됩니다. 스트리밍 부족 기능이 부족하여 생성적 요구 사항을 충족할 수 없으며 검색 및 기타 요구 사항으로 인해 서비스 안정성 및 신제품 수요 반복 요구 사항을 충족할 수 없습니다.

[낮은 재사용성]: 검색 표현 계층의 주요 서비스는 일반 검색, 수직 검색 등입니다. 현재 일반 검색과 수직 검색 사이에는 합리적인 아키텍처 설계가 부족하여 일반 검색과 수직 검색 모두에서 반복적인 개발이 필요한 동일한 요구 사항이 발생합니다.

02 솔루션

2.1 전체 디자인

2.1.1 핵심 아이디어

R&D 난이도 감소: 프리젠테이션 계층의 특성에 따라 그래프 관리 엔진을 설계 및 구현하고 프리젠테이션 기능을 연산자 세분성으로 분할합니다. 단일 연산자는 간단하고 명확하며, 비즈니스 측은 전체 애플리케이션이 아닌 기능(연산자) 및 요구 사항에 집중하는 동시에 검색 및 표시 서비스 프로세스를 DAG 그래프 처리로 업그레이드하여 프로세스 관리의 복잡성을 줄입니다. . 운영자->그래프->요구사항의 계층적 관리를 실현함으로써 검색 및 디스플레이 서비스의 프로세스 연구 및 개발 모델을 프로세스 중심에서 기능 중심, 비즈니스 중심으로 추진합니다.

아키텍처 기능 개선: PHP+HHVM에서 GO로 전환하고, Baidu의 내부 GO 개발 프레임워크를 기반으로 검색 및 표시 서비스를 구축하고, 더 나은 성능과 더 높은 동시 처리 기능을 확보하세요. 동시에 비동기/코루틴/스트리밍 상호 작용 기능을 지원하는 비용은 더 낮습니다.

재사용성 향상: 추상 공용 연산자와 구현 기반 Lib의 공동 구성을 통해 코드의 재사용성과 유지 관리성을 향상시킵니다. 공공 사업자는 반복적인 개발 및 유지 관리 비용을 피하면서 여러 검색 및 표시 서비스에 재사용할 수 있습니다. Basic Lib은 개발자가 코드를 신속하게 개발하고 유지 관리할 수 있도록 공통 기능과 도구 클래스를 제공하여 반복적인 개발 및 오류 가능성을 줄입니다.

그림

△검색 프리젠테이션 레이어 아키텍처 다이어그램

2.1.2 인프라

GDP(Go 개발 플랫폼): Go를 기반으로 하는 Baidu의 내부 비즈니스 개발 플랫폼으로, 완전한 RPC 서버 및 RPC 클라이언트 기능을 갖추고 있으며 주로 API, 웹 및 백엔드 서비스 개발에 사용됩니다.

ExGraph: Baidu 검색 디스플레이 팀이 자체 개발한 그래프 실행 엔진입니다.

그래픽: 간단한 그래프 설명 언어를 설계했습니다. 도구를 사용하지 않고도 rd는 모듈 실행 로직의 전체 그림을 쉽게 학습하고 이해할 수 있어 인수의 어려움을 줄일 수 있습니다.< /a i=0> 아>

연산자: 간단한 인터페이스를 설계하고 구현 세부정보를 보호합니다. rd는 연산자 인터페이스 구현 후 실행될 수 있습니다.

실행: 복잡한 비즈니스 프로세스에 적응하기 위한 직렬 그룹, 병렬 그룹, 하위 그래프, 조건 연산자, 스위치 연산자, 중단, 대기 및 기타 메커니즘의 유연한 설계

효율성 도구: 코드 생성기 및 스캐폴딩과 같은 효율성 도구를 구현하여 애플리케이션을 빠르게 생성합니다.

Datahold: Baidu 검색 표시 팀이 자체 개발한 데이터 관리자는 주로 모듈 데이터(예: 구성, 사전) 종속성 및 로딩 문제를 해결합니다. 다음과 같은 능력을 가지고 있습니다:

  • 핫 로딩 지원, 변경된 파일을 백그라운드에서 모니터링 및 구문 분석한 후 사용을 위해 포그라운드로 전환, 범용 사전, 구성 파서 제공, 사용자 정의 파일 파서 지원

  • 구성을 통해 데이터 객체의 자동 등록, 로딩, 파싱을 지원하고, 대규모 서비스에서 구성/사전을 효과적으로 관리하며, 파싱 오류 등에 대한 적시 알람을 보장합니다.

  • R&D 단계에서 환경 배포의 효율성을 향상시키기 위해 원격 데이터에 의존하는 첫 번째 오프라인 환경 모듈의 원클릭 배포를 지원합니다.

공개 라이브러리: 또한 인프라 계층은 팀의 공개 라이브러리를 표시하기 위해 udai(통합 원격 데이터 액세스 cgo 확장), Baidu 자체 서명 등도 제공합니다. 공공 도서관 건설에는 통일된 액세스 표준이 있어 바퀴를 재발명하는 것을 방지하고 R&D 효율성을 향상시킵니다.

2.1.3 공공 사업자

검색 표시 일반 로직을 인터페이스로 추상화하고, 그래프 엔진 기반의 공용 연산자를 제공하며, 개발을 한 곳에서 구현하고, 일반 검색, 수직 검색 등 여러 애플리케이션을 함께 사용할 수 있습니다. 현재 샘플링, 적응, 다운그레이드, 전류 제한, 검색 요청, 랜딩 페이지 클릭, 렌더링 등 수십 가지 공공 연산자가 구현되어 있으며 즉시 사용할 수 있으며 새로운 검색 및 디스플레이 애플리케이션 구축을 신속하게 지원할 수 있습니다. .

2.1.4 애플리케이션 계층

공용 연산자와 각 서비스 자체의 표시 연산자를 통해 실행 그래프를 구축하여 애플리케이션 비즈니스 로직을 구현합니다. 현재 검색 표시 서비스에는 일반 검색 표시 서비스, 수직 검색 표시 서비스, 생성 검색 표시 서비스 등이 포함됩니다.

2.2 상세설계

범용 검색은 수직 검색과 같은 서비스보다 복잡하므로 이번 장에서는 범용 검색 디스플레이 서비스를 예로 들어 Go 재구성 및 마이그레이션 구현 계획을 자세히 소개합니다.

그림

_Δ범용검색 디스플레이 서비스 개편 전후 비교표

우리는 재건과 이주 과정에서 주로 두 가지 어려움에 직면합니다.

난이도 1: 앞서 언급했듯이 범용 검색 디스플레이 서비스는 수십 가지 제품군의 100개 이상의 RD가 공동으로 개발한 모듈입니다. 디스플레이 전략 그룹 1&2&3은 매일 평균 4개 이상의 전략 반복이 시작되는 총 600개 이상의 비즈니스 프레젠테이션 전략 리팩토링 및 마이그레이션 과정에서 해결해야 할 첫 번째 문제는 마이그레이션을 기존 비즈니스 반복 효율성과 호환되게 만드는 방법은 무엇입니까? 많은 비즈니스 라인의 마이그레이션을 조정하는 방법은 무엇입니까?

난이도 2: 검색 및 디스플레이 서비스 비즈니스 로직은 매우 복잡합니다. 재건축 프로젝트가 사용자 효과, 비즈니스 수익 및 서비스 안정성을 어떻게 보장합니까?

난이도 1은 주로 아키텍처 비즈니스 분리 및 원활한 마이그레이션 메커니즘의 두 가지 방법을 통해 해결되며, 난이도 2는 R&D, 테스트 및 출시의 전체 프로세스의 안정성을 보장합니다. 이 두 부분은 다음에 자세히 소개하겠습니다.

2.2.1 비즈니스 분리 및 원활한 마이그레이션

마이그레이션 및 기존 비즈니스 반복의 효율성을 보장하고 여러 제품 라인과 협력하여 비즈니스 프레젠테이션 전략 마이그레이션을 수행합니다. 핵심 의미: 아키텍처와 비즈니스 프레젠테이션 로직을 분리합니다. 아키텍처 마이그레이션 부분은 먼저 Go로 마이그레이션됩니다. 비즈니스 프레젠테이션 전략은 여전히 ​​​​있습니다. PHP 기반 실행 아키텍처 로직 마이그레이션 중에 비즈니스 반복을 차단하지 말고 PHP 버전과 Go 버전에서 동시에 동일한 비즈니스 로직을 개발하지 않도록 하세요. 비즈니스 디스플레이 전략을 비즈니스 라인별로 Go 기반 검색 디스플레이 서비스로 독립적으로 마이그레이션할 수 있도록 지원하는 메커니즘을 설계하고, 복잡한 전체 마이그레이션 프로세스를 4단계로 나누어 순차적으로 진행하여 궁극적으로 전체 프로젝트 목표를 달성합니다.

그림

첫 번째 단계: 아키텍처 부분의 그래픽 마이그레이션 + 서비스로서의 프레젠테이션 전략

전류 제한, 매개변수 처리, 검색 요청, 광고 검색 요청, http-header 렌더링 등의 아키텍처 로직 코드를 GDP+Exgraph 기반으로 마이그레이션하고, go 기반 일반 검색 표시 서비스는 검색 데이터의 통합 처리를 완료한 후 그런 다음 PHP 기반 프레젠테이션 전략 서비스를 요청하여 비즈니스 프레젠테이션 로직을 수행합니다. 이를 통해 상대적으로 자주 반복되지 않는 아키텍처 로직을 먼저 Go로 마이그레이션하여 프레젠테이션 전략의 후속 마이그레이션을 위한 기반을 마련할 수 있으며, 반복이 빈번한 프레젠테이션 전략이 원래 R&D 모델에 따라 계속 반복될 수 있도록 보장합니다.

2단계: 비동기 다이제스트 요청의 전체 마이그레이션

먼저 비동기 요약이 무엇인지 대답해 보세요.

컴퓨팅 리소스와 응답 속도를 고려하기 위해 검색 시스템은 종종 각 하위 시스템 내에 캐시를 설정합니다. 캐시 실패 시간은 최소 몇 분이며 일부 시나리오에서는 며칠에 이릅니다. 동영상 조회수, 기사 좋아요 수, 검색 결과에서 사용자가 좋아하는지 여부 등 몇 초 안에 업데이트해야 하는 일부 표시 요소의 경우 캐시가 그다지 친숙하지 않습니다. 그래서 비동기식 요약이 탄생하게 되었고, 검색 요청이 반환된 후 검색 결과를 바탕으로 고효율 요약 서비스를 요청하게 되는데, 요약 요청은 일반 디스플레이 전략과 비동기적으로 동시에 완료되므로 실시간 요약을 구현할 뿐만 아니라 보완할 뿐만 아니라 사용자 응답 속도 저하도 방지합니다.

프리젠테이션 전략에 따라 Go가 점진적으로 마이그레이션되는 것을 피하기 위해 비동기식 요약 요청 시간을 병렬 시간으로 단축하고 우회 시스템을 도입합니다. 수십개의 비동기 요약 전략이 있으며 일반 표시 전략보다 반복 횟수가 적습니다. 요청은 전체를 함께 마이그레이션하는 것입니다. 비동기 요약 요청이 우회 시스템에 성공적으로 기록되고 모든 일반 표시 전략이 실행됩니다( 실행을 위해 마이그레이션되거나 PHP에 유지됨) PHP 기반 정책 서비스는 우회 시스템을 통해 모든 비동기 요약을 획득하고 실시간 요약 보완을 수행합니다. 우회 시스템 도입 자체에도 통신 오버헤드가 필요하며 이는 다음 방법으로 줄일 수 있습니다.

  • 사이드카 기반 우회 서비스를 통해 원격 통신 오버헤드 감소

  • Go 디스플레이 서비스는 비동기 요약을 구문 분석하지 않지만 원본 직렬화 결과를 우회 시스템에 쓰고 구문 분석을 위해 PHP 서비스를 기반으로 데이터를 얻습니다. go/php에서 데이터의 반복적인 역직렬화로 인해 발생하는 오버헤드를 효과적으로 방지할 수 있습니다.

3단계: 전략 마이그레이션 시연

각 생산라인과 협업하여 디스플레이 전략그룹 1, 디스플레이 전략그룹 2, 디스플레이 전략그룹 3을 go 기반 검색 및 디스플레이 서비스로 전환 완료합니다. 이 단계에서는 정책 세분화 및 소규모 비즈니스 트래픽에 따른 제품군 마이그레이션을 지원하는 동시에 Go의 검색 디스플레이 서비스를 기반으로 새로운 디스플레이 전략(비동기 요약 전략 제외)을 직접 개발할 수 있습니다.

마이그레이션 기준: 표시 전략에 종속성이 있는지 여부에 따라 마이그레이션합니다. 일반 시나리오에 대한 의존성: 정책 실행은 먼저 실행될 다른 비업무 표시 전략에 의존합니다. 이 시나리오는 먼저 종속 전략에 의해 마이그레이션되어야 합니다. 전략은 내부적으로 아키텍처 기능에 의존하지만 기능의 이 부분은 Go로 마이그레이션되지 않습니다. , 등.

마이그레이션 우선순위:

(1) 종속성 없는 디스플레이 전략의 마이그레이션을 우선시하고 개발, 실험, 프로모션을 독립적으로 마이그레이션할 수 있습니다.

(2) 종속성이 있는 표시 전략의 경우 종속 당사자와 협력하여 마이그레이션을 완료합니다.

네 번째 단계: 전체 마이그레이션

비동기 요약 전략 마이그레이션, 렌더링 및 작업 후 마이그레이션을 전체적으로 완료합니다.

이 로직 부분은 상대적으로 자주 반복되지 않습니다. 미리 마이그레이션하는 것이 어떨까요?

주요 제한 요소는 응답 속도입니다. PHP 기반 프리젠테이션 전략 서비스가 렌더링 및 후처리 작업을 위해 go 기반 프리젠테이션 서비스로 다시 전송되면 php->go는 또 다른 직렬화, 역직렬화 및 통신 시간을 추가하게 되어 속도 저하가 발생하게 됩니다. 마이그레이션 후 속도 최적화로 성능 저하를 상쇄할 수 없습니다.

2.2.2 전체 프로세스 안정성 보장

보편적 검색 디스플레이 서비스 재구성 프로젝트의 사용자 효과, 사업 수익 및 서비스 안정성은 주로 전체 프로세스의 안정성에 의해 보장됩니다. 전체 프로세스의 안정성에는 주로 연구 개발, 테스트 및 온라인 안정성 보장이 포함됩니다.

연구개발 보증

마이그레이션 프로세스는 단순한 기능 마이그레이션이 아닙니다. 범용 검색 및 표시 서비스는 수십 년 동안 반복되어 왔으며 데이터 중복, 너무 많은 과거 비행 로직, 낮은 코드 재사용 등 불합리한 설계가 많습니다. 위의 문제를 기반으로 , 데이터 관리, 비행 노선 부담 정리, 공공 사업자 재추상 및 설계 등을 수행합니다. 이는 R&D 품질에 대한 더 높은 요구 사항을 제시했는데, 한편으로는 단위 테스트 및 자동화된 파이프라인 테스트(데이터 차이 및 UI-DIFF, 테스트 보증 도입)를 통해 코드 품질이 보장되지만, 다른 한편으로는 역사적 부담이 있습니다. 로그 관리 분석을 통해 사전에 오프라인화하여 불합리하고 불필요한 마이그레이션을 방지합니다.

테스트 보증

기능 검사:

데이터 비교: qa와 협력하여 자동화된 데이터 비교 기능을 구축하고, 온라인 재생 요청을 기록하고, 검색 요청, 광고 요청, 데이터 출력과 같은 주요 데이터를 렌더링으로 전송합니다. 서비스 등. 완전히 자동화된 일상적인 데이터 차이를 수행하고, 데이터 차이를 통해 잠재적인 문제를 발견하며, 총 수만 개의 데이터 차이를 발견하고 제거합니다.

UI-차이: 검색 결과 페이지에는 날씨 알라딘, 주식 알라딘 등 다양한 유형의 결과가 있습니다. 수천 개의 리소스 유형이 있으며 각 리소스 유형에는 자체 표시 템플릿이 있습니다. 효과 회귀 비용은 높고 어렵습니다. 리소스 표시 양의 우선 순위를 지정하고 ui-diff 플랫폼(HTML 페이지의 픽셀 수준 diff)을 사용하여 diff에 초점을 맞춘 기준선 및 전략 라인 자동화 ui-diff에 대한 온라인 쿼리를 자동으로 마이닝합니다. 임계값을 초과하는 차이 효과 문제, 총 40개 이상의 효과 문제가 이러한 방식으로 발견되고 수정되었습니다.

엔드 투 엔드 테스트: 데이터 차이와 UI 차이의 두 가지 자동 테스트 방법은 이미 대부분의 효과 시나리오를 다룰 수 있습니다. 또한 QA는 주요 시나리오를 검색합니다. 예를 들어 랜딩 페이지 점프, 페이지 넘김, 광고 효과와 같은 수동 효과 테스트가 다시 시작되었습니다. 자동 테스트 + 수동 효과 테스트를 통해 재구성 및 변환 후 디스플레이 효과를 보장합니다.

안정성 테스트: 온라인 운영 환경을 시뮬레이션하고 서비스의 온라인 안정성을 보장하기 위해 온라인 트래픽을 전환하여 장기적인 스트레스 테스트를 수행합니다.

성능 테스트: 성능 플레임 그래프를 사용하여 시스템 성능 핫스팟 발견 및 최적화 지점, 일반 온라인 인스턴스 피크 qps에 대한 성능 테스트 및 극한 압력 테스트를 수행하여 서비스 제한 qps를 얻고 온라인 리소스 용량이 충분한지 여부를 사전에 예측합니다. 응답 데이터의 저하입니다.

온라인 보증

출시 단계에서 안정성을 보장하는 주요 수단에는 출시 전 리소스/응답 시간 추정, 안정성 검토, 모니터링 및 경보, 다운그레이드, 내부 테스트, 네트워크 전체의 소규모 트래픽 등이 포함됩니다.

03 요약

본 논문에서는 검색 디스플레이 서비스의 개발 과정과 현재 직면하고 있는 주요 과제인 높은 연구개발 난이도, 부족한 아키텍처 역량, 낮은 재사용성을 소개하고, 그래프 실행 엔진 + 공공 운영자 + 재구성 및 마이그레이션 기반의 방법을 제안한다. 위의 문제를 해결하고 마지막으로 만능 검색 디스플레이 서비스를 기반으로 계획의 구현을 자세히 설명합니다. 이번 글은 검색 표시 서비스 개편에 대한 여러분의 생각을 공유하는 것을 목적으로 하며, 이를 통해 배우고 얻는 것이 있기를 바랍니다. 물론 부족한 부분도 있을 수 있으니 함께 논의할 수 있는 메시지를 남겨주시길 바랍니다.

검색 기술 플랫폼 R&D 부서에서는 AI R&D 엔지니어를 모집하고 있습니다. 관심 있는 학생들은 [email protected]으로 이력서를 제출하시기 바랍니다.

--끝--

추천도서

Baidu APP iOS 패키지 크기 50M 최적화 실습 (7) 컴파일러 최적화

Baidu 검색 콘텐츠 HTAP 테이블 저장 시스템

빅모델 시대, “누구나 AI를 할 수 있다”는 바이두 개발자 플랫폼은 어떤 모습일까?

수십만 개의 QPS, 바이두의 핫 이벤트 검색 안정성 보장 실무

바이두 검색 1조 규모의 특징 계산 시스템 실습

SenseTime 창립자 Tang Xiaoou, 55세의 나이로 사망 2023년에는 PHP 정체 Wi-Fi 7이 완전히 출시됩니다 2024년 초 데뷔, Wi-Fi 6보다 5배 빠름 홍멍 시스템은 곧 독립을 앞두고 있으며 많은 대학에서 '홍멍 수업'을 설치했습니다 Zhihui Jun의 스타트업 회사 재융자, 금액 6억 위안 초과, 사전 평가액 35억 위안 Quark Browser PC 버전 내부 테스트 시작 AI 코드 도우미 인기 많고 프로그래밍 언어 순위는 다 별거 없어요 Mate 60 Pro의 5G 모뎀과 무선 주파수 기술이 훨씬 앞서 있습니다 MariaDB가 SkySQL을 분할하여 설립되었습니다 독립 회사로서 Xiaomi는 Yu Chengdong의 화웨이의 "용골 피벗" 표절 발언에 대응
{{o.이름}}
{{이름}}

추천

출처my.oschina.net/u/4939618/blog/10321458