10분만에 해결되는 대규모 분산형 전자상거래 시스템 아키텍처 |

이 글은 대규모 분산 웹사이트 아키텍처 학습에 대한 기술적 요약입니다. 고성능, 고가용성, 확장 가능한 분산 웹사이트의 아키텍처에 대한 간략한 설명과 아키텍처 참조가 제공됩니다. 글의 일부는 독서 노트이고, 일부는 개인적인 경험을 요약한 것으로 대규모 분산 웹사이트 아키텍처에 좋은 참고 가치가 있습니다.

대규모 분산 웹사이트 아키텍처 기술

1. 대규모 웹사이트의 특징

• 다수 사용자, 폭넓은 배포
• 대규모 트래픽, 높은 동시성
• 대용량 데이터, 서비스 고가용성
• 보안 환경이 열악하고 네트워크 공격에 취약
• 다양한 기능, 빠른 개발, 잦은 출시
• 소규모에서 대규모로 점진적으로 발전
• 사용자- 중심
• 무료 서비스, 유료 경험

2. 대규모 웹사이트 아키텍처 목표

• 고성능: 빠른 액세스 경험을 제공합니다.
• 고가용성: 웹사이트 서비스는 항상 정상적으로 접속 가능합니다.
• 확장 가능: 하드웨어를 통해 처리 능력을 증가/감소, 증가/감소시킵니다.
• 보안: 웹사이트 보안 액세스 및 데이터 암호화, 보안 저장 및 기타 전략을 제공합니다.
• 확장성: 새로운 기능/모듈을 편리하게 추가/제거할 수 있습니다.
• 민첩성: 주문형, 빠른 응답

3. 대규모 웹사이트 아키텍처 모델

• 레이어링: 일반적으로 애플리케이션 계층과 서비스 계층으로 나눌 수 있습니다. , 데이터 계층, 관리 계층 및 분석 계층
• 세분화: 일반적으로 비즈니스/모듈/기능 특성에 따라 구분됩니다. 예를 들어 애플리케이션 계층은 홈페이지와 사용자 센터로 구분됩니다.
• 분산: 애플리케이션을 별도로 배포하고(예: 여러 물리적 시스템) 원격 호출을 통해 함께 작업합니다.
• 클러스터: 애플리케이션/모듈/기능은 로드 밸런싱을 통해 외부 액세스를 제공하기 위해 여러 복사본(예: 여러 물리적 시스템)에 배포됩니다.
• 캐싱: 액세스 속도를 높이기 위해 애플리케이션이나 사용자에 가장 가까운 데이터를 배치합니다.
• 비동기: 동기 작업을 비동기화합니다. 클라이언트는 서버가 응답할 때까지 기다리지 않고 요청을 보냅니다. 서버는 처리를 완료한 후 알림이나 폴링을 사용하여 요청자에게 알립니다. 일반적으로 요청-응답-알림 모드를 나타냅니다.
• 중복성: 복제본을 늘려 가용성, 보안 및 성능을 향상합니다.
• 보안: 알려진 문제에 대한 효과적인 솔루션을 확보하고 알려지지 않은/잠재적인 문제에 대한 검색 및 방어 메커니즘을 구축합니다.
• 자동화: 기계를 사용하여 도구를 통해 사람의 개입이 필요하지 않은 반복적인 작업을 완료합니다.
• 민첩성: 요구 사항의 변화를 적극적으로 수용하고 비즈니스 개발 요구 사항에 신속하게 대응합니다.

4. 고성능 아키텍처

는 사용자 중심이며 빠른 웹 액세스 경험을 제공합니다. 주요 매개변수는 짧은 응답 시간, 대규모 동시 처리 능력, 높은 처리량 및 안정적인 성능 매개변수입니다.

프론트엔드 최적화, 애플리케이션 계층 최적화, 코드 계층 최적화, 스토리지 계층 최적화로 나눌 수 있습니다.

• 프런트 엔드 최적화: 웹사이트 비즈니스 로직 이전 부분
• 브라우저 최적화: HTTP 요청 수 감소, 브라우저 캐시 사용, 압축 활성화, CSS JS 위치, JS 비동기, 쿠키 전송 감소; 가속, 역방향 프록시;
• 애플리케이션 계층 최적화: 웹사이트 비즈니스를 처리하는 서버. 캐시 사용, 비동기식, 클러스터
• 코드 최적화: 합리적인 아키텍처, 멀티스레딩, 리소스 재사용(개체 풀, 스레드 풀 등), 우수한 데이터 구조, JVM 튜닝, 싱글톤, 캐시 등;
• 스토리지 최적화: 캐시, 솔리드 스테이트 드라이브, 광섬유 전송, 최적화된 읽기 및 쓰기, 디스크 중복성, 분산 스토리지(HDFS), NoSQL 등

5. 고가용성 아키텍처

대규모 웹사이트는 항상 접근 가능해야 하며 정상적인 외부 서비스를 제공해야 합니다. 대규모 웹사이트의 복잡성, 분산, 저렴한 서버, 오픈소스 데이터베이스, 운영 체제 및 기타 특성으로 인해 고가용성을 보장하기 어렵습니다. 이는 웹사이트 장애가 불가피하다는 것을 의미합니다.

