중국어 이름
웹 사이트 아키텍처
사람들은 일반적으로
고객 요구에 따른 분석 결과
계획
웹 사이트 개발 프로세스 및 순서
내용
프로세스 아키텍처, 표현 아키텍처
빠른
항행
부드러운 건물의 8 가지 방안
하드아키텍처
컴퓨터실 선택
기계실을 선택할 때는 사이트 사용자의 지리적 분포에 따라 인터넷통이나 통신실을 선택할 수 있지만, 더 많은 경우 이중선실이 더 적합할 수 있습니다. 도시가 클수록 기계실이 더 비싸다. 비용 측면에서 볼 때 서버는 일부 중소 도시에서 호스팅할 수 있습니다. 예를 들어 베이징의 회사는 천진 랑방 등지에서 서버를 호스팅하는 것을 고려해 볼 수 있는데, 그리 멀지 않지만 가격이 훨씬 싸질 것이다.
대역폭의 크기입니다
사장이 우리에게 웹사이트를 지을 때, 매일 654.38+0 만 개의 PV 방문량을 감당할 수 있는 웹사이트와 같은 목표를 주는 경우가 많다. (토마스 A. 에디슨, 일명언) 이때, 우리는 얼마나 많은 대역폭이 필요한지 추산해야 한다. 대역폭 계산에는 주로 두 가지 지표 (최대 트래픽 및 페이지 크기) 가 포함됩니다. 우리는 계산하기 전에 필요한 가정을 할 수 있습니다.
첫째, 피크 유속이 평균 유속의 5 배라고 가정합니다.
둘째: 방문당 평균 페이지 크기가 약 100K 바이트라고 가정합니다.
1 만PV 의 방문이 하루 동안 균등하게 분산되면 초당 12 회 정도의 방문수와 같습니다. 액세스당 평균 페이지 크기가 약100kb 인 경우 이 12 액세스의 합계는 약1200kb 이고 바이트 단위는 byte 이고 대역폭 단위는 bit 입니다. 이들 사이의 관계는 1Byte = 8bit 이므로 1200K Byte 는 대략 9600K bit, 즉 9Mbps 에 해당합니다. 사실, 우리 웹 사이트는 트래픽 피크 시간대에 정상적인 액세스를 유지할 수 있어야 하므로 가상 트래픽 피크에 따라 실제 대역폭 요구 사항은 약 45Mbps 여야 합니다.
물론, 이 결론은 위에서 언급한 두 가지 가정에 근거한 것이다. 만약 너의 실제 상황이 이 두 가설과 다르다면 결과는 다르다.
서버의 구분
먼저 사진 서버, 페이지 서버, 데이터베이스 서버, 애플리케이션 서버, 로그 서버 등 필요한 서버를 살펴보겠습니다.
방문량이 많은 웹사이트의 경우, 별도의 그림 서버와 페이지 서버를 분리하는 것이 매우 필요하다. Lighttpd 를 사용하여 그림 서버를 실행하고 Apache 를 사용하여 페이지 서버를 실행할 수 있습니다. 물론, 우리도 다른 것을 선택할 수 있다. 심지어 우리는 많은 그림 서버, 많은 페이지 서버, 관련 도메인 이름 (예: img.domain, www.domain) 을 설정할 수 있습니다. 페이지의 그림 경로는 모두 절대 경로를 사용합니다. 예를 들면 다음과 같습니다.
웹 사이트의 병목 현상이 십중팔구 데이터베이스이기 때문에 데이터베이스 서버가 가장 중요하다. 일반적으로 중소형 사이트는 MySQL 데이터베이스를 많이 사용하지만 클러스터링 기능은 아직 안정화 단계에 이르지 않은 것 같습니다. 여기서는 언급하지 않습니다. 일반적으로 MySQL 데이터베이스를 사용할 때는 마스터-슬레이브 (마스터-슬레이브) 구조가 있어야 합니다. 기본 데이터베이스 서버는 innodb 테이블 구조를 사용하고, 데이터 서버는 myisam 테이블 구조를 사용하여 각각의 장점을 최대한 활용합니다. 또한 이러한 마스터-슬레이브 구조는 읽기 및 쓰기 작업을 분리하여 읽기 작업의 부담을 덜어주며, 전용 슬레이브 서버를 백업 서버로 설정하여 백업을 용이하게 할 수 있습니다. 그렇지 않으면 주 서버가 한 대밖에 없다면, 데이터 양이 많은 경우 mysqldump 는 거의 희망이 없습니다. 데이터 파일을 직접 복제하는 경우 복제하기 전에 데이터베이스 서비스를 중지해야 합니다. 그렇지 않으면 백업 파일에 오류가 발생합니다. 그러나 많은 웹 사이트에서는 데이터베이스 서비스가 1 초만 중지되더라도 용납할 수 없습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 데이터베이스 서비스, 데이터베이스 서비스, 데이터베이스 서비스) 데이터베이스 서버에서 데이터를 백업할 때 백업 전에 서비스 (slave stop) 를 중지하고 서비스 (slave start) 를 시작하면 서버에 영향을 주지 않고 주 서버의 데이터를 자동으로 동기화할 수 있습니다. 그러나 마스터-슬레이브 구조에도 치명적인 단점이 있습니다. 즉, 마스터-슬레이브 구조는 읽기 작업의 압력을 줄일 뿐 쓰기 작업의 압력을 낮출 수는 없다는 것입니다.
더 큰 규모에 적응하기 위해 마지막 수단인 가로/세로 분할 데이터베이스만 남아 있을 수 있습니다. 가로로 데이터베이스를 분할하는 것은 다른 테이블을 다른 데이터베이스 서버에 저장하는 것입니다. 예를 들어, 사용자 테이블은 A 데이터베이스 서버에 저장되고 문장 테이블은 B 데이터베이스 서버에 저장됩니다. 물론 이런 분할은 대가가 있고, 가장 기본적인 것은 왼쪽 연결과 같은 작업을 할 수 없다는 것이다. 수직 분할 데이터베이스란 일반적으로 사용자 ID (user_id) 등으로 데이터 저장소를 나누는 서버를 말합니다. 예를 들어, "user_id% 5+ 1" 이 1 과 같으면 서버 1 에 저장하고 2 와 같으면 서버 2 에 저장합니다 그러나 데이터베이스의 가로 분할과 마찬가지로 데이터베이스의 세로 분할도 비용이 듭니다. 가장 기본적인 것은, 우리는 카운트, 합계 등의 요약 연산을 할 때 많은 번거로움을 겪게 될 것이다. 요약하자면, 데이터베이스 서버 솔루션은 다양한 솔루션의 장점을 최대한 활용할 수 있도록 필요에 따라 혼합 솔루션을 채택하고 있으며, 경우에 따라 더 많은 액세스 요구 사항을 충족하기 위해 memcached 와 같은 타사 소프트웨어가 필요합니다.
전용 응용 프로그램 서버가 PHP 스크립트를 실행하는 것이 가장 적절하기 때문에 페이지 서버는 정적 페이지만 저장할 수 있습니다. 응용 프로그램 서버에 대해 app.domain 과 같은 도메인 이름을 설정하여 페이지 서버와 구분할 수 있습니다. 응용 프로그램 서버의 경우 prefork 모드에서 Apache 를 사용하고 필요한 경우 xcache 와 같은 PHP 캐시 소프트웨어를 사용하는 것을 선호합니다. 로드된 모듈이 적을수록 좋습니다. Mod_rewrite 와 같은 필수 모듈을 제외한 모든 불필요한 것은 버려져 httpd 프로세스의 메모리 소비를 최소화하는 반면 이미지 서버, 페이지 서버 등의 정적 콘텐츠는 lighttpd 또는 tux 를 사용하여 다양한 서버의 특징을 최대한 활용할 수 있습니다.
조건이 허용하는 경우 별도의 로깅 서버도 필요합니다. 일반적으로 작은 웹 사이트는 페이지 서버와 로그 서버를 하나로 통합하는 것입니다. cron 은 새벽 트래픽이 적을 때 전날의 로그 계산을 실행합니다. 그러나 awstats 와 같은 로그 분석 소프트웨어를 사용하면 매일 수백만 명의 방문객을 아카이빙해도 계산에 많은 시간과 서버 자원이 소모되므로 개별 로그 서버를 분리하는 것이 좋으며 공식 서버의 작업 상태에는 영향을 주지 않습니다.
소프트 빌딩
프레임 선택
PHP 프레임워크에는 CakePHP, Symfony, Zend Framework 등 다양한 옵션이 있습니다. 어떤 것을 사용해야 하는지에 대한 유일한 답은 팀 구성원이 각 프레임워크에 대해 얼마나 잘 알고 있는지에 따라 다릅니다. 프레임워크를 사용하지 않아도 좋은 프로그램을 쓸 수 있는 경우가 많다. 예를 들어 Flickr 는 Pear+Smarty 와 같은 클래스 라이브러리로 쓰여졌다고 합니다. 따라서 프레임 워크를 사용할지 여부는 일반적으로 가장 중요하지 않습니다. 중요한 것은 우리가 프로그래밍 사고에서 프레임 의식을 가져야 한다는 것이다.
분류: 계층 논리