Linux 고성능 네트워크 프로그래밍에 관한 10가지 토론

"리눅스 고성능 네트워크 프로그래밍에 관한 10가지 이야기"의 기술 블로그가 몇 달 동안 작성되었습니다. 지난 몇 년간의 작업을 검토하기 위해 요약을 작성해야겠다고 생각했습니다. 거의 8 나사 작업에 많은 시간을 소비했지만 참여, 최적화, 아키텍처 최종 설계에 이르기까지 고성능 아키텍처의 진화 경험을 통해 여전히 많은 것을 배웠습니다.

1. 사전 디자인인가, 아니면 비즈니스 진화인가?

누구나 0에서 1까지의 프로젝트 과정을 경험했을 것입니다. 질문하고 싶습니다. 많은 경우 아키텍처는 비즈니스와 함께 발전합니까, 아니면 미리 설계됩니까?

건축 관련 서적을 공부한 분들도 계시겠지만, 대부분의 책들은 건축이 비즈니스 발전과 함께 진화한다고 믿습니다. 하지만 건축은 미리 설계해야 한다고 주장하는 건축가도 많다. 여기서는 당분간 결론을 내리지 않고, 내 경험을 통해 건축의 진화를 탐구해 볼 것이다.

2. PHP에서 C++로

2.1 간단한 PHP 아키텍처

PHP는 간단하고 편리한 언어로서 대규모 공장의 모든 부서에 있어야 합니다. 당시 저는 작업에 C++와 PHP라는 두 가지 언어를 사용하여 기능을 개발하는 것이 매우 빨랐습니다. 성숙한 라이브러리가 많기 때문에 Classic nginx

+php-fpm+memcache 아키텍처를 형성했습니다.

php 아키텍처

현재 아키텍처에서는 단일 8c8g 머신이 1000qps를 지원하는 것은 큰 문제가 아니므로 비즈니스에서는 현재 1wqps 미만입니다. 물론 몇 대의 머신이 더 지원할 수 있습니다. 캐시 레이어의 디자인을 보면, redis가 아직 제대로 개발되지 않았을 때 당시에는 memcache가 주류 캐시 구성 요소였으며 비즈니스 및 PHP와의 도킹이 간단했습니다. 하지만 사업이 발전함에 따라 당시 계산 곡선에 따르면 1년 안에 5wqps에 도달할 수도 있습니다. nginx + php-fpm + memcache 아키텍처를 사용하는 것이 합리적일까요? 논의 결과 목표는 서버에서의 고성능입니다. 그래서 우리는 고성능 발견의 여정을 시작했습니다.

2.2 다중 프로세스 프레임워크

당시 사람들은 고성능 서버사이드 프레임워크를 구현하기 위해 몇 가지 해결책을 시도했습니다. 그 중 하나는 PHP 플러그인 기능을 사용하여 서버의 기능을 스크립트 언어에 통합하는 것이었습니다. 이 접근 방식은 어느 정도 고성능이라는 목표를 달성합니다. 예를 들어, PHP의 swoole은 이제 이 방법의 개발 결과입니다.

php-서버

그러나 여기에서 해결해야 할 몇 가지 문제가 있습니다:

함정을 피하기 위해 PHP 확장의 사용 시나리오를 숙지하세요

• PHP 자체 사용시 메모리 누수 문제
• 문제 발생 시 문제 해결 비용 예를 들어 문제가 발생하면 PHP 소스 코드를 이해해야 할 때도 있지만 수십만 줄의 코드로 인해 이 비용이 상당히 높습니다.
• PHP는 사용이 간편합니다. Docker가 등장하면 PHP 생태계가 이를 지원할 수 있을까요?
…
• 비즈니스 개발에 대한 위의 생각과 분석을 바탕으로 실제로 서버를 직접 구현하거나 기존 C++ 프레임워크를 사용하여 비즈니스 계층 서버 세트를 구현하는 것이 더 합리적입니다. 따라서 우리는 고려한 끝에 회사의 SPP 프레임워크를 채택했습니다. . 아키텍처는 다음과 같습니다:

SPP 프레임워크 아키텍처

SPP는 다중 프로세스 아키텍처임을 알 수 있습니다. 해당 아키텍처는 Nginx와 유사하며 프록시 프로세스와 작업자 프로세스로 구분됩니다.

프록시 프로세스는 handler_init를 사용하여 초기화를 수행하고, handler_route는 실행을 위해 지정된 작업자 처리 프로세스로 전달되며, handler_input은 요청의 패킷 항목을 처리합니다

