JD 통합 헤드 및 테일 관리 시스템 탐색 및 실습

시스템 배경

Q: 웹사이트의 카피라이팅을 수정하는 데 얼마나 걸립니까? 작은 개인 웹 사이트의 경우 매우 간단할 것으로 추정되며 몇 분 안에 수정 및 게시할 수 있습니다. 하지만 수백 개의 웹사이트의 카피라이팅을 수정하고 싶다면 어떻게 해야 할까요? 그러면 제품 수요를 높이고, R&D를 위한 개발 일정을 잡고, 회귀 검증을 위한 테스트가 필요할 것으로 추정됩니다. 많은 수의 응용 프로그램이 관련되어 있고 각 응용 프로그램에는 고유한 연구 및 개발 요구 사항이 있기 때문에 카피라이팅 수정 일정을 신속하게 예약하지 못할 수 있습니다. 따라서 매우 간단한 요구 사항처럼 보이지만 관련된 애플리케이션과 부서가 많을 때 제품 관리자에게는 악몽이 됩니다. 특히 Jingdong Mall과 같은 대형 쇼핑 웹사이트의 경우 탐색하는 모든 웹페이지 뒤에는 많은 비즈니스 시스템이 있으며 전담 R&D 팀에서 관리합니다. 통일된 웹 페이지 스타일을 유지하기 위해 각 비즈니스 시스템은 공통 헤더 및 테일이라고 하는 동일한 페이지 헤더 및 테일을 사용하는 경우가 많습니다.

예를 들어 위 사진은 현재 JD.com에서 일관되게 사용하는 페이지의 꼬리 부분인데 꼬리 부분에서 카피라이팅이나 링크를 수정하려면 수백 개의 시스템과 R&D 팀을 푸시하여 수정 일정을 잡고 실행해야 합니다. 이 문제를 해결하기 위해 JD.com의 통합 헤더 및 꼬리 관리 시스템이 탄생했으며 기본적으로 JD.com의 공개 헤더 및 꼬리 콘텐츠의 5분 수정을 실현했습니다.

현재 통합 헤드 투 테일 시스템의 성과는 다음과 같습니다.

전체 시스템 아키텍처 설계

전체 시스템은 주로 두 부분으로 구성됩니다.첫 번째 부분은 주로 Jingdong의 공개 헤더 및 꼬리 파일과 비즈니스 시스템을 관리하고 비즈니스 시스템과 공개 헤더 및 꼬리 파일 간의 관계를 구성하고 공개 헤더를 배포하는 데 사용되는 관리 배경입니다. 비즈니스 시스템용 tail 파일. . 두 번째 부분은 헤더 및 테일 클라이언트로, 비즈니스 시스템이 의존하는 헤더 및 테일 파일을 얻은 다음 페이지를 구문 분석 및 렌더링하고 헤더 및 테일 파일의 최신 버전 콘텐츠를 출력하는 데 주로 사용됩니다. 서로 다른 버전의 언어로 개발된 비즈니스 시스템에 대처하기 위해 헤드 클라이언트와 테일 클라이언트는 다시 Java 클라이언트와 Nginx 클라이언트로 나뉩니다. Java 클라이언트는 주로 Java 언어로 개발된 비즈니스 시스템을 지원하며 정적 HTML을 구문 분석하고 처리할 수 있을 뿐만 아니라 JSP/Velocity/FreeMarker/Thymeleaf와 같은 구문 분석 페이지 템플릿 엔진도 지원합니다. Nginx 클라이언트는 비 Java 언어로 개발된 비즈니스 시스템을 지원하고 페이지 템플릿을 구문 분석하고 비 Java 시스템의 공용 헤더 및 테일을 렌더링하는 기능을 구현합니다.

관리 배경 설계 및 구현

전체 관리 배경은 프런트 엔드와 백 엔드의 분리를 실현하고 백 엔드는 HTTP 인터페이스 제공을 담당하고 프런트 엔드는 페이지 렌더링만 담당합니다. 관리 배경은 모듈로 나뉘며 주로 파일 관리 모듈, 응용 프로그램 관리 모듈 및 개인 센터 모듈을 포함한 세 가지 모듈로 나뉩니다.

파일 관리 모듈

관리 백그라운드에서 공개 head 및 tail HTML 콘텐츠를 생성 및 저장할 수 있는 공개 head 및 tail 파일의 유지 관리 기능을 제공하고 공개 head 및 tail 파일에 대한 버전 제어를 구현합니다.사용자는 헤드를 편집, 게시 및 롤백할 수 있습니다. 관리 배경 등의 꼬리 파일.

