뉴스APP 백엔드 시스템 아키텍처 성장의 길 - 고가용성 아키텍처 설계에 대한 상세한 그래픽 및 텍스트 설명

전재시 출처를 밝혀주세요 : News APP 백엔드 시스템 아키텍처 성장경로 - 고가용성 아키텍처 설계

1. 처음으로 성지에 입장하다

2. 기초 건물: 완전 재건축

3. 황금 비약: 함정을 밟으세요. . 그리고 그것은 큰 함정입니다

4. Yuanying: 어려움에 직면하고 교통 정체가 다가오고 있습니다

5. Out of Body: 서버 아키텍처 조정 및 최적화

6. 고난의 극복: 서비스 거버넌스 플랫폼

7. Mahayana: 서버의 고가용성

8. 급증: 클라이언트의 고가용성-[2017 HTTPS+HTTP-DNS]

---

1. 처음으로 성지에 입장하다

---

업무 협의로 인해 원래 APP 백엔드의 일부 선배들이 다른 비즈니스 부서로 이동하여 2015년 말부터 클라이언트 백엔드 작업을 맡기 시작했습니다. 처음으로 성지에 들어가는 것은 연옥에 들어가는 것과 같았습니다.

당시에는 친구들의 지속적인 지원이 필요한 비즈니스 개발 작업이 아직 많이 남아 있었기 때문에 혼자서 APP 백엔드 개발에 뛰어들 수밖에 없었습니다.

예전에 편했던 콘텐츠 비즈니스 개발부터 APP 백엔드 인터페이스 개발까지, 아직 APP에 대한 전문적인 지식이 많지 않아 결국에는 친구들에게 상담하고 배울 수 밖에 없습니다. 동시에 도움을 준 반 친구들에게 마지막으로 감사 인사를 전하고 싶습니다. 다양한 어려움에 직면했음에도 불구하고 사업은 계속해서 전진할 것이며, 버전 반복도 계속 진행 중입니다.

이렇게 12명이 넘는 아름다운 제품 소녀들의 다양한 요구를 처리하면서 매일 코딩하고 버그를 수정하고 있었습니다.

기존 API는 2012년 초에 개발되었습니다. 2015년 말까지 거의 4년 동안 4개 그룹이 처리했습니다. 한밤중에 일어나는 일이 얼마나 많았는지 짐작할 수 있습니다. 온라인 버그를 수정합니다.

동시에 기존 API의 성능 문제는 낙관적이지 않았고 인터페이스 응답 시간은 그 당시에는 여전히 사업 규모가 작았으며 원래 개발자는 서비스 아키텍처 및 최적화에 특별한 관심을 기울이지 않았습니다. 사용자 수가 급격하게 증가함에 따라 PUSH가 출시되면 서비스가 중단될 예정이므로 이를 시행할 수밖에 없습니다. 이런 식으로 강렬한 버전 반복을 지원하면서, 함정에 발을 들여놓고 채우면서, 물론 조용히 구멍을 파는 동안, 이것은 한 달 이상 지속되었습니다.

이전 API 코드 전체를 완전히 이해한 후 4년 내에 수십 가지 버전의 APP가 출시되었다는 사실을 발견했습니다. 마스터와 선배가 작성한 원래의 우수한 코드는 4년 동안 여러 사람들이 인식할 수 없을 정도로 변경되었습니다. API 코드는 모든 버전 코드와 호환되며, 단일 파일에 10개가 넘는 IF ELSE가 있어 더 이상 확장할 수 없습니다. 한 번의 움직임이 전체에 영향을 미칠 수 있으며, 코드 몇 줄만 조정하면 모든 버전의 전체 서비스가 중단될 수 있다고 합니다. 그러나 시간이 길어질수록 비즈니스 코드는 더욱 혼란스러워지고 그때쯤에는 더욱 수동적인 상태에 직면하게 됩니다.

2. 기초 구축: 인터페이스 재구성

---

바꾸지 않으면 오래가지 못할 것 같아요! 우리는 마음을 정하고 완전히 재구성할 수만 있습니다!

그러나 비즈니스 개발과 버전 반복은 멈출 수 없습니다. 이전 API 개발을 계속 지원하기 위해 원래 콘텐츠 비즈니스 개발에서 두 명의 동급생만 전송할 수 있습니다. 동시에 새로운 인터페이스 아키텍처의 설계를 조사하기 시작했습니다.

APP 개발 경험이 부족하고 기술이 부족하여 인터페이스 재구성에 공백이 생기기 시작했고, 2주 연속으로 밤을 새워가며 여러 프레임워크를 작성하면서 낮 동안 친구들과 토론을 하다가 다양한 문제점을 발견하게 되었습니다. 하나씩 뒤집어 엎었습니다.

다양한 정보를 찾아보고, 주요 인터넷 어플의 경험을 익히며, 유명 선생님들을 동시에 방문할 수밖에 없었습니다. [Thanks to: @青哥, @雪大夫, @京京, @强哥 @tai哥그리고 APP 및 WAP 측면의 친구들. 지침], 많은 학습을 통해 새로운 인터페이스 아키텍처 구축 아이디어 전체에 대한 전반적인 계획을 천천히 생각해 냈고, 빛을 본 것 같습니다.

일주일 동안 밤낮으로 일한 후 처음에는 전체 프레임 구조를 완성했습니다. 쉬지 않고 일하고 있으니 친구들을 일로 이끌어 봅시다!

전체적인 디자인에 대한 대략적인 아이디어는 있지만 인터페이스 재구성에도 큰 문제가 있으며 이를 진행하려면 APP, 제품, 통계학 전공 학생들의 전폭적인 지원이 필요합니다.

새로운 인터페이스는 호출 방식과 데이터 출력 구조 측면에서 기존 인터페이스와 완전히 달라서 APP 코드에 많은 수정이 필요합니다. [지원과 협력을 해주신 @Huihui @박명님께 감사드립니다]

물론 통계도 같은 문제에 직면해 있습니다. 모든 인터페이스가 변경되었습니다. 즉, 원래의 통계 규칙을 모두 수정해야 합니다. 동시에 [@婵女@statistics 부서 @product classmates]에게도 감사의 말씀을 전하고 싶습니다. 그들의 강력한 협력을 위해. 양쪽 끝, 제품, 통계의 지원 없이는 인터페이스 재구성 작업의 진행이 불가능할 것입니다. 동시에 재구성 작업이 예정대로 진행될 수 있도록 모든 지도자들의 강력한 지원에 감사드립니다.

새로운 인터페이스는 주로 다음과 같은 측면에서 설계되었습니다.

1. 보안.