사용성을 어떻게 개선할 것인가는 시급히 해결해야 할 문제입니다. 우선 아키텍처 수준에서 고려하고, 계획 시 가용성을 고려해야 합니다. 업계에서는 가용성 지표를 나타내는 데 일반적으로 4개의 9(99.99)와 같이 몇 개의 9를 사용하며, 1년에 허용되는 비가용 시간은 53분입니다.

다양한 수준에서 다양한 전략이 사용됩니다. 중복 백업 및 장애 조치는 일반적으로 고가용성 문제를 해결하는 데 사용됩니다.

• 애플리케이션 계층: 일반적으로 상태 비저장으로 설계되어 각 요청을 처리하는 데 사용되는 서버에 영향을 미치지 않습니다. 일반적으로 고가용성을 달성하기 위해 세션 동기화 문제를 해결해야 하는 로드 밸런싱 기술이 사용됩니다.
• 서비스 계층: 로드 밸런싱, 계층적 관리, 빠른 실패(시간 초과 설정), 비동기 호출, 서비스 저하, 멱등성 설계 등
• 데이터 계층: 중복 백업(콜드, 핫 백업[동기, 비동기], 웜 백업), 장애 조치(확인, 전송, 복구). 높은 데이터 가용성에 대한 유명한 이론적 근거는 CAP 이론(지속성, 가용성, 데이터 일관성[강한 일관성, 사용자 일관성, 최종 일관성])입니다.

6 확장성이란 원래 아키텍처 설계에 따라 하드웨어(서버)를 추가/감소하여 시스템의 처리 능력을 늘리거나 줄일 수 있습니다.

애플리케이션 레이어: 애플리케이션을 수직 또는 수평으로 분할합니다. 그런 다음 단일 기능(DNS, HTTP [역방향 프록시], IP, 링크 계층)에 대해 부하를 분산합니다.

• 서비스 계층: 애플리케이션 계층과 유사
• 데이터 계층: 하위 데이터베이스, 하위 테이블, NoSQL 등 일반적으로 사용되는 알고리즘 해시, 일관된 해시.
7. 확장 가능한 아키텍처

쉽게 기능 모듈을 추가/제거할 수 있으며 코드/모듈 수준에서 우수한 확장성을 제공합니다.

모듈화 및 구성요소화: 높은 응집력, 낮은 결합도, 향상된 재사용성 및 확장성.

• 안정적인 인터페이스: 안정적인 인터페이스를 정의합니다. 인터페이스는 변경되지 않지만 내부 구조는 "자유롭게" 변경될 수 있습니다.
• 디자인 패턴: 객체 지향 아이디어와 원리를 적용하고, 디자인 패턴을 사용하여 코드 수준에서 디자인합니다.
• 메시지 대기열: 메시지 대기열을 통해 상호 작용하여 모듈 간의 종속성을 분리하는 모듈식 시스템입니다.
• 분산 서비스: 공용 ​​모듈은 다른 시스템에서 사용하도록 제공하여 재사용성과 확장성을 향상시키는 서비스 지향적입니다.
8. 보안 아키텍처

알려진 문제에 대한 효과적인 솔루션을 갖추고 알 수 없거나 잠재적인 문제에 대한 검색 및 방어 메커니즘을 구축합니다. 보안 문제에 대해서는 먼저 보안 인식을 개선하고 이를 보장하기 위한 효과적인 보안 메커니즘을 정책 수준과 조직 수준에서 구축해야 합니다. 보안 검색 등 제도적 안전체계 구축을 강화한다. 동시에 안전과 관련된 모든 측면에 주의를 기울여야 합니다. 인프라 보안, 애플리케이션 시스템 보안, 데이터 기밀성 및 보안 등 보안 문제는 무시할 수 없습니다.

• 인프라 보안: 하드웨어 조달, 운영 체제 및 네트워크 환경 보안. 일반적으로 공식 채널을 사용하여 고품질 제품을 구매하고, 안전한 운영 체제를 선택하고, 적시에 취약점을 패치하고, 바이러스 백신 소프트웨어 및 방화벽을 설치합니다. 바이러스와 백도어로부터 보호하세요. 방화벽 정책을 설정하고, DDOS 방어 시스템을 구축하고, 공격 탐지 시스템을 사용하고, 서브넷 격리를 수행합니다.
• 응용 프로그램 시스템 보안: 프로그램 개발 중에 올바른 방법을 사용하여 코드 수준에서 알려진 일반적인 문제를 해결합니다. XSS(교차 사이트 스크립팅 공격), 삽입 공격, CSRF(교차 사이트 요청 위조), 오류 메시지, HTML 주석, 파일 업로드, 경로 탐색 등을 방지합니다. 또한 웹 애플리케이션 방화벽(예: ModSecurity)을 사용하여 보안 취약성 검색 및 기타 조치를 수행하여 애플리케이션 수준 보안을 강화할 수 있습니다.
• 데이터 기밀성 및 보안성 : 저장보안(신뢰할 수 있는 장비에 저장, 실시간, 예약백업), 보존보안(중요정보를 암호화하여 보존, 복합보존 및 탐지에 적합한 인력 선발 등), 전송보안 (데이터 도용 및 데이터 변조 방지)