애플리케이션 관리 모듈

비즈니스 시스템의 유지 관리 기능을 제공합니다.사용자는 관리 백그라운드에서 새 애플리케이션을 추가하고, 구성 환경을 생성하고, 비즈니스 시스템이 의존하는 공용 헤드-투-테일 구성 관계를 추가하고, 애플리케이션 정보 및 헤드-투-테일 클라이언트를 볼 수 있습니다. 비즈니스 애플리케이션에서 액세스하는 정보를 요청합니다.

개인 센터 모듈

파일 작업 및 응용 프로그램 작업을 포함하여 관리 백그라운드 사용자의 다양한 작업 로그를 기록하는 데 사용되며 작업 로그 쿼리 기능을 제공합니다. 또한 공개 헤더 및 테일 파일의 릴리스 작업에 대한 온라인 승인 처리를 수행합니다.

헤드 및 테일 클라이언트 설계 및 구현

앞에서 소개한 헤드 및 테일 관리 배경은 헤드 및 테일 파일의 생성, 유지 관리 및 버전 제어를 실현했으며, 비즈니스 시스템이 이러한 헤드 및 테일 파일을 참조하는 데 의존하는 방법은 다음 단계에서 직면해야 하는 문제입니다. 우선 우리가 해결해야 할 문제는 헤드앤테일 관리 백그라운드에서 생성된 헤드앤테일 파일을 각 업무 시스템에 어떻게 분배하느냐다. 현재 주로 두 가지 방법, 즉 헤드 앤 테일 시스템의 푸시 방식과 비즈니스 시스템의 풀 방식이 있습니다.

머리와 꼬리 시스템 푸시 방법:

즉, 각 비즈니스 시스템의 각 서버를 서버로 사용하고 헤드 및 테일 시스템을 클라이언트로 사용하는 것을 의미합니다 헤드 및 테일 시스템의 헤드 및 테일 파일이 업데이트되면 능동적으로 각 비즈니스 시스템의 서버 연결에 성공하면 헤드 및 테일 파일의 최신 내용이 비즈니스 시스템으로 전송됩니다. 헤드 및 테일 시스템 클라이언트가 언제든지 각 비즈니스 시스템 서버와 연결을 설정할 수 있도록 비즈니스 시스템은 고정 포트를 모니터링하고 항상 서비스를 제공해야 합니다. 머리와 꼬리 파일. 실제 환경은 JD.com이 많은 비즈니스 시스템을 보유하고 있으며 배포 환경도 다양하고 개발 언어도 다양합니다. 헤드투테일 서버를 개발하려면 먼저 언어간 문제를 해결해야 합니다.JD.com은 현재 개발을 위해 Java, Js, Php, Golang, Lua를 사용합니다.헤드를 제공하고 유지해야 합니다. -to-tail 서버 버전은 5개 언어로 제공됩니다. 또한 비즈니스 시스템에서 모니터링하는 포트 수가 많기 때문에 헤드 및 테일 서버가 시작할 때 포트 점유 위험에 직면하게 되며, 이로 인해 헤드 및 테일 서버가 정상적으로 시작되지 않아 헤드 및 테일 서버가 정상적으로 시작되지 않습니다. 테일 파일은 업데이트할 수 없습니다. 그러나 이 방법도 장점이 있는데, 헤더 파일을 업데이트해야 하는 경우에만 연결을 설정하여 푸시합니다.헤더 및 테일 파일은 실시간으로 업데이트 및 적용할 수 있을 뿐만 아니라 서버를 저장합니다. 자원.

비즈니스 시스템 끌어오기 방법:

이 방식은 Head-to-tail 방식의 Push 방식과 정반대의 방식으로, Head-to-tail 방식을 서버로 사용하면 포트 점유로 인한 시작 실패 문제를 해결할 수 있지만 여전히 Cross-to-Tail 방식의 문제에 직면해 있습니다. 언어 클라이언트 버전. 그러나 비즈니스 시스템에 대한 우리의 연구 및 분석을 통해 기본적으로 모든 비즈니스 시스템은 Nginx를 리버스 프록시로 사용하며 이 Nginx는 우리에게 교차 언어 비즈니스 시스템을 지원할 수 있는 가능성을 제공합니다. 그런 다음 헤드 및 테일 클라이언트의 Java 버전을 개발하여 헤드 및 테일 파일을 Java 비즈니스 시스템에 도입하고 가져오기만 하면 됩니다. 그러나이 방법에는 단점도 있습니다. 즉, 헤드 및 테일 클라이언트는 헤드 및 테일 파일이 언제 업데이트 될지 모르고 헤드 및 테일 클라이언트는 정기적으로 헤드 및 테일 시스템을 폴링하여 헤드 및 테일 파일이 있는지 여부를 확인할 수 있습니다. tail 파일이 업데이트되고 파일이 업데이트되면 새 헤더 및 tail 파일 내용을 가져옵니다. 이로 인해 헤드 및 테일 파일이 실시간으로 업데이트되지 않고 일반 폴링도 특정 서버 및 네트워크 리소스를 소비합니다.