1>, 인터페이스 요청에 서명 확인을 추가하고, 인터페이스 암호화 요청 메커니즘을 설정하고, 각 요청 주소에 대한 고유 ID를 생성하고, 서버와 클라이언트에서 양방향 암호화를 사용하여 악의적인 인터페이스 브러싱을 효과적으로 방지합니다.

2>, 모든 비즈니스 항목에 대한 등록 시스템, 통합 보안 관리

2, 확장성

높은 응집력과 낮은 결합력, 강제 버전 분리, APP 버전의 평면 개발, 코드 재사용성을 향상시키는 동시에 작은 버전은 상속 시스템을 따릅니다.

3. 자원관리

서비스 등록 시스템, 통합된 입구 및 출구, 모든 인터페이스는 지속 가능한 개발을 보장하기 위해 시스템에 등록되어야 합니다. 후속 모니터링 및 일정 다운그레이드를 보장합니다.

4. 통합 캐시 스케줄링 및 할당 시스템

3. 황금 비약: 함정을 밟으세요. . . . 그리고 그것은 큰 함정입니다

---

5.0 버전 출시와 함께 예정대로 새로운 인터페이스가 출시됐다. 모든 게 괜찮을 줄 알았는데, 그 앞에 큰 구덩이가 조용히 나를 기다리고 있을 줄 누가 알았겠는가.

앱에는 PUSH 기능이 있습니다. PUSH가 발행될 때마다 많은 수의 사용자가 즉시 앱을 방문하게 됩니다.

새 인터페이스가 PUSH를 보낼 때마다 서버가 중단되는데 이는 비극적입니다.

오류 발현:

1. php-fpm이 차단되었으며, 서버 전반적인 상태는 정상입니다.

2. nginx는 다운되지 않았고 서비스는 정상입니다.

3. php-fpm을 다시 시작하세요. 잠시 동안 서비스가 정상으로 작동하지만 몇 초 후에 다시 종료됩니다.

4. 인터페이스가 느리게 반응하거나 시간 초과되고 콘텐츠 없이 앱이 새로 고쳐집니다.

추측 문제 해결

처음에는 다음 질문을 의심했습니다.

1. MC에 문제가 있다

2. MYSQL이 느리다

3. 요청량이 많다

4. 일부 요청은 프록시의 오래된 인터페이스이므로 요청이 두 배로 늘어납니다.

5. 네트워크 문제

6. 일부 종속 인터페이스는 속도가 느려 서비스를 저하시킵니다.

그러나 로그 기록이 부족해 근거를 찾을 수 없었다.

문제 추적:

서버 압력이 순간적으로 올라갑니다. push.PHP-FPM은 짧은 시간 내에 차단되고 중단됩니다.

PHP는 순차적으로 실행됩니다. 하나의 백엔드 인터페이스가 느리면 동시성이 높은 상황에서는 대기열이 발생하고 처리량이 늘어납니다. PHP가 완전히 죽을 때까지 급락합니다.

1. 푸시 시 다수의 앱 사용자가 동시에 클라이언트를 열면 그 수가 평소보다 3~5배 늘어납니다(그림 참조). 중첩됩니다))

2. 클라이언트가 PUSH를 열면 콜드 스타트이며, 사용자 유치를 위해 많은 인터페이스 리소스가 호출되며, 새로운 API 출시 초기에는 APP 측에서 학생들과 충분한 의사소통이 이루어지지 않아 캐시할 수 없는 많은 실시간 관심사, 광고 등을 포함하여 엄청난 수의 인터페이스에 대한 즉각적인 요청이 발생하고 많은 수의 백엔드 인터페이스 줄무늬가 발생했습니다. 그리고 MYSQL 및 기타 리소스로 인해 많은 대기 시간이 발생합니다.

3. 인터페이스 요청 백엔드 리소스의 시간 제한이 너무 길게 설정되어 있고 느린 인터페이스 요청이 제때 해제되지 않아 대기열에 대기 중인 인터페이스 요청이 많습니다

4. 사용자 규모는 늘어나고 있으며, APP 사용자 규모는 연초와 동일합니다. 수를 두 배로 늘린 것에 비해 코드 재구성에 중점을 두었지만 서버 리소스를 방치하고 신규 사용자 수가 없습니다. 이 실패의 원인이기도 한 기계입니다. [참고: 하드웨어 투자는 사실 최저가 투자입니다.]

그러다가 죽었습니다. . .

해결된 문제:

1. NGINX 레이어 캐시를 최적화합니다(텍스트 등). NGINX 레이어에서 CACHE를 수행하여 백엔드 부담을 줄입니다.

2. [통계 등]] 처리를 통해 NGINX는 PHP를 사용하지 않고 직접 반환하므로 PHP-FPM에 대한 부담이 줄어듭니다

3. 요청한 백엔드 인터페이스 리소스를 비즈니스 중요도에 따라 우선순위를 지정하고 엄격하게 제어합니다. 시간 초과.

4. 새로운 장비를 추가하고 사용자 규모에 따라 서버 리소스를 다시 계산 및 구성합니다

5. 리소스 호출 로그를 기록하고 종속 리소스를 모니터링합니다. 리소스에 문제가 발생하면 공급자를 찾아 제때 해결하세요

6. MC 캐시 구조를 조정하여 캐시 활용도를 높입니다

7. 효과적인 인터페이스 활용도를 높이기 위해 클라이언트와 완벽하게 소통하여 APP의 인터페이스 요청 순서와 빈도를 신중하게 분류합니다.

이러한 일련의 개선 조치를 통해 효과는 여전히 뚜렷합니다. 기존 API와 비교하여 새 API의 성능 이점은 다음과 같습니다. :

이전: 100ms 미만의 요청이 55%

이전 API 응답 시간을 차지합니다.

새로운 기능: 93% 이상의 응답 시간이 100ms 미만

새 API 응답 시간

문제 요약:

주요 원인은 다음과 같습니다. 1. 응답 부족, 2. 반복적인 의사소통 부족, 3. 견고성 부족, 4. PUSH 특성

1>, 대응이 부족합니다

연초부터 그 때까지 사용자 수가 두 배 이상 늘었지만 충분한 관심을 끌지 못하고 인터페이스 재구성 진행이 여전히 느려서 최적화와 고민을 위한 충분한 시간이 부족하여 직접 전투에 들어갔습니다. 서버 장비 자원을 적시에 추가하지 않아 큰 문제가 발생했습니다.

2>, 소통부족