일반적으로 사용되는 암호화 및 복호화 알고리즘(단일 해시 암호화[MD5, SHA], 대칭 암호화[DES, 3DES, RC]), 비대칭 암호화[RSA] 등

9. Agility

웹 사이트의 아키텍처 설계와 운영 및 유지 관리는 변화에 적응하고 높은 확장성을 제공해야 합니다. 급속한 비즈니스 개발, 트래픽이 많은 액세스의 갑작스러운 증가 및 기타 요구 사항에 편리하게 대처할 수 있습니다.

위에 소개된 아키텍처 요소 외에도 애자일 관리 및 애자일 개발 아이디어를 도입하는 것도 필요합니다. 비즈니스, 제품, 기술, 운영 및 유지 관리를 통합하고 요구 사항에 적응하며 신속하게 대응합니다.

10. 대규모 아키텍처의 예

위는 7개 계층의 논리적 아키텍처를 사용하며, 첫 번째 계층은 고객 계층, 두 번째 계층은 프런트엔드 최적화 계층, 세 번째는 계층은 애플리케이션 계층, 네 번째 계층은 서비스 계층, 다섯 번째 계층은 첫 번째 계층은 데이터 저장 계층, 여섯 번째 계층은 빅데이터 저장 계층, 일곱 번째 계층은 빅데이터 처리 계층이다.

• 고객 레이어: PC 브라우저와 모바일 앱을 지원합니다. 차이점은 모바일 APP은 IP와 역방향 프록시 서버를 통해 직접 접속할 수 있다는 점입니다.
• 프런트 엔드 레이어: DNS 로드 밸런싱, CDN 로컬 가속 및 역방향 프록시 서비스 사용
• 애플리케이션 레이어: 제품 애플리케이션, 회원 센터 등 비즈니스에 따라 수직으로 분할되는 웹사이트 애플리케이션 클러스터;
• 서비스 레이어: 사용자 서비스, 주문 서비스, 결제 서비스 등의 공공 서비스를 제공합니다.
• 데이터 레이어: 관계형 데이터베이스 클러스터(읽기-쓰기 분리 지원), NOSQL 클러스터, 분산 파일 시스템을 지원합니다. 클러스터 및 분산 캐시
• 빅 데이터 저장 계층: 애플리케이션 계층 및 서비스 계층의 로그 데이터 수집, 관계형 데이터베이스 및 NOSQL 데이터베이스의 구조적 및 반구조적 데이터 수집을 지원합니다. Mapreduce Data 분석이나 Storm 실시간 데이터 분석을 통해 오프라인으로 처리되며, 처리된 데이터는 관계형 데이터베이스에 저장됩니다. (실제 사용 시 오프라인 데이터와 실시간 데이터는 비즈니스 요구 사항에 따라 분류 및 처리되며 애플리케이션 계층 또는 서비스 계층에서 사용하기 위해 서로 다른 데이터베이스에 저장됩니다.)

대규모 전자상거래 웹사이트의 시스템 아키텍처의 진화

성숙한 대규모 웹사이트(예: Taobao, Tmall, Tencent 등)의 시스템 아키텍처는 설계되지 않았습니다. 처음부터 완벽한 고성능, 고가용성, 높은 확장성 및 기타 특성을 갖추고 있으며, 사용자 수의 증가와 비즈니스 기능의 확장에 따라 점차 발전하고 개선되었습니다. 디자인 아이디어도 큰 변화를 겪었습니다. 기술 인력도 소수에서 부서, 심지어는 제품 라인으로 성장했습니다. 그래서 성숙한 시스템 아키텍처는 비즈니스 확장과 함께 점차 개선되며 이는 하루아침에 달성되지 않습니다. 다양한 비즈니스 특성을 가진 시스템은 Taobao와 같이 검색, 주문 및 처리를 해결해야 하는 자체 초점을 갖게 됩니다. 예를 들어, Tencent는 수억 명의 사용자에 대한 실시간 메시지 전송을 처리해야 합니다.

모두 고유한 비즈니스 특성을 갖고 있으며 시스템 아키텍처도 다릅니다. 그럼에도 불구하고 이러한 다양한 웹사이트 배경에서 공통된 기술을 찾을 수 있습니다. 이러한 기술과 방법은 대규모 웹사이트 시스템의 아키텍처에서 널리 사용됩니다. 대규모 웹사이트 시스템의 진화 과정을 소개하여 이러한 기술과 방법을 이해해 보겠습니다. 수단.

초기 웹 사이트 아키텍처

그림과 같이 초기 아키텍처, 애플리케이션, 데이터베이스 및 파일이 모두 서버에 배포됩니다.

2. 애플리케이션, 데이터, 파일의 분리