마지막으로 종합적인 고려 끝에 헤드 및 테일 파일을 배포하기 위해 비즈니스 시스템의 풀 방식을 선택했습니다. 비즈니스 시스템의 교차 언어 문제를 해결하기 위해 헤드 및 테일 클라이언트의 두 가지 버전, 즉 Nginx 헤드 및 테일 클라이언트와 Java 헤드 및 테일 클라이언트를 제공합니다. 모든 비즈니스 시스템의 꼬리 파일. 그러나 비즈니스 시스템이 이러한 헤더 및 테일 파일을 참조하는 방법에는 SSI(server-side web page inclusion) 기술이 포함됩니다. 다음은 두 가지 방법의 헤드 및 테일 클라이언트가 헤드 및 테일 파일과 SSI를 끌어오는 문제를 어떻게 해결할 수 있는지 소개합니다.

Nginx 헤드 및 테일 클라이언트

이 방법은 주로 Nginx의 SSI 모듈을 사용하여 head, tail 파일과 SSI 문제를 pull하는데 ngx_http_ssi_module 모듈은 Nginx에 있는 필터로 이를 통과하는 응답에서 SSI(server-side inclusion) 명령을 처리합니다. 포함된 명령어를 현재 사용하고 있으며 구성 예는 다음과 같습니다.

  <!--# include file="/fragment/footer.html" -->

비즈니스 시스템의 페이지는 이 구성 지침을 통해 헤드 및 테일 시스템에서 유지 관리되는 헤드 및 테일 파일을 참조하지만 이 구성 지침에서는 이러한 파일을 로드하고 Nginx로 교체하기 전에 서버에 실제로 존재해야 합니다. 따라서 이 설정만으로는 헤더와 테일 시스템에 구성된 헤더와 테일 파일을 가져올 수 없으며, include 명령으로 도입된 파일명을 URL로 변환한 후 헤더와 테일 시스템 서버로 가서 요청을 해야 한다. 해당 버전의 헤더 및 테일 파일. 그래서 여기서 Nginx의 URL 재작성 및 리버스 프록시 구성을 사용하여 헤드 및 테일 파일을 끌어오는 문제를 해결합니다. 이 시점에서 실제로 완전한 헤더 및 테일 파일 SSI 기능이 구현되었으며 헤더 및 테일 파일을 포함하는 페이지도 비즈니스 시스템에 완전히 표시될 수 있습니다.

그러나 여전히 몇 가지 문제가 있습니다.여기에서 헤더 및 테일 파일 요청은 사용자가 페이지를 열람할 때 수동적으로 트리거되며, 헤더 및 테일 파일도 리버스 프록시 동기화를 통해 Nginx에서 요청하므로 헤더 및 테일의 응답 시간이 꼬리 시스템은 비즈니스 시스템의 페이지에 직접적인 영향을 미칩니다.로드 시간, 헤드 및 꼬리 시스템이 시간 초과되면 비즈니스 시스템 페이지도 시간 초과되며 비즈니스 시스템의 페이지 트래픽(JD 홈페이지, 비즈니스 세부 정보 페이지 포함)은 모두 머리와 꼬리 시스템에 부딪히는데, 이는 머리와 꼬리 시스템이 감당할 수 없는 트래픽입니다. 따라서 비즈니스 시스템의 요청량을 줄여야 하며 이러한 헤더 및 테일 파일의 내용이 너무 자주 변경되지 않으므로 Nginx를 사용하여 로컬 캐시 proxy_cache를 추가할 수 있습니다. 사용자가 비즈니스 시스템의 페이지를 열람할 때 로컬 캐시에 있는 헤드 및 테일 파일을 먼저 요청하고 캐시 시간이 만료된 후 헤드 및 테일 시스템에 요청하여 최신 헤드 및 테일 파일을 얻습니다. Nginx 프록시 캐시 구성을 통해 수천 건의 사용자 요청이 각 비즈니스 시스템의 서버 캐시 시간 내에 단 하나의 요청에 최적화되어 헤드 및 테일 시스템의 요청 압력을 크게 줄입니다. 동시에 proxy_cache_use_stale 구성은 비즈니스 시스템이 헤드 및 테일 시스템에 의존하는 위험을 줄이기 위해 사용되며 헤드 및 테일 시스템이 다운되더라도 헤드 및 테일 파일의 로드 및 표시에 영향을 미치지 않습니다. 비즈니스 시스템의. 다음은 Nginx 클라이언트의 부분 구성 예입니다.