나는 APP 측의 반 친구들과 운영 및 유지 관리 부서와 충분한 의사 소통을 유지하지 않았고 내 발에서 일어나는 일에만 관심을 가졌습니다. 터미널과 운영 및 유지보수 학생들과 충분한 의사소통과 통합을 유지해야 합니다. 기존 리소스 조건[하드웨어, 소프트웨어, 종속 리소스 등]에 따라 다양한 리소스 요청의 시기와 빈도를 세부적으로 합의하고, 메인 애플리케이션이 아닌 인터페이스 요청은 적절하게 지연하여 메인 비즈니스가 가능하고 서비스 자원을 최대한 활용하십시오.

참고: 개발 중에 급우들과 원활한 의사소통을 유지하는 것이 특히 중요합니다. 너무 많은 인터페이스를 요청하면 자신의 APP에서 많은 수의 앱을 실행하는 것과 같습니다. 자신의 서버에 대한 Ddos 공격은 매우 심각합니다. .

3> 견고성 부족

신뢰할 수 있는 타사 인터페이스에 대한 과도한 의존, 종속 인터페이스에 대한 불합리한 시간 제한 설정, 캐시 활용도 부족, 재해 백업 없음, 종속 리소스 문제 등은 사망으로 이어질 수 있습니다.

참고: 불신의 원칙, 종속 리소스를 신뢰하지 마십시오. 종속 인터페이스가 언제든지 끊길 수 있도록 준비하고, 재해 복구 조치를 취하고, 엄격한 시간 제한을 설정하고, 필요한 경우 포기하십시오. . 훌륭한 서비스 저하 전략을 세우세요. [참고: 1. 업무 다운그레이드, 캐시 추가로 업데이트 빈도 줄이기, 2. 본업 확보, 불필요한 업무 제거, 3. 사용자 다운그레이드, 일부 사용자 포기, 우량 사용자 보호]. 로그 기록 로그는 시스템의 눈입니다. 로그를 기록하는 것이 시스템 성능의 일부를 소모하더라도 로그는 반드시 기록되어야 합니다. 시스템에 문제가 발생하면 이를 통해 문제를 빠르게 찾아 해결할 수 있습니다. 로그.

4>, 갑작스러운 트래픽 증가

PUSH 및 제3자는 막대한 양의 트래픽을 즉각적으로 가져오는데, 이는 시스템이 견딜 수 없으며 효과적인 회로 차단기, 전류 제한 및 다운그레이드 자체 보호 조치가 부족합니다.

요약: 저도 이 질문을 통해 많은 것을 배웠고 전반적인 시스템 아키텍처에 대해 더 깊은 이해를 얻었습니다. 동시에 저는 어떤 일들은 당연하게 여겨지지 않고, 어떤 일을 하기 전에 충분히 준비해야 한다는 사실도 배웠습니다. 리팩토링은 단지 코드를 다시 작성하는 것이 아닙니다. 전체 업스트림 및 다운스트림 시스템 리소스에 대한 완전한 이해와 지식이 필요하며, 완벽한 준비가 필요합니다.

4. 초기 영혼: 도전에 직면하기

기대하고 기대하고 교통도 막히고 올림픽도 다가오고 있어요!

BOSS 타오 형제가 말했습니다: 올림픽이 잘못되지 않으면 학생들에게 큰 식사를 대접하겠습니다! 올림픽에서 무슨 일이 생기면 타오 형제에게 잔치를 베풀어 주세요! 그러니 잔치에는 아무런 문제가 없을 것입니다!

우리는 올림픽을 앞두고 준비 상태에 있었고 올림픽 트래픽 피크에서 완벽하게 살아남을 수 있도록 많은 최적화 작업을 수행했습니다.

1. 모든 종속 리소스를 주의 깊게 분류하고 주요 비즈니스 인터페이스를 주의 깊게 모니터링했습니다.

2. APP측에 로그 보고 모듈을 배포하여 이상 로그를 실시간으로 보고하여 모니터링합니다

3. MC 클러스터를 업그레이드 및 확장하고 시스템 캐시를 균일하게 최적화 및 관리합니다

4. 다단계 업무용 서킷브레이커 발동 및 다운그레이드 전략

그러나 올림픽이 실제로 다가오고 있으며 시스템은 여전히 ​​큰 테스트에 직면해 있습니다. 올림픽이 시작될 때 시스템의 모든 지표가 문제 없이 정상적으로 작동하는지 확인하기 위해 우리는 엔지니어를 회사에 배치했습니다. 24시간 올림픽 첫 금메달을 획득한 PUSH는 기대에 부응하여 즉각적인 성공을 거두었습니다. 평소보다 5배가 넘는 트래픽으로 인해 다양한 리소스가 부족하여 서버가 최대 용량으로 작동하기 시작했습니다. 이 순간 우리의 이전 준비가 시작되었습니다. 근무 중인 엔지니어는 항상 대형 모니터링 화면에 주의를 기울이고 모니터링 데이터 및 서버 로드 상태에 따라 언제든지 시스템 매개변수를 조정하는 동시에 다양한 데이터를 워밍업했습니다. 첫 올림픽 금메달을 성공적으로 통과했습니다! 첫 번째 금메달 이후 올림픽 기간 동안 다른 금메달 종목으로 인해 발생한 트래픽이 첫 번째 금메달에 비해 그리 크지 않은 것을 관찰하면서 순진하게도 올림픽 트래픽 피크 전체를 무사히 통과했다고 생각했습니다. [첫 번째 금 이상 모니터링 사진은 다음과 같습니다]

그러나 [하나님은 선을 위하여 일하신다. . ]아기 사건이 갑자기 닥쳐 올림픽과 겹쳐진다! 베이비 사건 첫날 PUSH가 가져온 트래픽은 첫 번째 골드의 최고 트래픽을 훨씬 초과했습니다. 많은 Bagua 사용자의 강력한 지원으로 우리 시스템은 마침내 우리 인생에서 가장 큰 테스트를 겪었습니다. , APP 접속이 PUSH에서 즉시 응답하기 시작했습니다. 느린 경우 실시간 모니터링 시간 표시 오류율도 증가하기 시작합니다.

베이비 이벤트 PUSH와 올림픽 중첩 교통

과부하로부터 시스템을 보호하기 위해 즉시 비상 계획을 가동했으며, 전체 시스템 가용성이 영향을 받지 않도록 중요도에 따라 서비스를 다운그레이드[일반적으로 업데이트 빈도 감소, 캐시 시간 연장, 비활성화 등]했습니다. 시스템은 트래픽 피크를 원활하게 통과할 수 있습니다. 다운그레이드를 수동으로 활성화한 후 시스템은 대량의 리소스를 빠르게 해제하기 시작하고 시스템 부하가 꾸준히 감소하기 시작하며 사용자 측 응답 시간이 정상 수준으로 돌아갑니다. PUSH가 경과한 후[최대 피크는 일반적으로 약 3분 동안 지속] 수동으로 다운그레이드를 취소합니다.

