배경 전염병 발생 초기 에 모 지역 정 부 는 이 도시 시민 들 을 대상 으로 무료 마스크 를 배포 하기 로 결정 했다. 이 도시 시민 들 은 모두 무료 로 예약 하여 수령 할 수 있 고 예약 시간 은 오전 9 시 - 12 시 이기 때문에 이 장면 은 시간 제한 구 매 유형 장면 으로 매우 큰 시간 초과 유량 과 큰 병행 문제 에 직면 하 게 될 것 이다. 이 프로젝트 의 착지 과정 에서 관련 된 구조 변 화 를 기록 하고 생각 했다. 구성 도 & 분석 - V1 원시 구조 도시 & 분석 (2 월 2 일 저녁 22 시 쯤 의 원시 구조) 2 월 2 일 저녁 22 시 쯤 의 원시 구조
클 라 이언 트 가 HTTPS 프로 토 콜 을 통 해 ECS 에 직접 접근 합 니 다.
ECS 에 Nginx 감청 HTTPS 443 포트 사용 하기;
Nginx 는 Tomcat, Nginx 는 정적 파일 을 처리 하고 Tomcat 는 동적 요청 을 처리 합 니 다.
프로그램 은 먼저 Redis 에 가서 캐 시 를 찾 고 명중 하지 않 으 면 데이터 베 이 스 를 조회 하 는 동시에 Redis 와 Mysql 간 의 데 이 터 는 프로그램 에 의 해 동기 화 됩 니 다.
이렇게 구조 설계:
장점: 관리 하기 쉽 고 배치 하기 쉽다.
단점: 성능 이 떨 어 지고 확장 성 이 없 으 며 단일 위험 이 존재 한다.결과: 이 앱 이 출시 되 자마자 바로 끊 겼 고 알 수 없 는 이유 로 예약 페이지 가 유출 되 어 예약 시간 이 되 지 않 아 서비스 가 끊 겼 다 는 사실 이 입증 되 었 다.구조 도 & 분석 - V2
그 후에 우리 측 이 개입 하여 구조 조정 을 했 습 니 다. 24 시 쯤 에 우 리 를 찾 았 습 니 다. 아침 9 시 에 서버 를 열 어야 합 니 다. 시간 이 너무 촉박 하고 임무 가 너무 무 겁 습 니 다. 절차 가 움 직 이지 못 하 는 상황 에서 몇 십 만 의 병발 구 조 는 어떻게 합 니까?2 월 3 일 아침 9 시 쯤 의 구조, 4 일 에 도 이 구 조 를 회복 했다) 2 월 3 일 아침 9 시 쯤 의 구조
SLB 에 접속 하여 미 러 를 통 해 부하 능력 을 수평 으로 확장 합 니 다.
읽 기와 쓰기 분리 데이터베이스 구조 에 접속 하여 아 리 클 라 우 드 데이터 베 이 스 를 통 해 자동 으로 읽 기와 쓰기 분 리 를 하고 자동 으로 데 이 터 를 동기 화 합 니 다.
Nginx 프로 토 콜 조정;
같은 구조 로 클 러 스 터 를 사용 합 니 다 (도 메 인 이름 분석 은 두 개의 A 기록 을 만 들 었 습 니 다).
방문 로 그 를 분석 한 결과 실패 원인 은 문자 메시지 수령 과 로그 인 초기 화 쿠키 지점 에 있 었 습 니 다.
이렇게 구조 설계:
장점: 높 은 가용성 을 증가 하고 부하 능력 을 확대 했다.
단점: 데이터 에 대한 예측 이 부족 하고 정적 페이지 도 ECS 에 있 기 때문에 SLB 의 대역 폭 은 한때 최대 치 인 5. X G 에 달 했 고 병발 은 22w + 에 달 했다.결과: 데이터 가 너무 많아 사용자 가 한때 페이지 를 열지 못 했 고 도 메 인 네 임 서비스 업 체 XX 의 제한 으로 고객 이 스스로 분석 을 추가 할 수 없 었 으 며 그날 밤 도 메 인 네 임 서비스 업 체 고객 센터 에 연락 하지 못 해 CDN 방안 이 좌초 되 었 다.
구성 도 & 분석 - V3 2 월 5 일의 구조
CDN 분류 초대 대역 폭 접속;
Nginx 의 대 리 를 취소 합 니 다.
새로운 프로그램 이 제시간에 출시 되 지 못 하 는 재해 준비 전환 방안 을 만 들 었 다.
가상 서버 그룹 을 사용 하여 새로운 오래된 프로그램의 전환 을 하지만 7 층 감청 SLB 백 엔 드 에 200 개의 기계 만 걸 수 있 고 아무리 SLB 가 많아 도 견 딜 수 없어 서 오래된 프로그램 이 처음 연결 되 었 을 때 다시 끊 는 것 이 단점 이다.
5 번 은 이 구 조 를 사용 하여 출시 되 었 습 니 다. 7 분 동안 재고 가 매진 되 었 고 극도 의 절 차 를 체험 하 며 실 처럼 매 끄 럽 고 건강 한 친구 들 이 개발 한 새로운 프로그램 은 정말 시원 합 니 다.
이렇게 구조 설계:
장점: CDN 이 정적 자원 을 부담 하 는 유량 은 SLB 의 대역 폭 을 낮 추고 압력 측정 효과 도 매우 이상 적 이다.
단점: 페이지 에 독립 된 도 메 인 이름 이 하나 더 있어 야 합 니 다. 크로스 도 메 인 과 관련 되 고 4 번 서버 를 열 때 테스트 에서 입고 & 예약 문자 코드 가 되 돌아 오 는 것 을 발 견 했 습 니 다. 긴급 하 게 오래된 프로그램, 즉 2 세대 구조 로 전환 되 었 습 니 다.
이상 구조 도 & 분석 - V4 이상 구조
메 인 도 메 인 이름 이 CDN 에 접속 합 니 다.
CDN 은 리 소스 Http, Https 프로 토 콜 을 설정 하여 SLB 의 서로 다른 감청 을 방문 하여 신 구 프로그램 간 전환 을 실현 하고 구체 적 으로 리 소스 프로 토 콜 대응 을 실현 한다.서로 다른 감청, 감청 은 서로 다른 절차 에 대응한다.
이렇게 구조 설계:
장점: 정적 가속 은 SLB 대역 폭 을 낮 추고 동적 회 원, 크로스 도 메 인 문제 가 없 으 며 전환 이 편리 하 다.
단점: 아직도 수공 으로 설정 해 야 합 니 다. 미 러 배치 ecs 가 불편 합 니 다. 시간 이 충분 하면 용기 에 직접 올 라 갈 수 있 는 구조 가 얼마나 아름 다 울 까요? 하나의 scale 은 몇 십 수백 개의 pod 를 확대 할 수 있 고 노드 자동 으로 확대 할 수 있 습 니 다.
총결산 시간 이 촉박 하고 임무 가 무 거 워 N 여 개의 구 덩이 를 만 났 습 니 다.
vcpu 구 매 한도;
SLB 백 엔 드 마 운 트 한도;
고객 잔액 부족 요금 정지;
도 메 인 네 임 서비스 업 체 는 고객 센터 에 연락 해 야 추가 할 수 있다 고 분석 했다.
CDN 구 조 를 처음 고려 할 때 크로스 도 메 인 문 제 를 고려 하지 않 았 다.
새로운 프로그램 개발 기간 에 메 인 라 이브 러 리 테스트 에 연결 되 지 않 아 온라인 실패 (메 인 라 이브 러 리 어 지 러 움) 를 초래 합 니 다.
처음 (3 번) 걸 렸 을 때 역장 거래 SLB 의 데이터 에 만 관심 을 가지 고 가장 많이 실패 한 부분 을 상세 하 게 분석 하지 않 았 다.
온라인 전 압력 측정 이 부족 하고 인공 테스트 기능 에 만 의존한다.
압력 측정 은 사람 손 으로 Jmeter 한 대 (4 일 저녁 부터 5 일 아침 까지 PTS 를 도입 하여 압력 측정 을 한다).
갑자기 고객 의 원시 프로그램 이 윈도 에 놓 여 있 는 것 이 생각 났 다. 윈도 + 썩 은 프로그램의 성능 이 정말 나쁘다.
이 '작은 프로젝트' 는 전후 에 10 만 원 이 들 었 다. 처음부터 우리 에 게 해 주면 원 가 를 절반 으로 줄 일 수 있 을 것 이다.마지막 성과 통계 (샘플링 분석, 실제 데 이 터 는 이것 보다 더 크다): 성과 통계 (샘플링 분석) 마지막 에 출시 된 3 세대 구 조 는 안전 을 위해 150 대의 기 계 를 만 들 었 으 나 활동 기간 의 관찰 과 테스트 결과 에 대한 평가 에 따라 50 대의 기 계 는 견 딜 수 있 을 것 이다. 5 시간 동안 계속 붕괴 되 어 단말 사용자 에 게 욕 을 먹 었 다.7 분 만 에 재고 가 매진 됐다 는 리더 의 찬 사 는 3 개의 밤샘 도륙 전 을 겪 었 음 에 도 몸 과 마음 이 승화 했다 는 것 을 어렴풋이 느 낄 수 있 었 다.
각종 최적화 노트 매개 변수 최적화
네트워크 인삼
`net.ipv4.tcp_max_tw_buckets = 5000` _--> 50000_
`net.ipv4.tcp_max_syn_backlog = 1024` _--> 4096_
`net.core.somaxconn = 128` _--> 4096_
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1(5
6
nat
)
`net.ipv4.tcp_tw_recycle = 1`
/etc/security/limits.conf
soft nofile 65535
hard nofile 65535
nginx 매개 변수 최적화
`worker_connections 1024`_-->10240;_
`worker_processes 1`_-->16;__（ ， __auto__）_
`worker_rlimit_nofile 1024`_-->102400;_
`listen 80 backlog 511`_-->65533__；_
일부 장면 도 nginx 가 긴 연결 을 열 어 짧 은 링크 가 가 져 온 비용 을 최적화 하 는 것 을 고려 할 수 있다. 구조 최적화
SLB 백 엔 드 ECS 수량 을 확대 하고 ECS 설정 이 통일 되 었 습 니 다.
Nginx 백 엔 드 upstream 무효 포트 제거;
클 라 우 드 조수 의 대량 처리 서비스, 파라미터 최적화, 인 스 턴 스 표 지 를 추가 합 니 다.(중점 을 두 고 ECS 를 대량으로 사용 하면 클 라 우 드 조수 라 는 제품 을 고려 할 수 있 습 니 다)
클 라 우 드 모니터링 디스크 모니터링, ECS, SLB, DCDN, Redis 등;
SLB 를 7 층 감청 모드 로 조정 하고 7 후 4 세 션 을 닫 고 유지 하면 로그 인 상태 가 실 효 됩 니 다.
프로그램 최적화 GC log 를 추가 하고 GC 분석 문 제 를 포착 하여 프로 세 스 메모 리 를 설정 합 니 다.
문자 발송 논 리 를 최적화 하고 로그 인 할 때 먼저 Redis 등록 면제 세 션 을 조회 하 며 세 션 에 등록 하지 않 고 문자 인증 코드 (문자 의 양 을 낮 추고 로그 인 체험 을 최적화) 를 보 낼 수 있다.
jedis 연결 탱크 최적화;
maxTotal 8 --> 20
`acceptcount`` （ ``somaxconn``）`
bug: springboot 1.5 밴드 의 jedis 2.9.1 의 Redis 연결 이 누 출 된 문제 로 인해 Tomcat 800 프로 세 스 가 가득 찬 후에 Redis 연결 을 무한 기다 리 게 되 었 습 니 다.나중에 진일보 한 조사 연 구 를 통 해 이 문 제 는 2.10.2 에서 복원 되 었 고 2.10.2 에서 뒤로 2.9.1 을 호 환 한 것 을 발견 했다.
데이터베이스 최적화
Redis 공공 네트워크 주 소 를 내부 네트워크 주소 로 변경 합 니 다.
Redis 세 션 시간 초과 설정 단축, Redis 연결 해제 에 사용;
느 린 SQL 최적화 (RDS 의 CloudDBA 가 매우 좋 음);
읽 기 전용 인 스 턴 스 를 추가 하고 자동 읽 기 및 쓰기 분리;
backlog 최적화;
읽 기와 쓰기 분리 실례 수량 을 추가 합 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