비즈니스 확장으로 인해 하나의 서버가 더 이상 성능 요구 사항을 충족할 수 없어 애플리케이션, 데이터베이스, 파일이 별도의 서버에 배포되고, 최상의 성능 결과를 얻으려면 서버의 목적에 따라 다양한 하드웨어를 구성하십시오.

3. 캐싱을 사용하여 웹 사이트 성능 향상

하드웨어 성능을 최적화하는 동시에 소프트웨어를 통해서도 성능을 최적화합니다. 캐싱은 주로 핫 데이터의 존재로 인해 발생합니다. 대부분의 웹 사이트 방문은 28 원칙(즉, 액세스 요청의 80%가 데이터의 20%에서 발생함)을 따르므로 이러한 데이터에 대한 액세스를 줄이기 위해 핫 데이터를 캐시할 수 있습니다. 사용자 경험을 향상시키는 길.

캐시를 구현하는 일반적인 방법은 로컬 캐시와 분산 캐시가 있습니다. 물론 CDN, 역방향 프록시 등도 있는데 이에 대해서는 나중에 설명하겠습니다. 이름에서 알 수 있듯이 로컬 캐시는 애플리케이션 서버에 로컬로 데이터를 캐시하거나 메모리에 저장할 수 있습니다. OSCache는 일반적으로 사용되는 로컬 캐시 구성 요소입니다. 로컬 캐시의 특징은 속도가 빠르지만, 로컬 공간이 제한되어 있기 때문에 캐시되는 데이터의 양도 제한됩니다. 분산 캐시의 특징은 대용량 데이터를 캐시할 수 있고 확장이 매우 쉽다는 점입니다. 포털 웹사이트에서 자주 사용되며 일반적으로 사용되는 분산 캐시로는 Memcached 및 Redis만큼 빠르지 않습니다.

4. 애플리케이션 서버 성능 향상을 위해 클러스터 사용

웹사이트 입구로서 애플리케이션 서버는 요청 수를 공유하기 위해 종종 애플리케이션 서버 클러스터를 사용합니다. 로드 밸런싱 서버는 애플리케이션 서버 앞에 배포되어 사용자 요청을 예약하고 배포 정책에 따라 요청을 여러 애플리케이션 서버 노드에 분산합니다.

일반적으로 사용되는 로드 밸런싱 기술 하드웨어로는 상대적으로 고가인 F5가 있고, 소프트웨어로는 LVS, Nginx, HAProxy가 있습니다. LVS는 대상 주소와 포트를 기반으로 내부 서버를 선택하는 4계층 로드 밸런싱입니다. Nginx 및 HAProxy는 메시지 내용을 기반으로 내부 서버를 선택할 수 있는 7계층 로드 밸런싱입니다. Nginx 및 HAProxy는 성능이 더 높습니다. Nginx 및 HAProxy는 더 구성 가능하며 동적 및 정적 분리에 사용할 수 있습니다(요청 메시지의 특성에 따라 정적 리소스 서버 또는 애플리케이션 서버 선택).

5. 데이터베이스 읽기와 쓰기 분리 및 데이터베이스와 테이블 샤딩

사용자 수가 증가하면서 데이터베이스 성능을 향상시키는 가장 큰 병목 현상이 발생했습니다. 샤드 데이터베이스 및 테이블 읽기 및 쓰기 이름에서 알 수 있듯이 분리는 데이터베이스를 읽기 데이터베이스와 쓰기 데이터베이스로 나누고 기본 기능과 보조 기능을 통해 데이터 동기화를 달성하는 것입니다. 데이터베이스 샤딩과 테이블 샤딩은 수평 샤딩과 수직 샤딩으로 구분됩니다. 수평 샤딩은 사용자 테이블과 같이 데이터베이스 내 매우 큰 테이블을 분할하는 것입니다. 수직적 세분화는 다양한 비즈니스를 기반으로 합니다. 예를 들어 사용자 비즈니스와 제품 비즈니스와 관련된 테이블은 서로 다른 데이터베이스에 배치됩니다.

6. CDN 및 역방향 프록시를 사용하여 웹 사이트 성능 향상

저희 서버를 청두의 컴퓨터실에 배포하면 쓰촨성 사용자의 경우 액세스가 더 빨라지지만 베이징 사용자의 경우 액세스가 더 빨라집니다. 이는 쓰촨성과 베이징이 각각 차이나 텔레콤과 차이나 유니콤의 다른 개발 지역에 속하기 때문입니다. 베이징 사용자는 청두의 서버에 액세스하려면 더 긴 경로를 거쳐야 합니다. 그래서 데이터 전송 시간이 더 길어집니다. 이러한 상황에서 CDN은 문제를 해결하기 위해 자주 사용됩니다. 사용자가 데이터에 액세스하면 먼저 가장 가까운 운영자로부터 데이터를 가져오므로 네트워크 액세스 경로가 크게 줄어듭니다. 보다 전문적인 CDN 운영자로는 Lanxun과 Wangsu가 있습니다.