올림픽 기간 중 갑작스럽게 아기 사건이 발생했지만, 원활하게 잘 처리해 서비스 전반에 문제가 없었으며, 이번 두 사건으로 인해 APP의 전반적인 비즈니스 데이터도 크게 개선되었습니다.

BOSS도 학생들을 초대하여 잔치를 벌이며 행복한 시간을 보냈습니다!

요약: 1. 모니터링 시스템을 더욱 세부화해야 하며 리소스 모니터링을 추가해야 합니다. 사후 분석을 통해 확인된 문제 중 일부는 트래픽으로 인한 것이 아니라 트래픽에 대한 의존성 때문일 수 있다는 사실이 밝혀졌기 때문입니다. 리소스 문제로 인해 시스템 정체가 발생하고 영향이 증폭됩니다. 2. 예측할 수 없는 긴급 상황이 발생하여 24시간 근무가 불가능하도록 경보 시스템을 개선합니다. 3. 자동 다운그레이드 메커니즘 서비스 관리 시스템이 구축을 기다리고 있습니다. 갑작스런 트래픽이나 종속 리소스에 갑작스러운 이상이 발생하면 자동으로 무인그레이드됩니다.

5. Out of Body : 업무 최적화 및 서버 아키텍처 조정

빠르게 발전하는 비즈니스는 또한 우리 시스템의 다양한 지표에 대해 더 높은 요구 사항을 적용했습니다. 첫 번째는 서버 측 응답 시간입니다.

APP의 두 가지 핵심 기능 모듈인 피드 스트림과 텍스트의 응답 속도는 전반적인 사용자 경험에 큰 영향을 미칩니다. 경영진의 요구 사항에 따라 우선 평균 응답 시간이 설정됩니다. 피드 스트림의 전체 응답 시간은 100ms입니다. 이는 약 500-700ms로 갈 길이 멀습니다!

피드 스트리밍 사업은 복잡하며 실시간 광고, 개인화, 댓글, 이미지 전송, 초점 이미지, 고정 위치 전달 등 많은 데이터 리소스에 의존합니다. 실시간 계산 데이터의 경우 일부 리소스를 캐시할 수 없습니다. 캐싱에만 의존할 수는 없습니다. 다른 방법을 찾아 다른 수단을 통해서만 해결할 수 있습니다.

먼저 운영 및 유지보수팀과 협력하여 서버 소프트웨어 시스템 환경 전체를 업그레이드하고 Nginx를 Tengine으로 업그레이드한 후 PHP를 업그레이드하여 업그레이드 효과가 뚜렷이 나타났으며 전체 응답 시간이 약 20% 단축되었습니다. 300~400ms로 성능이 향상됐지만 아직 목표에는 한참 못 미치는 수준이다. 최적화가 진행되면서 피드의 비즈니스 링크 전체에 대한 로그 분석을 진행하여 가장 많은 퍼포먼스를 소모하는 영역을 찾아 하나씩 물리쳐 나가고 있습니다.

원래 서버 구조는 다음과 같습니다.

이는 로드 밸런싱 계층, 프록시 계층 및 웹 계층으로 구분됩니다. 클라이언트 액세스는 먼저 Nginx 프록시 계층 프록시를 통해 Nginx+PHP-FPM 웹 시스템으로 전달됩니다. 레이어와 웹 머신이 동일한 장치에 있지 않거나 심지어 다른 장소에 있는 경우에도 동일한 컴퓨터실에서는 심각한 성능 손실이 발생할 수 있습니다. 많은 로그 분석을 통해 예상대로 프록시 레이어의 Nginx 로그 기록은 웹 레이어 로그 기록의 응답 시간보다 수십, 심지어 수백 밀리초 더 길고, 원래 캐시 레이어에는 단일 오류가 있습니다. 문제가 발견되면 서버 구조를 조정했습니다. 다음과 같이 원래 캐시 계층을 오프라인화하고 이를 웹 프런트 엔드 시스템으로 이동하여 단일 지점 병목 현상을 줄이고 전체 서비스 가용성에 영향을 미치는 단일 지점 장애 위험을 제거합니다.

서버 구조 조정이 완료된 후 피드 응답 시간도 크게 단축되었으며 성능도 크게 향상되어 약 200~350ms에 이르렀습니다. 설정된 목표에 가까워졌지만 여전히 설정된 목표를 달성하지 못하고 있습니다.

어느 날 우리 엔지니어들은 코드를 디버깅하는 동안 실수로 PHP-CURL에 설정된 밀리초 시간 제한이 유효하지 않다는 것을 발견했습니다. 우리는 PHP와 함께 제공되는 기본 CURL 라이브러리가 밀리초를 지원하지 않는다는 것을 수많은 테스트를 통해 확인했습니다. 공식 PHP 문서에서 우리는 이전 버전의 PHP libcurl 라이브러리에 이 문제가 있음을 발견했습니다. [나중에 회사의 대부분의 비즈니스 PHP 버전 환경에 이 문제가 있음이 발견되었습니다.] 시스템이 적용되지 않아 시스템 성능이 지연되었습니다. 이 문제를 해결하면 운영 및 유지 관리를 통해 온라인 그레이스케일 검증 테스트를 즉시 시작할 수 있습니다. 며칠간의 온라인 테스트 후에도 다른 문제는 발견되지 않았고 성능도 많이 향상되었으므로 모든 서버가 온라인 상태가 될 때까지 점차 범위를 확장했습니다. 데이터에 따르면 libcurl 버전 라이브러리가 업그레이드된 후 서버 피드가 다른 최적화 없이 응답 시간이 100-100에 직접 도달했습니다. 약 150ms로 매우 분명합니다.

서버 구조 계층과 소프트웨어 시스템 환경 계층은 가능한 모든 작업을 수행했지만 아직 평균 피드 응답 시간에 대해 설정된 요구 사항인 100ms에 도달하지 못했습니다. 당시에는 비즈니스 코드로만 시작할 수 있습니다. 흐름 요청은 순차적으로 실행된 리소스에 의존합니다. 리소스가 정체되면 후속 요청이 대기열에 추가되어 전체 응답 시간이 늘어납니다. 우리는 PHP CURL을 다중 스레드 동시 요청으로 변경하고, 직렬을 병렬로 변경하고, 여러 종속 리소스 인터페이스를 기다리지 않고 동시에 요청하기 시작했습니다. CURL 클래스 라이브러리를 다시 작성하여 To를 제공했습니다. 문제를 피하기 위해 우리는 오랫동안 수많은 그레이스케일 테스트를 수행하고 이를 검증했으며, 테스트를 통과하여 온라인 생산 환경에 출시하는 동시에 서버 피드 스트림 응답 시간도 보상받았습니다. 동시에 인터페이스의 평균 응답 시간은 15ms 이내로 제어됩니다.