작업자 프로세스는 handler_init를 사용하여 초기화를 수행하고, handler_process는 패키지와 비즈니스 로직을 처리하고 반환합니다.
• C++ 아키텍처를 사용하면 단일 머신 성능이 6kqps로 직접 향상되어 기본적으로 동일한 머신에서 더 많은 비즈니스를 지원할 수 있는 것으로 보입니다.

2.3 코루틴 소개

C++를 사용하면 성능 요구 사항은 충족되지만, 서비스의 높은 성능을 유지하기 위해 코드 로직에서는 다음과 유사한 비동기 콜백을 사용하는 등 개발 효율성에 많은 문제가 있습니다. 으아아아

GetValueCallback은 콜백 함수입니다. io 작업이 많은 경우 여기에서 콜백을 비슷한 동기화 방법으로 캡슐화하더라도 그때는 std::future 및 처리가 매우 번거로울 것입니다. std::async가 도입되지 않았습니다.

한편, 후속 qps가 10~20w 수준에 도달할 수 있다는 사실을 기반으로 코루틴은 다중 IO 서비스 처리 성능에서도 더 많은 이점을 갖게 되므로 코루틴 방식을 변형하기 시작했고 모든 IO 위치를 다음으로 교체했습니다. 비즈니스 개발을 위해 호출하면 코드는 다음과 같습니다.

으아아아

값은 코드에 io가 있으면 맨 아래 계층에서 io를 코루틴의 API로 대체합니다. 이런 방식으로 차단된 모든 io 작업은 동기화 프리미티브, 코드 구조 및 개발 효율성이 둘 다 많이 향상되었습니다(특정 코루틴 구현에 대해서는 "Linux 고성능 네트워크 프로그래밍에 대한 10가지 대화 | 코루틴" 시리즈를 참조하세요).

코루틴

아키텍처에는 아직 많은 변화가 없습니다. 다중 프로세스 + 코루틴 접근 방식은 수년 동안 기하급수적인 성능 성장은 없지만 고성능 탐색 및 침전에 대한 더 많은 경험을 얻었습니다.

3. 클라우드 네이티브

비즈니스는 계속 발전하고 있으며 엔지니어는 항상 가장 최첨단 개념을 추구합니다. 최근 몇 년 동안 인기 있는 기술 포인트인 클라우드 네이티브는 당연히 무시되지 않습니다. DevOps 개발 개념은 아키텍처 설계 및 프레임워크 선택에 대한 기술적 부채를 상환해야 하는 고통스러운 프로세스가 될 것입니다.

3.1 DevOps 개념 구현

과거에는 아키텍처를 할 때 고성능을 고려했습니다. 아키텍처에 대한 이해를 바탕으로 고성능은 아키텍처 디자인의 작은 영역에 불과하다는 것을 알았습니다. 좋은 아키텍처를 구축하려면 더 민첩한 프로세스와 서비스 거버넌스 개념은 다음과 같이 요약됩니다.

지속적 통합: 개발자는 하루에 여러 번 코드를 공유 저장소에 통합하며, 코드에 대한 모든 격리된 변경 사항은 즉시 테스트되어 통합 문제를 감지하고 예방합니다
지속적인 전달: CD(지속적인 전달)는 CI 저장소에서 테스트된 모든 코드 버전이 출시될 준비가 되었는지 확인합니다
지속적 배포: 여기에는 그레이스케일 배포, 청록색 릴리스 등이 포함됩니다. 목적은 비교적 완전한 통합 테스트 후 그레이스케일 검증을 달성할 수 있다는 것입니다.
서비스 검색: 서비스를 마이크로서비스로 전환하여 서비스 간 호출을 단순화
RPC 프레임워크: 고성능을 추구하는 서버 프레임워크에서는 전류 제한, 회로 차단기 등 기본 구성 요소의 지원도 고려해야 합니다
모니터링 시스템: Promethues, OpenTracing 및 기타 기능과 통합되어 민첩한 개발 프로세스에서 온라인 문제를 빠르게 발견할 수 있습니다
컨테이너화: 환경을 통합하고 클라우드 네이티브 시나리오를 미리 고려하기 위해서는 개발 프로세스에서 컨테이너화가 필수적입니다
…

DevOps