location ~ ^/fragment/ {
    proxy_cache header_cache;
    proxy_cache_key $uri;
    proxy_cache_valid 200 1m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_lock on;
    proxy_cache_lock_timeout 1s;
    proxy_connect_timeout 1s;
    proxy_ignore_headers Set-Cookie Cache-Control;
    proxy_hide_header Cache-Control;
    proxy_hide_header Set-Cookie;
    # 参考头尾系统中配置，请注意区分测试环境和生产环境，返回的文件内容默认都是UTF-8编码内容，如果需要GBK编码内容需要在env后面拼接参数?charset=GBK
    # 只需要替换{appId} {token} 和 {env}
    rewrite ^/fragment/(.*) /open/fragment/$1/Nginx/$nginx_version/$server_addr/{appId}/{token}/{env} break;
    proxy_set_header Accept-Encoding "";
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass   http://xxx.jd.local;
}

Java 헤드 및 테일 클라이언트

앞에서 소개한 Nginx 메소드 클라이언트는 헤더와 테일 파일의 SSI 문제를 해결했지만 사용자가 페이지를 방문할 때 Nginx의 SSI 프로세스가 트리거되기 때문에 사용자 요청 프로세스 중에 동기식 호출이 발생하더라도 로컬 캐시가 이 추가되면 여전히 페이지의 응답 시간에 영향을 미칩니다. 그래서 이러한 성능 손실 문제를 해결하기 위해 헤드 및 테일 클라이언트의 Java 버전을 특별히 개발하여 헤드 및 테일 파일의 SSI 기능을 구현했습니다. 헤드 및 테일 클라이언트의 시작 프로세스는 다음과 같습니다.

먼저 비즈니스 시스템은 jar 패키지에 의존하기 위해 Java 헤드 및 테일 클라이언트를 도입한 다음 헤드 및 테일 시스템에서 애플리케이션 ID, 액세스 토큰, 환경 식별자, 페이지 템플릿 경로 및 템플릿 파일 접미사 이름을 구성해야 합니다. 구성이 완료되면 헤드 및 테일 클라이언트가 비즈니스 시스템과 함께 시작됩니다. 시작 프로세스 중에 헤드 및 테일 클라이언트는 먼저 헤드 및 테일 시스템에 구성된 헤드 및 테일 파일을 비즈니스 시스템 서버의 로컬 디렉토리로 다운로드한 다음 비동기 스레드를 시작하여 요청 헤드 및 테일 시스템을 폴링하고 헤드 및 테일 파일의 업데이트를 감지합니다. 헤드 및 테일 파일에 변경 사항이 있는 경우 최신 헤드 및 테일 파일을 로컬 디렉토리에 직접 다운로드합니다.

헤드 및 테일 파일이 로컬로 다운로드된 후 헤드 및 테일 클라이언트는 구성의 페이지 템플릿 경로 및 접미사 이름에 따라 SSI 명령이 포함된 모든 템플릿 파일을 스캔하고 메모리에 로드하고 이러한 템플릿 파일의 백업 파일을 생성합니다. 그런 다음 메모리에 로드된 템플릿 파일에 따라 템플릿 파일의 include 명령을 파싱하고 최종적으로 포함된 명령으로 구성된 파일 이름을 통해 헤드 및 테일 파일의 내용을 교체하여 로드하여 새로운 템플릿 파일을 생성합니다. 템플릿 파싱이 완료되면 헤더 및 테일 파일의 업데이트 여부를 모니터링하는 데 특별히 사용되는 헤더 및 테일 파일 옵저버를 등록하고 시작합니다. 업데이트가 있으면 메모리의 템플릿 내용을 다시 구문 분석하여 새 템플릿 파일. 이 프로세스는 기본적으로 비즈니스 시스템이 시작될 때 수행되므로 사용자가 비즈니스 시스템 페이지를 요청하면 비즈니스 시스템은 템플릿 파일을 직접 반환하여 사용자 요청 프로세스 중에 SSI 처리를 피하고 기본적으로 비즈니스 제로 손실을 실현합니다. 시스템 성능.

저자: Jingdong Retail Cao Zhifei

출처: JD 클라우드 개발자 커뮤니티