피드 흐름 응답 시간

텍스트 평균 응답 시간

그 후, 각 컴퓨터실에 서버를 분산 배치하고, VIP 네트워크 액세스 노드를 재배포하고, 네트워크 통화 리소스를 최적화하고, 운영자 간, 남북 간 액세스로 인해 발생할 수 있는 사용자 경험에 대한 부정적인 영향을 방지했습니다.

위의 수많은 최적화 조정을 통해 전체 시스템의 운반 능력도 크게 향상되었습니다.

현재 최고 QPS는 134,000에 달하고, 일일 최고 HIT 요청 수는 약 8억 건에 달합니다. 볼륨 수준은 이미 매우 인상적입니다.

단일 기계의 QPS 운반 능력도 크게 향상되었습니다. 단일 기계를 갖춘 원래의 500-800QPS 시스템은 완전히 로드되었지만 이제 단일 기계를 갖춘 2.5K 시스템은 여전히 ​​견고하고 움직이지 않습니다.

팀원들의 지속적인 노력과 큰 도움을 준 운영 및 유지 보수 학생들 덕분에 뉴스 APP 인터페이스 시스템의 성능과 부하 저항이 크게 향상되었습니다.

6. 고난의 극복: 서비스 관리 플랫폼

전략을 통해서만 우리는 수천 마일을 얻을 수 있습니다.

뉴스 앱 인터페이스는 현재 수백 개의 타사 인터페이스 및 리소스에 의존하고 있습니다. 하나 이상의 인터페이스 및 리소스에 문제가 발생하면 시스템 가용성에 영향을 미치기 쉽습니다.

이러한 상황을 토대로 본 시스템을 설계하고 개발한 주요 시스템 모듈은 다음과 같습니다.

서비스 자체 보호, 서비스 저하, 오류 분석 및 콜 체인 모니터링, 모니터링 및 경보. 자원 수명 감지 시스템, 인터페이스 액세스 스케줄링 스위치를 사용하는 자체 구축 오프라인 데이터 센터, 오프라인 데이터 센터는 실시간으로 주요 비즈니스 데이터를 수집하고 수명 감지 시스템은 실시간으로 자원 상태 및 가용성을 감지하고 인터페이스 액세스 스케줄링 스위치를 사용합니다. 수명 감지가 완료되면 인터페이스 요청을 제어합니다. 시스템이 리소스 문제를 감지하면 인터페이스 액세스 제어 스위치를 통해 자동으로 다운그레이드하고 액세스 빈도를 줄이며, 수명 감지 시스템이 지속적으로 감지하여 데이터 캐시 시간을 자동으로 연장합니다. 리소스를 완전히 사용할 수 없게 되면 제어 스위치는 인터페이스를 완전히 닫아 자동 서비스 저하에 대한 액세스를 요청하고 로컬 데이터 센터가 사용자에게 데이터를 제공할 수 있도록 합니다. 수명 프로브가 리소스를 사용할 수 있음을 감지한 후 통화를 재개합니다. 이 시스템은 여러 번에 걸쳐 리소스(예: CMS, 댓글 시스템, 광고 등)에 대한 과도한 의존을 성공적으로 피했습니다. 오류 If 뉴스 클라이언트 서비스의 가용성에 미치는 영향. 종속 리소스에 오류가 발생하면 비즈니스 응답은 다음과 같습니다. 클라이언트는 기본적으로 이를 인식하지 못합니다. 동시에 우리는 가능한 한 빨리 문제를 예측, 발견 및 해결할 수 있도록 완전한 예외 모니터링, 오류 분석 및 호출 체인 모니터링 시스템을 구축했습니다[자세한 내용은 7장 서버 고가용성 참조].

동시에 클라이언트 비즈니스는 지속적으로 빠르게 발전하고 있으며, 심각한 코드 문제 없이 빠른 반복을 충족하기 위해 각 기능 모듈을 빠르게 업데이트하고 반복하기 위해 코드 그레이스케일 및 릴리스 프로세스도 늘렸습니다. 새 기능이 시작되면 먼저 그레이스케일 검증을 거치게 되며, 동시에 새 기능에 문제가 있는 경우 새 스위칭 모듈이 예약됩니다. , 정상적인 서비스를 보장하기 위해 언제든지 이전 버전으로 전환할 수 있습니다.

서비스 거버넌스 플랫폼 기술 구현

서비스 거버넌스 플랫폼이 구축된 후의 시스템 서비스 아키텍처는 대략 다음과 같습니다.

7. Mahayana: 서버의 고가용성

고가용성은 현재 높은 동시성 및 트래픽이 많은 WEB 서비스 시스템에서 가장 우려되는 문제 중 하나입니다. 고가용성 설계는 네트워크, 서버 하드웨어, 웹 서비스, 캐시, 데이터베이스, 업스트림 리소스에 대한 의존성, 로그, 모니터링, 경보, 자체 보호, 재해 복구, 신속한 처리 및 복구 등 다양한 측면을 포함하는 체계적인 프로젝트입니다. .

고가용성의 정의:

시스템 가용성(Availability)의 정의 공식은 다음과 같습니다. 가용성 = MTBF / ( MTBF + MTTR ) × 100%

평균 고장 간격인 MTBF(Mean Time Between Failure)는 전체 시스템의 신뢰성을 나타내는 지표입니다. 대규모 웹 시스템의 경우 MTBF는 전체 시스템 서비스가 중단이나 장애 없이 지속적으로 실행되는 평균 시간을 나타냅니다.

평균 시스템 복구 시간인 MTTR(Mean Time to Repair)은 전체 시스템의 내결함성 능력을 나타내는 지표이다.

대규모 웹 시스템의 경우 MTTR은 시스템의 구성 요소에 오류가 발생했을 때 시스템이 오류 상태에서 정상 상태로 복구하는 데 걸리는 평균 시간을 나타냅니다.

MTBF를 높이거나 MTTR을 줄이면 시스템 가용성이 향상된다는 공식을 통해 알 수 있습니다.

따라서 문제는 이 두 지표를 통해 시스템 가용성을 어떻게 향상시킬 수 있는가 하는 것입니다.

위의 정의에서 고가용성의 중요한 요소인 MTBF는 시스템 안정성[평균 오류 간격]임을 알 수 있습니다.