이 시점에서는 단순한 고성능 서버가 아키텍처의 목표가 되었음을 알게 되므로 DevOps 개념을 성공적으로 구현하기 위해서는 아키텍처를 재조사하고 설계해야 합니다.

3.2 멀티스레딩

위의 C++ Server 프레임워크와 결합된 DevOps를 기반으로 하면 다중 프로세스가 더 이상 아키텍처의 요구 사항을 충족할 수 없는 것으로 나타났습니다.

여러 프로세스는 Docker 컨테이너의 단일 프로세스 개념과 일치하지 않습니다
작업자 프로세스 부하가 고르지 않은 경우, 멀티 코어를 더 잘 활용하는 방법
모니터링 시스템과 효과적으로 인터페이스
비즈니스 구성이 반복적으로 로드되고 구성 센터를 다시 조정해야 합니다
상태 저장 서비스를 제공하기 위해 여러 프로세스를 사용하는 것은 그다지 합리적이지 않습니다
…

비즈니스도 백만 QPS로 성장했습니다. 더 나은 서비스 관리 및 서비스 통화 비용을 위해 우리는 또 다른 아키텍처를 고려해야 합니다.

(1)gRPC 연구

gRPC

gRPC는 멀티스레드 RPC

서버입니다. 성숙한 생태계, 다양한 미들웨어, 다국어 지원 등을 갖추고 있습니다. 0에서 1까지의 비즈니스 개발에는 적합하지만 개발과 같은 비즈니스 마이그레이션에 대한 어려움에 직면해 있습니다. 자체 미들웨어 적응 서비스 검색, 구성 센터 등, 사용자 정의 인코딩 및 디코딩에 따른 변환 프로토콜, 코루틴 결합 방법 등을 통해 일부 비즈니스를 만족시킬 수 있지만 여전히 RPC
Server와 더 잘 통합해야 합니다. 회사의 구성요소 중 하나입니다.

(2)tRPC 사용

회사에서 tRPC를 개발 중이었는데, 연구 결과 기본적으로 요구 사항이 충족된다는 사실을 발견하여 개발 초기 단계에서 tRPC의 C++ 버전을 우리 시스템에 적용하려고 노력했습니다. 고성능 RPC 프레임워크가 마이그레이션되어 비즈니스 시스템에 사용되었습니다. 이제 tRPC의 아키텍처는 다음과 같습니다.

https://trpc.group/zh/docs/what-is-trpc/archtecture_design/

위의 고려 사항과 비즈니스 개발을 바탕으로 우리는 후속 RPC의 다양한 시나리오에 적응하기 위해 고성능 기반의 RPC 서버 프레임워크를 통합하기 시작했으며 비즈니스 시스템에 적응하는 기본 RPC

서버 세트를 구현했습니다. 프레임:

새로운 아키텍처

3.3.k8s로 갑니다

위의 선택과 변형을 거친 후, k8s로의 마이그레이션 과정에서 우리 서비스는 단계적으로 연결될 수 있습니다. 서비스는 해당 플랫폼에서 실행되기 위해 너무 많은 변형을 겪을 필요가 없으며, 연결된 각 플랫폼도 가능합니다. 완벽하게 지원됩니다.

새로운 기술을 추구하고 다음 트렌드를 기다리기만 하면 될 것 같은데요? 사실 지금은 클라우드의 편리함과 마이그레이션 서비스 아키텍처, 비즈니스 서비스 및 논리 수준의 무질서한 확장으로 인해 더 많은 어려움이 있습니다. 동시에 서비스가 의존하는 다운스트림 링크는 점점 더 길어지고 있습니다. 비록 우리의 프레임워크가 링크 추적을 지원하지만 링크가 길어질수록 서비스의 제어 가능성과 안정성은 점점 더 나빠질 것입니다. , 그리고 일일 작전에 대한 인간 지원이 더 많이 낭비될 것입니다.

무엇을 할까요?…

비즈니스 로직을 병합하여 아키텍처를 단순화해야 할까요? 여기서 문제는 비즈니스 로직이 복잡하면 주기가 오래 걸리는 경우가 많고, 비용 측면에서도 상대적으로 높고, 이점도 그다지 크지 않다는 것입니다

새로운 아키텍처를 재개발해야 할지, 낡은 것을 그대로 유지해야 할지, 아니면 버려야 할지, 다음 개발에 적응하기 위해 새로운 아키텍처를 사용해야 할지.

위 내용은 Linux 고성능 네트워크 프로그래밍에 관한 10가지 토론의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!