역방향 프록시는 사용자 요청이 도착하면 먼저 역방향 프록시 서버에 액세스합니다. 캐시된 데이터가 없으면 역방향 프록시 서버가 사용자에게 캐시된 데이터를 반환합니다. 이를 얻기 위해 애플리케이션 서버에 계속 액세스하면 데이터를 얻는 데 드는 비용이 줄어듭니다. 역방향 프록시에는 Squid 및 Nginx가 포함됩니다.

7. 분산 파일 시스템 사용

사용자 수가 날로 증가하고, 비즈니스 규모가 점점 커지고, 점점 더 많은 파일이 생성됩니다. 단일 파일 서버로는 불가능합니다. 더 이상 수요를 충족하려면 분산 파일 시스템의 지원이 필요합니다. 일반적으로 사용되는 분산 파일 시스템에는 GFS, HDFS 및 TFS가 있습니다.

8. NoSQL 및 검색 엔진 사용

대량 데이터의 쿼리 및 분석을 위해 NoSQL 데이터베이스와 검색 엔진을 사용하여 더 나은 성능을 얻습니다. 모든 데이터를 관계형 데이터에 배치할 필요는 없습니다. 일반적으로 사용되는 NoSQL에는 MongoDB, HBase 및 Redis가 포함되며 검색 엔진에는 Lucene, Solr 및 Elasticsearch가 있습니다.

9. 애플리케이션 서버를 비즈니스로 분할

비즈니스가 더욱 확장됨에 따라 애플리케이션이 매우 비대해집니다. 예를 들어 Baidu는 비즈니스로 분할해야 합니다. 뉴스, 웹 페이지, 사진 및 기타 서비스. 각 비즈니스 애플리케이션은 상대적으로 독립적인 비즈니스 운영을 담당합니다. 기업은 메시지를 통해 소통하거나 데이터베이스를 공유합니다.

10. 분산 서비스 구축

이때 각 비즈니스 애플리케이션은 사용자 서비스, 주문 서비스, 결제 서비스 및 보안 서비스와 같은 몇 가지 기본적인 비즈니스 서비스를 사용한다는 것을 확인했습니다. 모든 비즈니스 애플리케이션의 기본 요소를 지원합니다. 우리는 이러한 서비스를 추출하고 분산 서비스 프레임워크를 사용하여 분산 서비스를 구축합니다. Ali의 Dubbo가 좋은 선택입니다.

전자상거래 아키텍처를 설명하는 그림

대형 전자상거래 웹사이트 아키텍처 사례

1. 전자상거래의 이유 사례

현재 분산된 대규모 웹사이트에는 몇 가지 주요 카테고리가 있습니다:

• NetEase, Sina 등의 대형 포털
• Xiaonei, Kaixin.com 등의 SNS 웹사이트
• Alibaba, JD.com 등의 전자상거래 웹사이트 고메온라인, 오토홈 등

대규모 포털은 일반적으로 뉴스 정보이며 CDN, 정적화 등을 사용하여 최적화할 수 있습니다. Kaixin.com 및 기타 웹사이트는 더욱 대화형이며 더 많은 NoSQL, 분산 캐싱을 도입하고 고성능 통신 프레임워크를 사용할 수 있습니다. 등. 전자상거래 웹사이트는 위의 두 카테고리의 특성을 가지고 있습니다. 예를 들어, 제품 세부정보는 CDN을 사용할 수 있고 정적이며, 상호작용성이 높은 웹사이트는 NoSQL 및 기타 기술을 사용해야 합니다. 따라서 우리는 전자상거래 웹사이트를 분석 사례로 활용한다.

2. 전자상거래 웹사이트 요구사항

고객 요구사항:

• 사용자가 온라인으로 상품을 구매하거나, 온라인으로 결제하거나, 배송 시 결제할 수 있는 전체 카테고리 전자상거래 웹사이트(B2C)를 구축하세요.
• 사용자는 구매 시 온라인으로 고객 서비스와 소통할 수 있습니다.
• 상품을 받은 후 사용자는 상품을 평가하고 평가할 수 있습니다.
• 현재 성숙한 구매, 판매 및 재고 시스템이 필요합니다.
• 3~5년 안에 사업 발전을 지원하길 바랍니다.
• 3~5년 안에 사용자 수가 1천만 명에 이를 것으로 예상됩니다.
• 정기적으로 더블 11을 구성합니다. , 더블 12, 3월 8일 남성의 날 및 기타 활동
• 기타 기능에 대해서는 JD.com 또는 Gome Online과 같은 웹사이트를 참조하세요.

고객은 자신이 원하는 것을 구체적으로 알려주지 않고 고객의 요구 사항을 안내하고 탐색해야 하는 경우가 많습니다. 다행스럽게도 명확한 참조 웹사이트가 제공됩니다. 따라서 다음 단계는 대규모 분석을 수행하고 업계와 참조 웹사이트를 결합하여 고객에게 솔루션을 제공하는 것입니다.