그런 다음 MTBF에 영향을 미칠 수 있는 문제를 나열해 보겠습니다. 1. 서버 하드웨어, 2. 네트워크, 3. 데이터베이스, 4. 캐시, 5. 종속 리소스, 6. 코드 오류, 7. 갑작스러운 대규모 트래픽 높은 동시성 이러한 문제가 해결되면 고장을 방지하고 MTBF를 개선할 수 있습니다.

이러한 질문을 바탕으로 뉴스 클라이언트는 현재 어떻게 하고 있나요?

첫 번째 서버 하드웨어 장애: 서버 하드웨어 장애로 인해 해당 서버에서 서비스를 사용할 수 없는 경우 현재 시스템은 다음과 같습니다. MEMs가 부착되어 있습니다. 서버에는 LVS+HA라는 수명 감지 시스템이 있습니다. 이상이 감지되면 적시에 로드 밸런싱에서 제거하여 사용자가 문제가 있는 서버에 액세스하여 장애가 발생하는 것을 방지합니다.

두 번째 내부 네트워크 문제: 대규모 내부 네트워크 장애가 발생하면 종속 리소스 읽기 실패, 데이터베이스 액세스 실패, 캐시 클러스터 등을 읽고 쓰지 못하면 영향 범위가 상대적으로 크고 결과도 심각합니다. 그러면 이번에는 더 많은 글을 작성하겠습니다. 일반적으로 네트워크 문제는 주로 컴퓨터실 간 접속이 차단되거나 차단될 때 발생합니다. 같은 전산실에 있는 네트워크가 끊어지는 경우는 극히 드뭅니다. 일부 종속 인터페이스는 서로 다른 컴퓨터실에 분산되어 있기 때문에 컴퓨터실 간 네트워크 문제는 주로 종속 인터페이스의 느린 응답 또는 시간 초과에 영향을 미칩니다. 인터페이스가 비정상일 경우 실시간 지역화된 캐시를 먼저 가져옵니다. 지역화된 캐시 침투의 경우 즉시 로컬 컴퓨터실에 있는 캐시 클러스터의 실시간 캐시에 액세스합니다. 로컬 컴퓨터실의 영구 방어 캐시에 액세스합니다. 매우 가혹한 조건에서 영구 캐시에 적중이 없으면 백업 데이터 소스가 사용자에게 반환됩니다. 동시에 예열된 백업 데이터 소스는 캐시됩니다. 사용자가 이를 인지하지 못하고 대규모 장애를 피할 수 있도록 지속적으로 유지합니다. 네트워크 문제로 인한 데이터베이스 지연 문제를 해결하기 위해 우리는 주로 비동기식 대기열 쓰기를 사용하여 저장소를 늘려 데이터베이스 쓰기가 정체되어 시스템 안정성에 영향을 미치는 것을 방지합니다.

6번째 코드 오류 : 과거에도 코딩 오류로 인해 피비린내 나는 온라인 장애가 발생한 사례가 있었고, 대부분의 문제가 낮은 수준의 오류로 인해 발생했기 때문에 저희도 이 분야에 많은 노력을 기울이고 있습니다.

우선, 코드 개발 및 릴리스 프로세스를 표준화해야 합니다. 비즈니스가 성장함에 따라 시스템 안정성과 신뢰성에 대한 요구 사항도 날로 증가하고 있습니다. 화전 농업과 혼자 일하는 원시 사회 상태. 모든 작업에는 표준화와 프로세스 지향이 필요합니다.

개발 환경, 테스트 환경, 시뮬레이션 환경, 온라인 환경 및 온라인 프로세스를 개선했습니다. 엔지니어는 개발 환경에서 자체 테스트를 마친 후 테스트 환경에 대해 언급하고 테스트 부서에서는 테스트를 통과한 후 시뮬레이션 환경으로 가서 테스트를 통과한 후 이를 언급합니다. 온라인 시스템은 관리자의 승인을 받아야 사용할 수 있으며, 온라인 회귀가 완료된 후 온라인 회귀 검증이 수행되면 코드 온라인 검증이 종료됩니다. 실패하면 한 번의 클릭으로 온라인 시스템을 사전 출시 환경으로 롤백할 수 있습니다.

코드 개발 및 출시 과정

그럼 7조 : 갑작스러운 대규모 트래픽과 높은 동시성을 어떻게 처리합니까?

일반적으로 갑작스러운 대규모 트래픽은 시스템 소프트웨어 및 하드웨어의 예상 부하 범위를 훨씬 초과하는 짧은 시간 내에 많은 수의 액세스 요청이 발생하는 핫스팟 및 긴급 상황으로 정의됩니다. 이를 처리하지 않을 경우 전체 서비스에 영향을 미칠 수 있습니다. 이 상황은 짧은 시간 동안 지속됩니다. 새 온라인 머신을 임시로 추가하기에는 너무 늦다면 머신이 온라인 상태가 되고 트래픽 피크가 지나간 후에는 의미가 없습니다. 언제든지 많은 수의 백업 머신이 온라인으로 준비되어 있으면 해당 머신은 99%의 시간 동안 유휴 상태가 되어 많은 재정적, 물적 자원을 낭비하게 됩니다.

이러한 상황에서는 완전한 트래픽 스케줄링 시스템과 서비스 회로 차단기 및 전류 제한 조치가 필요합니다. 갑작스럽게 대규모 트래픽이 특정 지역에서 발생하거나 하나 이상의 IDC 전산실에 집중되는 경우, 부하가 높은 전산실에서 유휴 트래픽이 있는 전산실로 트래픽의 일부를 나누어 함께 부담을 공유할 수 있습니다. 그러나 트래픽 분할만으로는 문제를 해결할 수 없거나 모든 전산실의 트래픽 부하가 상대적으로 높은 경우에는 회로 차단기와 전류 제한을 통해서만 전체 시스템 서비스를 보호할 수 있습니다. 우선 순위에 따라 정렬합니다. 비즈니스 다운그레이드 후에도 문제가 해결되지 않으면 중요한 기능 모듈을 유지하고 외부 서비스를 계속 제공하기 위해 우선순위가 낮은 서비스를 하나씩 비활성화하기 시작합니다. . 극단적인 경우, 비즈니스 다운그레이드가 트래픽 피크를 견딜 수 없는 경우 현재 제한적인 보호 조치를 취하여 대부분의 고가치 사용자의 가용성을 유지합니다.

고가용성의 또 다른 중요한 지표는 MTTR 시스템 평균 복구 시간, 즉 장애 후 서비스가 복구되는 데 걸리는 시간입니다.

이 문제를 해결하기 위한 주요 포인트는 다음과 같습니다. 1. 결함 찾기, 2. 결함 원인 찾기, 3. 결함 해결

