이 글은 "확장성이 뛰어난 웹사이트의 50가지 원칙"을 읽고 다음 내용을 요약한 것입니다.
블로거는 실제 건축 경험이 없고, 지식이 넓지 않기 때문에 책의 핵심 내용을 체계적으로 요약하고 다음과 같은 결론을 내릴 수 있을 뿐입니다. 그 자신의 이해.
주요 내용
확장성이 뛰어난 웹사이트는 비즈니스의 발전과 사용자의 증가에 따라 자유롭게 확장할 수 있도록 다양한 측면에서 50가지 제안을 제시합니다. 웹사이트의 급속한 발전. 이 책의 구체적인 내용을 살펴보자:
방정식 단순화
1 지나치게 디자인하지 마세요
과도한 디자인 시스템이 복잡해지고 유지 관리 비용이 증가합니다. 그러나 이러한 과도한 디자인은 일반적인 사용에서는 거의 영향을 미치지 않습니다. 디자이너가 중요하다고 생각하는 기능이거나 금상첨화지만 실제로는 거의 사용되지 않는 경우가 많습니다.
2 설계 시 확장성을 고려하세요
설계 시에는 용량의 20배를 고려하고, 구현 시에는 용량의 3배를 고려하고, 배포 시에는 용량의 1.5를 고려하여 설계해야 합니다. 프로젝트 확장시 임시 증설로 인한 어려움.
3 계획을 단순화하세요
파레토의 법칙을 따라야 합니다. 디자인의 20%가 작업의 80%를 수행하므로 80%의 시간은 이 20%에 디자인에 투자해야 합니다. .
실제로 제품의 주요 기능은 몇 가지 사항에 집중되어 있습니다. 이러한 사항이 디자인되면 나머지는 단지 추가 기능일 뿐입니다. 따라서 이 핵심 사업은 간단하고 사용하기 쉬워야 합니다.
4 DNS 쿼리 줄이기
다른 도메인의 각 파일은 로드 시 DNS에 쿼리해야 합니다. 예를 들어 cnblogs.com과 i.cnblogs.com은 서로 다른 도메인에 속합니다. 그러면 DNS를 쿼리할 때 두 번 쿼리됩니다. 사업 규모가 크면 일정한 영향을 미칩니다.
5 개체를 최대한 줄입니다.
브라우저가 개체에 액세스할 때 개체를 로드해야 하기 때문입니다. 따라서 요청된 파일 수(이 수는 동시 브라우저 로드 수와 관련됨)를 줄이고 일부 개체를 최대한 병합하는 것을 고려할 수 있습니다. 예를 들어 아이콘 파일을 하나의 큰 그림으로 병합할 수 있습니다. 적절한 수의 파일을 사용하면 브라우저 액세스 및 로딩 속도가 빨라집니다.
6 동일한 브랜드의 네트워크 장비를 사용하십시오
http 요청은 여러 물리적 장치를 통과할 수 있으므로. 로드 밸런서, 스위치, 라우터 등. 따라서 예상치 못한 상황을 피하기 위해 동일한 브랜드의 장비를 사용하도록 노력하십시오.
작업 분산
7 예를 들어 애플리케이션이 여러 서버에서 제공됩니다. 일반적인 것에는 클러스터링, 로드 밸런싱 등, 데이터베이스의 읽기 및 쓰기 분리가 포함됩니다.
8개의 Y축, 서로 다른 기능을 분할
대규모 시스템에서는 등록, 구매, 조회, 클라우드 디스크 등 다양한 기능을 분할합니다. 잠깐만요
9개의 Z축, 서로 다른 비슷한 것 나누기
예를 들어 사용자의 레벨에 따라 나누거나, 사용자의 지리적 위치 등에 따라 나누는 것입니다.
수평 확장 설계
10 수평 확장 계획을 설계합니다
확장에는 수평 확장과 수직 확장이 포함됩니다. 수평적으로는 애플리케이션을 복사 및 복제하고 미니컴퓨터 클러스터를 사용하여 확장합니다. 수직적인 측면은 서버 하드웨어와 네트워크 시설을 개선하는 것이다.
많은 사례를 통해 단순히 하드웨어 업그레이드를 통한 수직적 확장으로는 현실적 부담을 약간만 해결할 수 있음을 알 수 있습니다. 그러나 수평적 클러스터 확장을 통해 자유롭게 확장이 가능합니다.
11 경제적인 시스템을 사용하라
위의 원칙과 마찬가지로 고가의 서버를 사용한다고 해서 앞으로도 좋은 성능이 보장되는 것은 아니다. 일반 미니컴퓨터 클러스터 확장을 사용해야 합니다.
12개의 스케일아웃 데이터센터
핫 스테이션과 콜드 스테이션 구성: 핫 스테이션을 사용하여 서비스를 제공하는 경우 콜드 스테이션을 사용하여 서비스를 계속하는 등 데이터 센터를 위한 다양한 설계 솔루션이 있습니다.
저렴한 비용과 역동적인 통화를 위해 여러 개의 실시간 사이트를 이용하는 것을 권장합니다. 단점은 운영 및 유지 관리의 어려움이 증가한다는 것입니다.
13 클라우드 기술을 활용한 디자인
클라우드 컴퓨팅의 장점은 비즈니스 피크 시간에도 유연하게 장비를 확장할 수 있는 가상화입니다. 매일 처리하려면 확장명을 반환하세요.
단점은 가상환경에 적용되는 결합도가 높아진다는 점이다. 서비스를 격리하기 위해 물리적 장치를 사용하면 가상화된 클라우드 컴퓨팅에서 비즈니스 격리 오류를 해결하는 데 특정 간섭이 발생할 수 있다는 점은 나중에 언급됩니다.
올바른 도구 사용
14 데이터베이스를 올바르게 사용
기존 관계형 데이터베이스인 Oracle 및 MySQl과 최신 비관계형 데이터베이스 등 다양한 데이터베이스 버전이 있습니다. MongoDB, 인메모리 데이터베이스 FastDB, SSD 솔리드 스테이트 드라이브 전용 Aerospike 등의 NoSql 데이터베이스
하지만 선택에 있어서는 여전히 개인적인 비즈니스 요구에 따라 다릅니다. 데이터베이스에 속도, 보안 등이 필요한지 여부에 따라 다릅니다.
15 방화벽, 방화벽은 어디에나 있습니다
방화벽은 일부 잘못된 액세스를 차단하고 필터링할 수 있습니다. 일반적으로 일부 CSS, 정적 파일, 그림, JS 등은 방화벽에서 사용되지 않지만 개인 정보와 관련된 중요한 업무에 사용됩니다. 적절하게 설계된 방화벽은 웹사이트 성능에도 일정한 영향을 미칩니다.
16 로그 파일을 적극적으로 활용하세요
다양한 로그와 도구를 활용해 비즈니스를 실시간으로 모니터링하세요. 서버의 메모리, CPU 모니터링은 물론 비즈니스 데이터까지 모니터링합니다. 예를 들어 splunk(로그 수집, 저장, 검색 및 그래픽 표시 제공)가 있습니다.
반복적인 작업을 하지 마세요
17 방금 한 작업을 바로 확인하지 마세요
예를 들어 방금 데이터를 썼다면 바로 읽지 마세요 . 일부 고객은 데이터가 완전하고 손실되지 않도록 해야 합니다. 그러나 로그 등을 통해 기록될 수 있으므로, 작성한 후 확인하는 이 방법은 권장되지 않습니다.
18 리디렉션 중지
리디렉션은 일정량의 지연과 컴퓨팅 리소스를 소비합니다. 가능한 한 피해야 합니다
19 타이밍 제약 완화
대부분의 관계형 데이터베이스는 확장 시 특정 문제를 일으키는 ACID 속성에 주의를 기울입니다. 따라서 특정 비즈니스에 대한 타이밍 제약을 적절하게 완화하면 웹 사이트 성능을 향상시킬 수 있습니다.
예를 들어 특정 웹사이트에서 호텔을 예약하는 경우 사용자는 예약 후 호텔의 리뷰를 기다립니다. 예를 들어 특정 계좌에서 돈을 인출하는 경우 시간 범위가 확인됩니다. 이는 타이밍 제약을 확장하여 웹사이트 성능과 거래 보안을 향상시키는 것입니다.
캐싱 적극 활용
20 CDN 활용
CDN을 활용하면 고객의 데이터와 콘텐츠를 저장할 수 있습니다. 일반적인 프로세스는 사용자가 웹 사이트를 방문하면 CDN 서버로 이동하고 CDN은 DNS 쿼리를 수행하고 사용자의 요청을 다른 서버에 할당하는 것입니다. 이 서비스를 제공하는 CDN 서비스 제공업체가 많이 있습니다.
21 만료 헤더 사용
다양한 개체 유형에 만료 헤더를 사용하여 개체 요청을 줄입니다. 일반적인 HTTP 해당 속성은 public no-cahe max-age 등입니다.
22 Ajax 호출 캐싱
Http 헤더 마지막 수정 캐시 제어 만료 및 기타 속성을 올바르게 수정합니다.
23 페이지 캐싱을 사용하세요
이전 겨울 요청에 대한 응답을 캐시하여 웹 서버의 부하를 줄입니다.
24 애플리케이션 캐시 활용
예를 들어 일부 특수 사용자의 요청 데이터를 캐시합니다.
25 객체 캐시 활용
반복 쿼리에 사용되는 데이터 객체에 적합합니다. 예를 들어, 쇼핑 웹사이트는 인기 상품 데이터를 캐시합니다.
26 객체 캐시를 자체 레이어에 배치
확장 및 유지 관리가 용이하도록 별도의 캐시 레이어를 사용합니다.
실수로부터 배우기
27 능동적 학습
기업에서는 학습하는 분위기가 있어야만 더 좋은 제품을 생산할 수 있습니다. 학습 내용에는 한편으로는 고객의 비즈니스 지식이 포함되고, 다른 한편으로는 기술, 운영 및 유지 관리 분야에서 비롯됩니다.
28 오류를 찾기 위해 QA에 의존하지 마세요
테스터나 품질 보증 인력을 고용하는 가장 큰 목적은 제품의 정확성을 감지하는 것입니다. 개발자가 항상 코드의 정확성에 주의할 필요가 없고 테스트를 위해 QA에 맡길 수 있기 때문에 비용을 절감하고 개발자의 개발 속도를 높일 수 있습니다.
그러나 QA는 문제를 찾는 책임만 집니다. 문제를 피하는 방법은 여전히 개발자에게 달려 있습니다.
29 롤백 없는 디자인은 실패한 디자인
여기서 롤백은 제품 출시의 롤백을 의미합니다. 특정 버전에서 버그가 발생하면 이전에 실행 가능했던 버전을 제공해야 할 수도 있습니다. 현재 롤백이 없으면 제품을 제공할 수 없습니다.
여기서는 지속적인 통합에 대해 알아보는 것이 좋습니다.
30 실패에 대해 토론하고 교훈을 얻으세요
같은 문제에 두 번 실패하면 안 됩니다. 각각의 실패를 요약하는 것이 필수입니다.
데이터베이스 원칙
관계형 데이터베이스의 ACID 속성:
원자성: 트랜잭션이 완전히 실행되거나 전혀 실행되지 않음,
일관성: 트랜잭션 시작 및 종료, 모든 데이터의 상태가 일관되어야 합니다.
격리: 트랜잭션의 성능은 데이터베이스에서 트랜잭션의 유일한 작업입니다.
내구성: 트랜잭션이 완료됩니다. 그리고 작업은 변경할 수 없습니다.
31 비용이 많이 드는 관계에 주의하세요
개발이 시작되면 특정 열을 추가하는 데 비용이 많이 들 수 있으므로 설계 단계에서 설계 테이블의 구조를 개선해야 합니다.
32 올바른 데이터베이스 잠금 사용
데이터베이스에는 암시적 잠금, 명시적 잠금, 행 잠금, 페이지 잠금, 범위 잠금, 테이블 잠금, 데이터베이스 잠금 등 많은 잠금 개념이 있습니다. 등. .
잠금 장치를 부당하게 사용하면 웹사이트 처리량에 영향을 미칠 수 있습니다.
33 다단계 제출을 사용하지 마세요
예를 들어 2단계 제출: 먼저 투표한 후 제출하세요. 커밋 트랜잭션이 완료될 때까지 다른 작업을 수행할 수 없으므로 확장성이 감소합니다.
34 업데이트에 선택을 사용하지 마세요
왜냐하면 FOR UPDATE 절로 인해 행이 잠기고 트랜잭션 처리 속도가 느려지기 때문입니다.
35 모든 데이터를 선택하지 마세요
예를 들어 xxx에서 *를 선택하면 비즈니스 처리 코드가 직접 작성됩니다. 데이터 열을 추가하면 오류가 발생하며 불필요한 데이터도 쿼리됩니다.
또는 xxx 값(xxxx)에 삽입;
컬럼 정보가 일치하지 않는 경우에도 오류가 발생합니다.
내결함성 설계 및 결함 제어
36 "수영 레인"을 사용하여 결함 격리
서비스와 데이터를 분할하는 방법에는 컨테이너, 클러스터, 풀과 샤드. 수영 레인은 각 업체가 자체 도메인을 갖고 있으며 수영 레인을 건너 호출할 수 없음을 의미합니다.
37 단일 장애 지점을 믿지 마세요
전체 시스템이 이 모듈만 사용할 경우 단일 장애 지점이 발생하면 전체 시스템이 단일 지점 모드로 설계되는 경우가 많습니다. 시스템이 붕괴됩니다.
38 시스템 캐스케이드 방지
예를 들어 시스템은 여러 구성 요소로 구성되며 각 구성 요소는 99.9%의 보안을 갖습니다. 3개의 구성 요소를 직렬로 연결하면 전체 시스템의 가용성이 99.7이 됩니다. %.
39 기능 활성화/비활성화 가능
일부 공유 라이브러리 및 타사 서비스의 경우 해당 기능을 활성화 또는 비활성화해야 합니다.
상태를 피하거나 분산시키세요
40 무국적을 달성하기 위해 노력하세요
상태를 구현하면 확장성이 제한되고 비용이 증가합니다
41 브라우저 측에서 해보세요 가능하다면 세션 유지
한편으로는 서버 부담을 줄이고 다른 한편으로는 모든 요청을 모든 서버로 보낼 수 있습니다.
42 분산 캐시를 사용하여 상태 저장
확장을 용이하게 하기 위해 독립적인 캐시 레이어를 사용합니다. memcached와 같은 분산 캐싱 솔루션이 많이 있습니다.
비동기 통신 및 메시지 버스
43 비동기식 통신을 최대한 활용하세요
비동기식 통신은 각 서비스와 레이어 간의 독립성을 보장할 수 있어 시스템의 확장성을 높이고 결합도를 줄이기가 더 쉽습니다.
44 메시지 버스를 확장할 수 있는지 확인하세요
Y축 또는 Z축 확장을 사용해 보세요. 즉, 비즈니스 요구와 기능에 따라 확장하세요. 단순 복사 또는 복제로 인해 각 메시지 구독자의 청취자 수가 증가하기 때문입니다. 비즈니스 격리에 따라 비즈니스 압력을 분리할 수 있습니다.
45 메시지 버스 과밀화 방지
메시지 비용 대비 가치를 평가하세요.
기타 원칙
46 타사 솔루션 확장 사용 시 주의
기업에 문제가 있는 경우 타사를 찾으세요. 긴급한 문제를 해결할 수 있습니다. 그러나 솔루션 제공업체는 고객이 많고, 귀하의 위기는 그들의 위기가 아니기 때문에 중요한 순간에 직무를 수행하는 것이 불가능하기 때문에 장기적인 솔루션이 아닙니다. 그러므로 기업은 여전히 어느 정도의 통제권을 가지고 있어야 합니다(이 단어는 정말 큰 의미를 갖습니다!).
47 삭제, 보관 및 비용 효율적인 저장
불필요한 데이터가 있으면 정기적으로 삭제해야 합니다. 약간의 가치가 있는 일부 데이터는 정기적으로 보관된 후 직접 삭제됩니다. 일부 중요한 데이터는 신속하게 백업하고 액세스해야 합니다.
48 트랜잭션 처리 시 비즈니스 인텔리전스 삭제
제품의 확장성을 높이기 위해서는 제품 시스템과 비즈니스 시스템을 분리해야 합니다.
사업 확장 시 시스템 아키텍처의 제약을 받지 마세요.
49 모니터링 가능한 애플리케이션 설계
답변을 보장할 수 있는 글로벌 모니터링 전략을 설계해야 합니다
"문제가 발생했나요?"
"어디에 그런 일이 있었나요? "
" 무슨 일이 일어났나요? "
" 자동으로 해결되나요? 🎜>
50 능숙해지려면
최고의 아키텍처는 모든 설계에 포함되어야 하며 타사 솔루션에 전적으로 의존할 수는 없습니다.
단순하고 우수한 아키텍처는 작고 세련된 아키텍처입니다. 아키텍처를 해결하기 위해 오픈 소스에만 의존한다면 문제는 해결되지만 애플리케이션이 비대해지게 됩니다.