요구 사항 기능 매트릭스요구 사항 관리에 대한 전통적인 접근 방식에서는 사용 사례 다이어그램 또는 모듈 다이어그램(요구 사항 목록)을 사용하여 요구 사항을 설명합니다. 그렇게 하면 매우 중요한 요구사항(비기능 요구사항)을 간과하는 경우가 많으므로 요구사항 기능 매트릭스를 사용하여 요구사항을 설명하는 것이 좋습니다. 이 전자상거래 웹사이트의 수요 매트릭스는 다음과 같습니다.

3. 웹사이트 기본 구조

일반 웹사이트의 초기 접근 방식은 3개의 서버로, 하나는 애플리케이션 배포용이고 다른 하나는 배포용입니다. 데이터베이스를 배포하고 하나는 NFS 파일 시스템을 배포합니다.

이것은 지난 몇 년 동안 비교적 전통적인 접근 방식입니다. 회원 수가 10만 명이 넘는 웹사이트와 수직 의류 디자인 포털, 그리고 수많은 사진을 본 적이 있습니다. 서버는 애플리케이션, 데이터베이스 및 이미지 스토리지를 배포하는 데 사용됩니다. 성능상의 문제가 많았습니다. 아래와 같이:

그러나 현재 주류 웹 사이트 아키텍처는 엄청난 변화를 겪었습니다. 일반적으로 고가용성 설계에는 클러스터 접근 방식이 사용됩니다. 최소한 다음과 같습니다.

• 클러스터를 중복 애플리케이션 서버에 사용하여 고가용성을 달성합니다. (로드 밸런싱 장비는 애플리케이션과 함께 배포할 수 있습니다.)
• 데이터베이스 사용 데이터 백업 및 고가용성을 달성하기 위한 마스터 백업 모드

4. 시스템 용량 추정추정 단계:

등록된 사용자 수 - 일일 평균 UV 볼륨 - 일일 금액
최대 추정치: 평소의 2~3배
동시성(동시성, 트랜잭션 수) 및 저장 용량을 기준으로 시스템 용량을 계산합니다.
고객 요구에 따라: 사용자 수는 3~5년 내에 등록 사용자 1,000만 명에 도달할 것이며 초당 동시 사용자 수는 다음과 같이 추정할 수 있습니다.

• 일일 UV는 200만(28개 원칙)입니다.
• 하루 30회 클릭
• PV 볼륨: 200*30=6000만
• 집중 방문수: 24 0.2=4. 8시간 , 6천만 0.8=4,800만(28개 원칙);
• 분당 동시성: 4.8*60=288분, 분당 4800/288=167,000회 방문(대략 동일); 초당: 167,000/60=2780(대략 동일)
• 피크 기간이 정상 값의 3배라고 가정하면 초당 동시 실행 횟수는 8340에 도달할 수 있습니다.
• 1밀리초 = 1.3회 방문
• 수학을 잘 공부하지 못한 것을 후회하시나요? ! (위 계산이 틀린지는 모르겠지만, 하하~~) 서버 추정: (Tomcat 서버를 예로 들어) 웹 서버에 따르면 초당 300개의 동시 계산을 지원합니다. 일반적으로 10개의 서버가 필요합니다(대략 동일). [Tomcat 기본 구성은 150], 피크 기간에는 30개의 서버가 필요합니다. 추정 용량은 70/90입니다. 시스템 CPU는 일반적으로 약 70%를 유지하며 피크 기간에는 90%에 도달하며 리소스를 낭비하지 않으며 비교적 안정적입니다. 메모리와 IO는 비슷합니다. 서버 구성, 비즈니스 로직 복잡성 등이 모두 영향을 미치기 때문에 위 추정치는 참고용일 뿐입니다. 여기서는 CPU, 하드 디스크, 네트워크 등이 더 이상 평가되지 않습니다. 5. 웹사이트 아키텍처 분석 위의 추정에 따르면 몇 가지 문제가 있습니다.

대규모 서버를 배포해야 하며 피크 기간에는 30개의 웹 서버를 배포할 수 있습니다. 게다가 이 30대의 서버는 반짝 세일이나 이벤트 기간에만 사용되기 때문에 낭비가 많습니다.