이 세 가지 점은 똑같이 중요합니다. 첫째, 문제가 발생하더라도 실제로는 끔찍하지 않습니다. 문제는 오랫동안 문제를 발견하지 못했다는 것입니다. 사용자 손실이 가장 심각합니다. 그렇다면 제때에 결함을 감지하는 방법은 무엇입니까?

모니터링 시스템은 전체 시스템은 물론 전체 제품 수명주기에서도 가장 중요한 링크입니다. 적시에 경고를 제공하여 사전에 결함을 감지하고, 이후에 문제 추적 및 찾아내기 위한 세부 데이터를 제공합니다.

우선, 우리는 완전한 모니터링 메커니즘을 갖추어야 합니다. 모니터링은 우리의 눈이지만, 모니터링만으로는 적시에 경보를 발령하고 적시에 문제를 처리하도록 관련 담당자에게 알려야 합니다. 이에 대해 운영 및 유지관리 부서의 지원을 받아 지원 모니터링 및 경보 시스템을 구축했습니다.

일반적으로 완전한 모니터링 시스템은 주로 1. 시스템 리소스, 2. 서버, 3. 서비스 상태, 4. 애플리케이션 예외, 5. 애플리케이션 성능, 6. 예외 추적 시스템

의 다섯 가지 측면을 갖습니다. 1. 시스템 리소스 모니터링

다양한 네트워크 매개변수 및 서버 관련 리소스(CPU, 메모리, 디스크, 네트워크, 액세스 요청 등)를 모니터링하여 서버 시스템의 안전한 작동을 보장하고 시스템 관리자가 다양한 문제를 신속하게 찾아 해결할 수 있도록 예외 알림 메커니즘을 제공합니다. 기존 문제.

2. 서버 모니터링

서버 모니터링은 주로 각 서버, 네트워크 노드, 게이트웨이 및 기타 네트워크 장비의 요청 응답이 정상적인지 여부를 모니터링하는 것입니다. 예약된 서비스를 통해 각 네트워크 노드 장치에 정기적으로 ping을 보내 각 네트워크 장치의 정상 여부를 확인합니다. 네트워크 장치에 이상이 있는 경우 메시지 알림이 발행됩니다.

3. 서비스 모니터링

서비스 모니터링은 다양한 웹 서비스 및 기타 플랫폼 시스템의 서비스가 정상적으로 실행되고 있는지를 의미합니다. 예약된 서비스를 이용하여 정기적으로 관련 서비스를 요청하여 플랫폼의 서비스가 정상적으로 실행되고 있는지 확인할 수 있습니다.

4. 애플리케이션 예외 모니터링

주로 비정상적인 시간 초과 로그, 데이터 형식 오류 등이 포함됩니다.

5. 애플리케이션 성능 모니터링

본업의 응답시간 지표가 정상인지 모니터링하고, 본업의 성과곡선 추이를 표시하며, 발생할 수 있는 문제점을 적시에 발견 및 예측합니다.

6. 예외 추적 시스템

예외 추적 시스템은 주로 전체 시스템이 업스트림과 다운스트림에 의존하는 리소스를 모니터링하여 응답 시간 변화, 타임아웃 비율 변화 등 종속 리소스의 상태를 모니터링하여 조기 판단 및 대처가 가능합니다. 전체 시스템에서 발생할 수 있는 위험. 또한 발생한 오류를 신속하게 찾아 종속성 리소스 문제로 인해 발생했는지 확인하여 신속하게 오류를 해결할 수 있습니다.

현재 우리가 온라인에서 사용하고 있는 주요 모니터링 시스템은 다음과 같습니다.

뉴스APP 백엔드 시스템 아키텍처 성장의 길 - 고가용성 아키텍처 설계에 대한 상세한 그래픽 및 텍스트 설명

종속 리소스 시간 초과 모니터링

종속 리소스 평균 응답 시간 모니터링

API 오류 모니터링

참고: [인용, 연구] 모니터링 시스템의 품질을 판단하는 데는 두 가지 주요 사항이 있습니다. 1. 꼼꼼함, 2. 한눈에 명확함. 이 둘은 서로 충돌하는 것처럼 보이지만, 세부적으로 모니터링 프로젝트가 너무 많아서 한눈에 명확하지 않을 수 있지만 그렇지 않습니다. 한 눈에 명확하다는 것은 주로 시간 내에 문제를 발견하는 것입니다. 수백 개의 모니터링 차트를 항상 응시하는 데 그렇게 많은 시간과 에너지를 가질 수 없기 때문입니다. 그러면 다양한 지표의 정상 여부를 요약하고, 비정상 지표를 나열하여 문제를 한눈에 식별할 수 있는 완전한 대시보드가 ​​필요합니다. 꼼꼼하다는 것은 주로 문제가 발생한 후 문제 해결을 준비하는 것입니다. 다양한 모니터링 데이터 포인트가 정상인지 확인하여 문제를 빠르게 찾을 수 있습니다.

8. 비상: 클라이언트를 위한 고가용성

[2017년 중요한 목표, 클라이언트를 위한 고가용성]

최근 인터넷 매체에 HTTPS에 대한 기사가 많이 나오고 있는데, 그 이유 중 하나는 운영자의 사악한 행위의 수익성이 점점 낮아지고 있으며 며칠 전 여러 인터넷 회사에서 차례대로 광고가 삽입된다는 것입니다. 교통 납치 등 불법 행위에 저항하기 위한 공동 성명을 공동으로 발표하고 일부 운영자를 비난했습니다. 한편, Apple의 ATS 정책에서도 강력하게 추진되어 모든 앱에서 모든 사람이 HTTPS 통신을 사용하도록 강제하고 있습니다. HTTPS를 사용하면 사용자 데이터를 유출로부터 보호하고 중개인의 데이터 변조를 방지하며 기업 정보를 인증하는 등 많은 이점이 있습니다.

HTTPS 기술이 사용되지만 일부 사악한 운영자는 HTTPS를 차단하고 DNS 오염 기술을 사용하여 도메인 이름이 자체 서버를 가리키도록 하여 DNS 하이재킹을 수행합니다.

이 문제가 해결되지 않으면 HTTPS로도 문제를 근본적으로 해결할 수 없으며, 여전히 많은 사용자가 접속 문제를 겪게 됩니다. 최소한 제품에 대한 불신으로 이어질 수도 있지만, 최악의 경우 사용자가 제품을 사용하지 못하게 되는 직접적인 원인이 되어 사용자 손실로 이어질 수도 있습니다.

그렇다면 제3자 데이터에 따르면 구창과 같은 인터넷 기업의 도메인 이름 확인 이상 현상은 얼마나 심각한가요? 매일 Gouchang의 분산 도메인 이름 확인 모니터링 시스템은 전국의 모든 주요 LocalDNS를 지속적으로 감지합니다. 전국의 Gouchang 도메인 이름에 대한 일일 확인 예외 수가 800,000개를 초과했습니다. 이로 인해 사업에 막대한 손실이 발생했습니다.