• 모든 애플리케이션이 동일한 서버에 배포되며 애플리케이션 간의 결합이 심각합니다. 수직 및 수평 절단이 필요합니다.
• 많은 수의 애플리케이션에 중복 코드가 있습니다
• 서버 세션 동기화는 많은 메모리와 네트워크 대역폭을 소비합니다
• 데이터가 데이터베이스에 자주 액세스해야 하며 데이터베이스 액세스 압력이 엄청납니다.
• 대형 웹사이트에서는 일반적으로 다음과 같은 아키텍처 최적화를 수행해야 합니다. (최적화는 아키텍처를 설계할 때 고려해야 할 사항입니다. 일반적으로 아키텍처/코드 수준에서 해결됩니다. 튜닝은 주로 JVM 튜닝과 같은 간단한 매개변수의 조정입니다. 튜닝에 다수의 코드 수정이 튜닝이 아닌 리팩토링과 관련된 경우):
  • 비즈니스 분할
  • 애플리케이션 클러스터 배포(분산 배포, 클러스터 배포 및 로드 밸런싱)
  • 다단계 캐시
  • Single Sign-On(분산 세션)
  • 데이터베이스 클러스터( 읽기 및 쓰기 분리, 하위 데이터베이스 및 하위 테이블)
  • Serviceization
  • 메시지 대기열
  • 기타 기술

  6. 웹사이트 아키텍처 최적화

  6. 1 사업 분할

  비즈니스 속성에 따른 수직적 세분화, 제품 하위 시스템, 쇼핑 하위 시스템, 결제 하위 시스템, 리뷰 하위 시스템, 고객 서비스 하위 시스템, 인터페이스 하위 시스템(구매, 판매, 재고, SMS 등 외부 시스템과 연결)으로 구분됩니다. 비즈니스 하위 시스템의 계층적 정의에 따라 핵심 시스템과 비핵심 시스템으로 나눌 수 있습니다. 핵심 시스템: 제품 하위 시스템, 쇼핑 하위 시스템, 결제 하위 시스템, 비핵심: 검토 하위 시스템, 고객 서비스 하위 시스템, 인터페이스 하위 시스템.

  • 비즈니스 분할의 역할: 하위 시스템으로의 업그레이드는 전문 팀과 부서에서 처리할 수 있으며, 전문 인력은 모듈 간의 결합 및 확장성 문제를 해결하기 위해 전문적인 작업을 수행합니다. 각 하위 시스템은 중앙 집중식 배포로 이어지는 것을 방지하기 위해 별도로 배포됩니다. 애플리케이션이 중단되고 모든 애플리케이션을 사용할 수 없습니다.
  • 레벨 정의의 역할: 트래픽 버스트 중에 주요 애플리케이션을 보호하고 정상적인 성능 저하를 달성하는 데 사용됩니다.

  분할 후 아키텍처 다이어그램:

  

  
  

  참조 배포 계획 2

  

  
  

  위와 같이 각 애플리케이션이 별도로 배포되고, 핵심 시스템과 비핵심 시스템이 배포됩니다. 조합

  6.2 애플리케이션 클러스터 배포(분산, 클러스터링, 로드 밸런싱)

  • 분산 배포: 사업 분할 후 애플리케이션은 별도로 배포되며, 애플리케이션은 RPC를 통해 직접 원격으로 통신합니다.
  • 클러스터 배포: 높음 전자상거래 웹사이트의 가용성 요구 사항. 각 애플리케이션은 클러스터 배포를 위해 최소 2개의 서버를 배포해야 합니다.
  • 로드 밸런싱: 고가용성 시스템에 필요합니다. 일반적으로 애플리케이션은 로드 밸런싱을 통해 고가용성을 달성하며, 분산 서비스는 구축됩니다. -in 로드 밸런싱은 고가용성을 달성하고, 관계형 데이터베이스는 활성 및 백업 방식을 통해 고가용성을 달성합니다.

  클러스터 배포 후 아키텍처 다이어그램:

  

  
  

  6.3 다단계 캐시

  캐시는 일반적으로 저장 위치에 따라 로컬 캐시와 분산 캐시의 두 가지 유형으로 나눌 수 있습니다. 이 경우에는 두 번째 수준 캐시 방법을 사용하여 캐시를 설계합니다. 첫 번째 수준 캐시는 로컬 캐시이고 두 번째 수준 캐시는 분산 캐시입니다. (보다 세분화된 페이지 캐싱, 프래그먼트 캐싱 등도 있습니다) 1단계 캐시, 캐시 데이터 사전, 일반적으로 사용되는 핫스팟 데이터 및 기타 기본적으로 변경 불가능/정기적으로 변경되는 정보인 2단계 캐시는 필요한 모든 캐시를 캐시합니다. 첫 번째 수준 캐시가 만료되거나 사용할 수 없게 되면 두 번째 수준 캐시의 데이터에 액세스됩니다. 두 번째 수준 캐시가 없으면 데이터베이스에 액세스됩니다. 캐시 비율은 일반적으로 1:4이며 캐시 사용을 고려할 수 있습니다. (이론적으로는 1:2면 충분합니다.)

  

  
  

  비즈니스 특성에 따라 다음 캐시 만료 전략을 사용할 수 있습니다.

  • 캐시 자동 만료
  • 캐시 트리거 만료; (분산 세션)

  시스템은 여러 하위 시스템으로 나누어져 있으며 독립적으로 배포한 후에는 필연적으로 세션 관리 문제가 발생합니다. 일반적으로 세션 동기화, 쿠키 및 분산 세션 방법을 사용할 수 있습니다. 전자상거래 웹사이트는 일반적으로 분산 세션을 사용하여 구현됩니다. 또한 분산 세션을 기반으로 완전한 Single Sign-On 또는 계정 관리 시스템을 구축할 수 있습니다.

  프로세스 설명

  • 사용자가 처음 로그인할 때 사용자 ID를 키로 사용하는 등 세션 정보(사용자 ID 및 사용자 정보)를 분산 세션에 기록합니다.
  • 사용자가 다시 로그인할 때 , 분산된 세션을 얻으세요. 세션 정보가 없으면 로그인 페이지로 이동하세요.
  • 일반적으로 Cache 미들웨어를 사용하여 구현되므로 로드를 용이하게 하는 지속성 기능이 있습니다. 분산 세션이 다운된 후 영구 저장소의 세션 정보입니다. ;
  • 세션을 저장할 때 세션 보존 시간을 15분 등으로 설정할 수 있으며, 이를 초과하면 자동으로 시간 초과됩니다. 캐시 미들웨어와 결합하여 구현된 분산 세션은 세션 세션을 잘 시뮬레이션할 수 있습니다.

  6.5 데이터베이스 클러스터(읽기-쓰기 분리, 하위 데이터베이스 및 하위 테이블)

  대형 웹사이트에서는 대용량 데이터 저장, 고가용성, 고성능을 달성하기 위해 대용량 데이터를 저장해야 합니다. 시스템은 일반적으로 중복 방식으로 설계됩니다. 일반적으로 읽기와 쓰기를 분리하는 방법과 하위 데이터베이스와 테이블을 분리하는 방법에는 두 가지가 있습니다. 읽기 및 쓰기 분리: 일반적으로 읽기 비율이 쓰기 비율보다 훨씬 큰 시나리오를 해결하기 위해 하나의 마스터와 하나의 백업, 하나의 마스터와 다중 백업 또는 다중 마스터와 다중 백업을 사용할 수 있습니다. 이 사례는 데이터베이스 샤딩, 테이블 샤딩 및 읽기-쓰기 분리와 결합된 비즈니스 분할을 기반으로 합니다. 아래와 같이:

  

  
  

  비즈니스 분할 후: 각 하위 시스템에는 별도의 라이브러리가 필요합니다.

  • 별도의 라이브러리가 너무 큰 경우 비즈니스 특성에 따라 다시 라이브러리로 분할될 수 있습니다. 제품 분류 라이브러리로,
  • 데이터베이스를 분할한 후 테이블에 데이터 양이 많을 경우 일반적으로 테이블을 ID, 시간 등에 따라 분할할 수 있습니다. .; (고급 사용법은 일관된 해시)
  하위 데이터베이스 및 테이블을 기반으로 별도의 읽기 및 쓰기
  관련 미들웨어는 Cobar(Alibaba, 현재 더 이상 유지되지 않음), TDDL(Alibaba)을 ​​참조할 수 있습니다. , Atlas(Qihoo 360) 및 MyCat이 있습니다. 샤딩 데이터베이스와 테이블의 테마 공유에서는 데이터베이스와 테이블을 샤딩한 후 시퀀스, JOIN, 트랜잭션 관련 문제가 소개됩니다.
  6.6 Servitization

  여러 하위 시스템에 공통적인 기능/모듈을 추출하여 공용 서비스로 사용합니다. 예를 들어 이 경우 멤버십 하위 시스템은 공용 서비스로 추출될 수 있습니다.

  

  
  

  6.7 메시지 대기열

  메시지 대기열은 하위 시스템/모듈 간의 결합을 해결하고 비동기식, 고가용성, 고성능 시스템을 달성할 수 있습니다. 이는 분산 시스템의 표준 구성입니다. 이 경우 메시지 큐는 주로 쇼핑 및 배송 링크에 사용됩니다.

  • 사용자가 주문한 후 메시지 대기열에 기록된 다음 클라이언트에 직접 반환됩니다.
  • 인벤토리 하위 시스템: 메시지 대기열 정보를 읽고
  • 배포 하위 시스템: 배포를 위해 메시지 큐 정보를 읽습니다.

  

  
  

  현재 가장 일반적으로 사용되는 MQ에는 Active MQ, Rabbit MQ, Zero MQ, MS MQ 등이 있으며 특정 항목에 따라 선택해야 합니다. 비즈니스 시나리오. Rabbit MQ를 공부하는 것이 좋습니다.

  6.8 기타 아키텍처(기술)

  위에 소개된 비즈니스 분할, 애플리케이션 클러스터, 다중 레벨 캐싱, Single Sign-On, 데이터베이스 클러스터, 서비스화 및 메시지 대기열 외에도. CDN, 역방향 프록시, 분산 파일 시스템, 빅 데이터 처리 및 기타 시스템도 있습니다. 여기서는 자세히 소개하지 않겠습니다. 기회가 있으면 Du Niang/Google에 문의해도 됩니다.

  아키텍처 요약

  

  
  

  대규모 웹사이트의 아키텍처는 비즈니스 요구에 따라 지속적으로 개선되며, 구체적인 디자인과 고려 사항은 다양한 비즈니스 특성에 따라 만들어집니다. 일반적인 대규모 웹사이트에 관한 기술과 방법 중 일부가 여러분에게 영감을 주기를 바랍니다.

위 내용은 10분만에 해결되는 대규모 분산형 전자상거래 시스템 아키텍처 |의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!