운영자는 광고비를 벌고 네트워크 간 정산을 절약하기 위해 무엇이든 할 것입니다. 그들이 사용하는 일반적인 하이재킹 방법은 ISP를 통해 가짜 DNS 도메인 이름을 제공하는 것입니다.

"사실 우리도 똑같은 심각한 문제에 직면해 있다"

뉴스 앱의 로그 모니터링 및 분석을 통해 사용자의 1~2%가 DNS 확인 이상 및 인터페이스 액세스 문제를 겪고 있는 것으로 나타났습니다.

DNS 이상 및 인터페이스 접속 불가

특히 급속한 비즈니스 발전 기간 동안 눈에 보이지 않게 많은 사용자 손실을 초래하여 비즈니스 경험에 큰 피해를 입혔습니다.

그럼 도메인 이름 확인 이상, 사용자 액세스 네트워크 간 문제, DNS 하이재킹의 근본 원인을 해결할 수 있는 기술 솔루션이 있을까요?

업계에서는 이러한 상황을 해결하기 위한 솔루션, 즉 HTTP DNS가 있습니다.

HttpDNS란 무엇인가요?

HttpDNS는 Http 프로토콜을 기반으로 DNS 서버에 도메인 이름 확인 요청을 보내며, DNS 프로토콜을 기반으로 운영자의 LocalDNS에 확인 요청을 시작하는 기존 방법을 대체하여 도메인 이름 하이재킹 및 네트워크 간 액세스 문제를 방지할 수 있습니다. LocalDNS, 모바일 인터넷 서비스의 비정상적인 도메인 이름 확인 문제를 해결합니다.

HttpDNS는 어떤 문제를 해결하나요?

HttpDNS는 주로 세 가지 유형의 문제를 해결합니다. 모바일 인터넷의 DNS 확인 이상 및 LocalDNS 도메인 이름 하이재킹, 평균 응답 시간 증가, 사용자 연결 실패율 유지 높음

1. DNS 확인 예외 및 LocalDNS 하이재킹:

• 모바일 DNS의 현재 상황: 사업자의 LocalDNS 내보내기는 권한 있는 DNS 대상 IP 주소를 기반으로 NAT를 수행하거나, 해결 요청을 다른 DNS 서버로 전달하여 권한 있는 DNS가 사업자의 LocalDNS IP를 올바르게 식별할 수 없게 되어 도메인 이름이 해결 오류 및 네트워크를 통과하는 트래픽.

• 도메인 이름 하이재킹의 결과: 웹 사이트 접속 불가(서버에 연결할 수 없음), 팝업 광고, 피싱 웹 사이트 접속 등

• 도메인 간, 지역 간, 운영자 간, 국가 간 구문 분석 결과의 결과: 웹 사이트 액세스가 느리거나 액세스할 수 없는 경우도 있습니다.

• 
  

HttpDNS는 IP를 통해 서버 A 레코드 주소를 얻기 위해 http로 직접 요청하므로 도메인 확인 과정을 로컬 운영자에게 요청할 필요가 없으므로 하이재킹 문제가 근본적으로 방지됩니다.

2. 평균 접속 응답 시간이 늘어납니다. IP 직접 접속은 도메인 확인 과정을 절약하므로 지능형 알고리즘을 통해 정렬한 후 가장 빠른 노드를 찾아 접속합니다.

3. 사용자 연결 실패율 감소: 알고리즘을 통해 과거에 실패율이 높았던 서버의 순위를 낮추고, 최근 접속한 데이터를 통해 서버 순위를 높이고, 이력 접속 성공을 통해 서버를 개선합니다. 기록. ip(a)에 대한 접속 오류가 발생하면 다음 번에는 ip(b) 또는 ip(c)의 정렬된 레코드가 반환됩니다. (LocalDNS는 ttl(또는 여러 ttl) 내에

레코드를 반환할 가능성이 높습니다. HTTPS는 콘텐츠 보안이 변조되는 것을 포함하여 운영자가 트래픽을 하이재킹하는 것을 최대한 방지할 수 있습니다.

HTTP-DNS는 클라이언트 DNS 문제를 해결하여 사용자 요청이 가장 빠른 응답으로 서버로 직접 전달되도록 할 수 있습니다.

HttpDNS 구현의 원리는?

HTTP DNS의 원리는 매우 간단합니다. 쉽게 탈취되는 프로토콜인 DNS를 HTTP 프로토콜 요청을 사용하도록 변환합니다

도메인IP 매핑. 올바른 IP를 획득한 후 클라이언트는 ISP가 데이터를 변조하는 것을 방지하기 위해 HTTP 프로토콜 자체를 조립합니다.

• 클라이언트는 도메인 이름의 최적 IP를 얻기 위해 HTTPDNS 인터페이스에 직접 액세스합니다. (재해 복구 고려 사항에 따라 사업자의 LocalDNS를 사용하여 도메인 이름을 확인하는 방법은 대안으로 예약되어 있습니다.)

• 
  

• 클라이언트는 비즈니스 IP를 획득한 후 이 IP로 직접 비즈니스 프로토콜 요청을 보냅니다. HTTP 요청을 예로 들면, 헤더에 호스트 필드를 지정하여 HTTPDNS에서 반환된 IP로 표준 HTTP 요청을 보낼 수 있습니다.

• 
  

클라이언트 측에서 고가용성을 달성하려면 먼저 이 문제를 해결해야 합니다. 우리는 APP 개발 학생과 운영 및 유지 관리 학생과 함께 준비를 시작했으며, APP 클라이언트의 고가용성을 달성하고 비즈니스의 빠른 발전을 위한 안정적인 보장을 제공하기 위해 가능한 한 빨리 HTTPDNS를 출시하려고 노력하고 있습니다!

1년 간의 노력 끝에 전체 APP 백엔드 시스템은 기본적으로 야만 시대에서 현재의 완벽한 상태로 바뀌었습니다. 저도 약간의 탐구를 통해 많은 지식을 배웠고 또한 성취했다고 생각합니다. 큰 성장을 이루었지만 동시에 우리는 많은 문제에 직면해 있습니다. 비즈니스의 급속한 발전으로 인해 백엔드 서비스에 대한 요구 사항이 점점 더 높아지고 있으며 앞으로도 해결해야 할 문제가 여전히 많습니다. 또한 우리는 더 높은 기준을 갖고 수억 명의 사용자 규모에 대비할 것입니다.

                                                                                         >                                                   www.php.cn)!