장치당 120만 개의 연결을 제공하는 Xiaoai 게이트웨이는 어떻게 구성되어 있나요?

앞에서 말했지

40세 건축가 니엔의 독자교류단 (50+)에는 알리바바, 넷이즈, 유잔, 시인, 바이두, 디디 등 1급 인터넷 기업의 면접 자격을 취득한 친구들이 많다.

최근 Nien은 친구의 이력서를 안내하고 " Long Connection Gateway 프로젝트 아키텍처 및 실제 운영 "을 작성했습니다. 이 프로젝트는 이 친구가 Byte/Alibaba/Weibo/Autohome에서 인터뷰 초대를 받는 데 도움이 되었기 때문에 이것은 멋진 프로젝트입니다.

여러분이 더 많은 면접 기회를 얻고 대기업으로부터 더 많은 제안을 받을 수 있도록 돕기 위해,

Nien은 이 프로젝트의 아키텍처와 실제 운영을 소개하기 위해 9월에 비디오 장 "33장: 10Wqps 높은 동시성 Netty 게이트웨이 아키텍처 및 실제 운영"을 게시하기로 결정했으며 이달 말 공개될 예정입니다. 그런 다음 일대일 이력서 안내를 제공하여 귀하의 이력서를 빛나고 완전히 변화시킬 수 있습니다.

"33장: 10Wqps 높은 동시성 Netty 게이트웨이 아키텍처 및 실제 운영" 포스터는 다음과 같습니다.

"33장: 10Wqps 높은 동시성 Netty 게이트웨이 아키텍처 및 실제 운영"과 함께 Nien은 여러 산업 등급 및 프로덕션 등급 게이트웨이 사례를 건축 및 디자인 자료로 분류합니다.

앞쪽에 정리되어 있어요

위의 5가지 사례 외에도 학습 사례를 분류하는 과정에서 Nien은 또 다른 아름다운 프로덕션 수준 사례를 발견했습니다. " 단일 장치에 120만 개의 연결이 있는 경우 Xiaoai 게이트웨이는 어떻게 구성되어 있습니까?" 》,

주의, 이것은 또 다른 매우 훌륭하고 최고 수준의 산업 등급 및 생산 등급 게이트웨이 케이스 입니다 .

이러한 사례는 Nien의 독창적인 사례가 아닙니다.

이러한 사례는 모두가 배우고 소통할 수 있는 "33장: 10Wqps 높은 동시성 Netty 게이트웨이 아키텍처 및 실제 운영" 비디오 강의를 준비하는 동안 인터넷에서 정보를 검색하는 동안 Nien이 수집한 것입니다.

"Nien 아키텍처 노트", "Nien High Concurrency Trilogy" 및 "Nien Java 인터뷰 가이드"의 PDF는 공식 계정 [Technical Freedom Circle]에서 얻으실 수 있습니다.

기사 디렉토리

장치당 120만 개의 연결을 제공하는 Xiaoai 게이트웨이는 어떻게 구성되어 있나요?

저자: Xiaoai 기술 팀

1. Xiaoai 액세스 게이트웨이의 거대한 진화 성과

Xiao Ai("Xiao Ai Classmate"라고도 함)는 Xiaomi가 소유한 인공 지능 음성 상호 작용 엔진입니다.

"Xiaoai Classmate"는 Xiaomi 그룹의 통합 지능형 음성 서비스 인프라입니다.

"Xiao Ai Classmate" 클라이언트는 Xiaomi 휴대폰, Xiaomi AI 스피커, Xiaomi TV 및 기타 장치에 통합되어 개인 이동성, 스마트 홈, 스마트 웨어러블, 스마트 오피스, 어린이 엔터테인먼트, 스마트 여행, 스마트 호텔 및 기타 분야에서 널리 사용됩니다. 스마트 학습 등 8개 장면.

Xiaoai 액세스 계층은 Xiaoai 클라우드 장치 액세스를 위한 핵심 서비스이자 핵심 서비스 중 하나입니다.

Xiaomi 기술팀은 2020년부터 2021년까지 이 서비스에 대한 일련의 최적화와 시도를 수행했습니다. 결국 단일 기계가 전달할 수 있는 긴 연결 수를 300,000에서 120W 이상으로 늘려 30개 이상의 기계를 절약하는 데 성공했습니다.

2. Xiaoai 액세스 레이어란 무엇입니까?

Xiaoai의 전체 아키텍처 계층은 다음과 같습니다 .

액세스 서비스는 주로 인증 및 권한 부여 계층과 전송 계층을 담당하며 모든 Xiaoai 장치가 Xiaoai Brain과 상호 작용하는 첫 번째 서비스입니다.

위 그림에서 Xiaoai 액세스 서비스의 중요한 기능에는 다음 사항이 포함되어 있음을 알 수 있습니다 .

1) 안전한 전송 및 인증: 신원 인증의 유효성과 데이터 전송의 보안을 보장하기 위해 장치와 뇌 사이의 보안 채널을 보호합니다.
2) 긴 연결 유지: 장치와 뇌(예: Websocket 등) 사이의 긴 연결을 유지하고, 연결 상태를 적절하게 저장하고, 하트비트 유지 관리 및 기타 작업을 수행합니다.
3) 요청 전달: 각 요청의 안정성을 보장하기 위해 Xiaoai 장치의 각 요청을 전달합니다.

3. 얼리 액세스 레이어의 기술적 구현

Xiaoai 액세스 레이어의 초기 구현은 Akka 및 playframework를 기반으로 했으며 이를 사용하여 첫 번째 버전을 구축했으며 그 기능은 다음과 같습니다.

1) Akka를 기반으로 코어 스레드가 차단되지 않고 성능이 좋아지도록 예비 비동기화를 구현했습니다.
2) 플레이프레임워크 프레임워크는 웹소켓을 자연스럽게 지원하기 때문에 제한된 인력으로 빠르게 구축 및 구현이 가능하며, 프로토콜 구현의 표준화를 보장할 수 있습니다.

플레이라고 하는 플레이프레임워크는 springmvc와 유사한 웹 개발 프레임워크입니다.

4. 얼리 액세스 레이어의 기술적 문제

XiaoAi의 긴 연결 수가 수천만 개에 도달하면서 우리는 조기 액세스 레이어 솔루션에 몇 가지 문제가 있음을 발견했습니다.

주요 이슈는 다음과 같습니다 .

1) 긴 연결 수가 늘어날수록 더 많은 메모리 데이터를 유지해야 하며 JVM의 GC는 성능 병목 현상이 발생하고 GC 위험이 있습니다. 사고 분석 결과, Akka+Play 버전의 액세스 레이어에서 단일 인스턴스 긴 연결 수의 상한선은 약 280,000개인 것으로 나타났습니다.
2) 이전 버전의 액세스 레이어 구현은 상대적으로 무작위입니다. Akka Actor 간에 상태 종속성이 많고 불변 메시지 전달을 기반으로 하지 않습니다. 결과적으로 액터 간의 통신은 함수 호출과 같습니다. 코드는 읽기 어렵고, 유지 관리가 어렵고, 작동하지 않습니다. 동시 프로그램 구축 시 Akka Actor의 장점.
3) 액세스 계층 서비스로서 이전 버전은 프로토콜 구문 분석에 대한 의존도가 높으며 버전 업데이트로 자주 온라인 상태가 되어야 하므로 연결 재연결 시간이 길어지고 눈사태 위험이 발생할 수 있습니다.
4) Play 프레임워크에 대한 의존으로 인해 긴 연결 관리가 부정확하다는 사실을 발견했습니다(기본 TCP 연결 데이터를 얻을 수 없기 때문에). 이는 서비스 용량 평가에 대한 일일 검사에 영향을 미치며 긴 연결 수 후에 증가하면 더 자세한 최적화를 수행할 수 없습니다.

5. 새로운 접근 계층의 설계 목표

얼리 액세스 레이어 기술 솔루션의 많은 문제점을 고려하여 우리는 액세스 레이어를 재구성하기로 결정했습니다.

새 버전의 액세스 계층의 설계 목표는 다음과 같습니다 .

1) 높은 안정성: 안정적인 서비스를 보장하기 위해 온라인 프로세스 중에는 연결 끊김을 최대한 피합니다.
2) 고성능: 대상 단일 머신은 최소 100만 개의 긴 연결을 전달할 수 있으며 GC의 영향을 피하려고 노력합니다.
3) 높은 제어성: 기본 네트워크 I/O의 시스템 호출을 제외하고 다른 모든 코드는 자체적으로 구현되거나 내부 구성 요소를 사용하여 자율성을 높여야 합니다.

따라서 우리는 단일 시스템에서 수백만 개의 긴 연결을 달성하기 위한 탐색 여정을 시작했습니다.

6. 새로운 액세스 계층을 위한 최적화 아이디어

6.1 액세스 레이어 종속성

액세스 계층과 외부 서비스 간의 관계는 다음과 같이 명확해집니다 .

6.2 액세스 계층의 기능적 분할

액세스 계층의 주요 책임은 다음과 같이 요약될 수 있습니다 .

1) WebSocket 디코딩: 수신된 클라이언트 데이터 스트림은 WebSocket 프로토콜에 따라 구문 분석되어야 합니다.
2) 소켓 상태 유지: 연결의 기본 정보를 저장합니다.
3) 암호화 및 복호화: 클라이언트와 통신하는 모든 데이터는 암호화되어야 하며 백엔드 모듈 간의 전송은 일반 텍스트 JSON입니다.
4) 순차화: 동일한 물리적 연결의 두 요청 A와 B가 서버에 도착합니다. 백엔드 서비스에서는 B가 A보다 먼저 응답을 받을 수 있지만 클라이언트에 보내기 전에 A가 완료될 때까지 기다려야 합니다. A와 B의 순서. ;
5) 백엔드 메시지 배포: 액세스 계층은 단일 서비스와 인터페이스할 뿐만 아니라 다양한 메시지를 기반으로 다양한 서비스에 요청을 전달할 수도 있습니다.
6) 인증 : 보안관련 본인인증, 본인인증 등

6.3 액세스 레이어 분할 아이디어

이전 단일 모듈을 상태 유무에 따라 두 개의 하위 모듈로 분할합니다.

세부 사항은 다음과 같습니다 .

1) 프런트엔드: 상태 저장, 최소화된 기능 및 온라인 최소화;
2) 백엔드: 상태 비저장, 최대화된 기능 및 온라인 시 사용자 인식이 없습니다.

따라서 위의 원칙에 따라 이론적으로 이러한 기능적 분할, 즉 프런트 엔드는 더 작고 백 엔드는 더 크게 달성됩니다. 개략도는 아래와 같습니다.

7. 새로운 액세스 계층의 기술적 구현

7.1 개요

모듈은 프런트엔드와 백엔드로 분할됩니다 .

1) 프런트 엔드는 상태 저장이고 백 엔드는 상태 비저장입니다.
2) 프런트엔드와 백엔드는 독립적인 프로세스이지만 동일한 머신에 배포됩니다.

보충 : 프런트 엔드는 장치의 긴 연결 상태를 유지하는 역할을 담당하므로 상태 저장 서비스이고, 백 엔드는 특정 비즈니스 요청을 처리하는 역할을 담당하므로 상태 비저장 서비스입니다. 백엔드 서비스 출시로 인해 기기 연결이 중단되거나 다시 연결되거나 인증 호출이 발생하지 않으므로 버전 업그레이드나 로직 조정으로 인해 장시간 연결 상태가 불필요하게 변동되는 것을 방지할 수 있습니다.

프런트 엔드는 C++로 구현됩니다 .

1) WebSocket 프로토콜을 독립적으로 구문 분석합니다. 소켓 수준에서 모든 정보를 얻고 모든 버그를 처리할 수 있습니다.
2) 더 높은 CPU 활용도: 추가 JVM 오버헤드가 없고 성능에 대한 GC 저하가 없습니다.
3) 더 높은 메모리 활용도: 연결 수가 증가하면 연결과 관련된 메모리 소비도 증가하며 자체 관리를 통해 극도의 최적화를 달성할 수 있습니다.

백엔드는 Scala에서 임시로 구현됩니다 .

1) 구현된 기능을 다시 작성하는 것보다 훨씬 저렴한 비용으로 직접 마이그레이션할 수 있습니다.
2) 일부 외부 서비스(예: 인증)에는 직접 사용할 수 있는 Scala(Java) SDK 라이브러리가 있지만 C++ 버전이 없으므로 C++로 다시 작성하면 비용이 매우 많이 듭니다.
3) 모든 기능은 사용자가 눈치채지 못하게 언제든지 다시 시작할 수 있는 무상태 기능으로 변환되었습니다.

통신은 ZeroMQ를 사용합니다 .

프로세스 간 통신을 위한 가장 효율적인 방법은 공유 메모리인데, ZeroMQ 는 공유 메모리를 기반으로 구현되므로 속도에는 문제가 없습니다.

7.2 프론트엔드 구현

전체 아키텍처 :

위 그림과 같이 4개의 하위 모듈로 구성됩니다 .

1) 전송 계층: 웹소켓 프로토콜 분석, XMD 프로토콜 분석
2) 분산 계층: 전송 계층의 차이점을 보호하며 전송 계층이 어떤 인터페이스를 사용하든 분산 계층에서 통일된 이벤트로 변환되어 상태 머신에 전달됩니다.
3) 상태 머신 계층: 순수 비동기 서비스를 구현하기 위해 단일 스레드 액터 추상화를 구현하는 Actor 모델을 기반으로 독립적으로 개발된 Akka와 유사한 상태 머신 프레임워크 XMFSM이 사용됩니다.
4) ZeroMQ 통신 계층: ZeroMQ 인터페이스는 차단 구현이므로 이 계층은 두 개의 스레드를 통해 송수신을 담당합니다.

7.2.1 전송 계층:

WebSocket 부분은 C++ 및 ASIO를 사용하여 websocket-lib를 구현합니다. Xiaoai 긴 연결은 WebSocket 프로토콜을 기반으로 하므로 WebSocket 긴 연결 라이브러리를 독립적으로 구현했습니다.

이 긴 연결 라이브러리의 특징은 다음과 같습니다 .

a. 우수한 성능을 보장하는 잠금 없는 디자인;
b. 기본 네트워크 성능을 보장하기 위해 BOOST ASIO를 기반으로 개발되었습니다.

스트레스 테스트는 이 라이브러리의 성능이 매우 우수하다는 것을 보여줍니다 .

긴 링크 수	SWC	P99 지연
100와트	5와트	5ms

이 계층은 원래 WebSocket 외에 다른 두 채널의 작업 전송 및 수신도 담당합니다.

현재 전송 계층은 다음과 같은 3가지 클라이언트 인터페이스를 지원합니다 .

a. websocket(tcp): ws라고 합니다.
b. SSL 기반 암호화된 웹소켓(tcp): wss라고 합니다.
c. xmd(udp): xmd라고 합니다.

7.2.2 분배층:

다양한 전송 계층 이벤트를 통합 이벤트로 변환하여 상태 머신에 전달합니다. 이 계층은 이전 전송 계층에서 어떤 유형이 사용되었는지에 관계없이 분산 계층에 도달하면 일관된 이벤트가 되도록 보장하는 어댑터 역할을 합니다. 상태 머신에 전달됩니다.

7.2.3 상태 머신 처리 계층:

주요 처리 논리는 이 계층에 있으며 여기서 매우 중요한 부분은 전송 채널의 캡슐화입니다.

Xiaoai 애플리케이션 계층 프로토콜의 경우 다양한 채널의 처리 논리는 완전히 일관되지만 각 채널은 처리 및 보안 관련 논리에 세부적인 차이가 있습니다.

예를 들면 다음과 같습니다 .

a. Wss 전송 및 수신에는 암호화 및 암호 해독이 필요하지 않습니다. 암호화 및 암호 해독은 더 프런트 엔드 Nginx에 의해 완료되는 반면 wss는 AES 암호화를 사용하여 전송되어야 합니다.
b. 성공적인 인증 후에는 wss가 암호화 및 암호 해독을 수행할 필요가 없기 때문에 wss는 클라이언트에 챌린지 텍스트를 보낼 필요가 없습니다.
c. xmd에서 보낸 내용은 다른 두 내용과 다릅니다. protobuf로 캡슐화된 전용 프로토콜을 기반으로 하며 xmd는 전송 실패 후 로직을 처리해야 하지만 ws/wss는 전송 실패 문제를 고려할 필요가 없습니다. , 이는 기본 Tcp 프로토콜에 의해 보장됩니다.

이러한 상황에 대응하여 C++의 다형성 기능을 사용하여 이를 처리하고 특히 채널 인터페이스를 추상화합니다. 이 인터페이스에서 제공되는 메소드에는 요청 처리의 몇 가지 주요 단계, 클라이언트에 메시지를 보내는 방법, 연결을 중지하는 방법, 전송 실패를 처리하는 방법 등이 있습니다. 3개의 서로 다른 전송 채널(ws/wss/xmd)의 경우 각 채널에는 자체 채널 구현이 있습니다.

클라이언트 연결 개체가 생성되자마자 해당 유형의 특정 채널 개체가 인스턴스화됩니다. 이런 식으로 상태 머신의 메인 로직은 비즈니스 계층의 공통 로직만 구현하면 되며 차등 로직 호출이 있을 때 채널 인터페이스가 직접 호출되어 완료됩니다. 이러한 간단한 다형성 기능은 차이점을 분리하는 데 도움이 됩니다. 코드가 깨끗한지 확인하세요.

7.2.4 ZeroMQ 통신 계층:

ZeroMQ의 읽기 및 쓰기 작업은 두 개의 스레드를 통해 비동기식이며 여러 개인 명령어의 캡슐화 및 구문 분석을 담당합니다.

7.3 백엔드 구현

7.3.1 무상태 변환:

백엔드에 적용된 가장 중요한 변경 사항 중 하나는 연결 상태와 관련된 모든 정보를 제거하는 것 입니다 .

전체 서비스는 Request(1개의 연결에 N개의 요청을 전송할 수 있음)를 핵심으로 다양한 전달 및 처리를 수행하며, 각 요청은 이전 요청과 연결되지 않습니다. 하나의 연결에 대한 여러 요청은 백엔드 모듈에서 독립적인 요청으로 처리됩니다.

7.3.2 아키텍처:

Scala 서비스는 Akka-Actor 아키텍처를 사용하여 비즈니스 로직을 구현합니다.

서비스가 ZeroMQ로부터 메시지를 받은 후 데이터 분석 및 요청 처리를 위해 Dispatcher로 직접 전달됩니다. Dispatcher의 다양한 요청은 이벤트 프로토콜 분석을 위해 해당 RequestActor로 전송되고 이벤트에 해당하는 비즈니스 Actor로 배포됩니다. 처리. 마지막으로 처리된 요청 데이터는 XmqActor를 통해 백엔드 AIMS&XMQ 서비스로 전송됩니다.

백엔드의 여러 행위자에 대한 요청 처리 흐름 :

7.3.3 발송자 요청 배포:

Protobuf를 사용하면 프런트 엔드와 백 엔드가 상호 작용할 수 있으므로 Json 구문 분석 성능을 절약하고 프로토콜을 더욱 표준화할 수 있습니다.

ZeroMQ가 보낸 메시지를 받은 후 백엔드 서비스는 DispatcherActor에서 PB 프로토콜을 구문 분석하고 다양한 분류(줄여서 CMD)에 따라 데이터 처리를 수행합니다. 분류는 다음과 같습니다.

바인드 명령 :

이 기능은 장치 인증에 사용되며, C++에서는 인증 로직이 복잡하고 구현하기 어렵기 때문에 여전히 Scala 비즈니스 계층에서 인증이 수행됩니다. 이 부분에서는 주로 장치에서 요청한 HTTP 헤더를 구문 분석하고 인증을 위한 토큰을 추출한 후 그 결과를 프런트 엔드에 반환합니다.

로그인 명령 :

이 명령은 장치 로그인에 사용됩니다. 장치가 인증을 통과하고 연결이 성공적으로 설정된 후 LOGIN 명령을 실행하여 긴 연결 정보를 AIMS로 보내고 후속 활성 푸시 및 기타 기능을 위해 Varys 서비스에 기록합니다. LOGIN 프로세스 중 서비스는 먼저 긴 연결의 uuid(연결 프로세스 중 라우팅 주소 지정에 사용)를 얻기 위해 Account 서비스에 요청한 다음 장치 로그인 작업을 위해 장치 정보 + uuid를 AIMS로 보냅니다.

로그아웃 명령 :

이 명령은 장치에서 로그아웃하는 데 사용됩니다. 장치가 서버에서 연결이 끊어지면 로그아웃 작업을 수행하여 Varys 서비스에서 긴 연결 기록을 삭제해야 합니다.

UPDATE 및 PING 명령 :

a. 장치 상태 정보 업데이트인 업데이트 명령은 장치의 데이터베이스에 저장된 관련 정보를 업데이트하는 데 사용됩니다.
b. Ping 명령, 연결 유지는 장치가 온라인인지 확인하는 데 사용됩니다.

TEXT_MESSAGE 与 BINARY_MESSAGE：

문자 메시지 및 바이너리 메시지 문자 메시지 또는 바이너리 메시지가 수신되면 requestid에 따라 처리하기 위해 요청에 해당하는 RequestActor로 전송됩니다.

7.3.4 요청 분석 요청:

수신된 텍스트 및 바이너리 메시지는 requestId에 따른 처리를 위해 DispatcherActor에 의해 해당 RequestActor로 전송됩니다.

그중에는 텍스트 메시지가 이벤트 요청으로 구문 분석된 다음 네임스페이스와 이름을 기반으로 지정된 비즈니스 액터에 배포됩니다. 바이너리 메시지는 현재 요청된 비즈니스 시나리오에 따라 해당 비즈니스 행위자에게 배포됩니다.

7.4 기타 최적화

새로운 아키텍처 1.0의 조정을 완료하는 과정에서 연결 용량을 지속적으로 측정하고 용량에 더 큰 영향을 미치는 몇 가지 사항을 요약하고 있습니다.

7.4.1 프로토콜 최적화:

a. JSON을 Protobuf로 대체 : 초기 Front-end 및 Back-end 통신에서는 JSON 텍스트 프로토콜을 사용했으나 JSON 직렬화 및 역직렬화가 CPU를 많이 차지한다는 사실이 밝혀졌고, Protobuf 프로토콜로 전환한 후 CPU 사용량이 감소했습니다. 크게.
b. JSON은 부분 구문 분석을 지원합니다 . 비즈니스 계층 프로토콜은 JSON을 기반으로 하며 직접 교체할 수 없기 때문에 "JSON 부분 구문 분석" 방법을 채택하여 더 작은 헤더 부분만 구문 분석하여 네임스페이스와 이름을 얻은 다음 가장 많은 부분을 전달합니다. 직접 전달된 메시지 중 소수의 JSON 메시지만 개체로 완전히 역직렬화됩니다. 이 최적화 후에는 CPU 사용량이 10% 감소합니다.

7.4.2 하트비트 시간 연장:

20w 연결을 처음 테스트했을 때 프런트엔드와 백엔드에서 보내고 받는 메시지 중 사용자를 온라인 상태로 유지하는 데 사용되는 하트비트 PING 메시지가 전체 메시지 볼륨의 75%를 차지하는 것으로 나타났습니다. CPU가 많아요. 따라서 하트비트 시간을 연장하고 CPU 소비를 줄이는 목적도 달성합니다.

7.4.3 자체 개발한 인트라넷 통신 라이브러리:

백엔드 서비스와의 통신 성능을 향상시키기 위해 Boost ASIO를 기반으로 개발된 순수 비동기 멀티스레드 TCP 네트워크 라이브러리인 자체 개발한 TCP 통신 라이브러리를 사용하고 있으며, 뛰어난 성능으로 인해 통신수 증가에 도움이 됩니다. 120w+에 대한 연결.

8. 미래 계획

새 아키텍처 버전 1.0의 최적화 후 미리 설정된 목표가 달성되었으므로 분할 방향이 올바른지 확인되었습니다 .

1) 단일 머신이 전달하는 연결 수는 28w => 120w+(16G 메모리 및 40개 코어를 갖춘 일반 서버 머신의 최대 요청 QPS가 10,000을 초과함)이며 액세스 레이어가 오프라인이 되어 머신 비용이 50% 이상 절약됩니다. ;
2) 백엔드는 무손실로 시작될 수 있습니다.

이상적인 목표를 다시 검토해 보고 이를 방향으로 삼아 버전 2.0의 프로토타입을 만들었습니다 .

구체적으로 :

1) 성능과 안정성을 더욱 향상시키기 위해 백엔드 모듈을 C++로 다시 작성했습니다. 동시에 C++로 다시 작성할 수 없는 백엔드 모듈 부분은 독립적인 서비스 모듈로 운영 및 유지되며 백엔드 모듈은 네트워크 라이브러리를 통해 호출됩니다.
2) 프론트엔드 모듈의 필수적이지 않은 기능을 백엔드로 마이그레이션하여 프런트엔드의 기능을 줄이고 안정성을 높이십시오.
3) 변환 후 프런트엔드와 백엔드의 처리 능력이 상당히 다른 경우 ZeroMQ가 실제로 초과 성능을 가지고 있다는 점을 고려하면 네트워크 라이브러리를 사용하여 ZeroMQ를 대체하는 것을 고려할 수 있습니다. 백엔드 배포는 1:1 단일 머신에서 1:N 다중 머신 배포까지 가능하며, 머신 배포를 통해 머신 리소스를 더 효율적으로 활용할 수 있습니다.

버전 2.0의 목표는 위의 변환 후에 단일 프런트 엔드 모듈이 200만 개 이상의 연결 처리 기능에 도달할 수 있을 것으로 예상되는 것입니다.

끝으로: 질문이 있는 경우 이전 아키텍처에서 조언을 구할 수 있습니다.

건축으로 가는 길은 우여곡절이 많다

아키텍처는 고급 개발과 다릅니다. 아키텍처 질문은 개방형/개방형이며 아키텍처 질문에 대한 표준 답변은 없습니다.

이 때문에 많은 친구들은 많은 에너지와 돈을 소비했음에도 불구하고 불행히도 평생 동안 아키텍처 업그레이드를 완료하지 못합니다 .

따라서 아키텍처 업그레이드/변환 과정에서 실제로 효과적인 솔루션을 찾을 수 없다면 40세 건축가 니엔에게 도움을 요청할 수 있습니다.

얼마 전, 전공을 넘나들며 Java를 연구하던 친구가 지금은 아키텍처 전환에 대한 문제에 직면해 있는데, Nien의 몇 차례의 지도 끝에 Java 아키텍트 + 빅데이터 아키텍트 제안을 성공적으로 받았습니다 . 따라서 직업상 어려움을 겪을 경우 경험이 풍부한 건축가에게 도움을 요청하는 것이 훨씬 더 원활할 것입니다.

장치당 120만 개의 연결을 제공하는 Xiaoai 게이트웨이는 어떻게 구성되어 있나요?

앞에서 말했지

기사 디렉토리

장치당 120만 개의 연결을 제공하는 Xiaoai 게이트웨이는 어떻게 구성되어 있나요?

1. Xiaoai 액세스 게이트웨이의 거대한 진화 성과

2. Xiaoai 액세스 레이어란 무엇입니까?

3. 얼리 액세스 레이어의 기술적 구현

4. 얼리 액세스 레이어의 기술적 문제

5. 새로운 접근 계층의 설계 목표

6. 새로운 액세스 계층을 위한 최적화 아이디어

6.1 액세스 레이어 종속성

6.2 액세스 계층의 기능적 분할

6.3 액세스 레이어 분할 아이디어

7. 새로운 액세스 계층의 기술적 구현

7.1 개요

7.2 프론트엔드 구현

7.2.1 전송 계층:

7.2.2 분배층:

7.2.3 상태 머신 처리 계층:

7.2.4 ZeroMQ 통신 계층:

7.3 백엔드 구현

7.3.1 무상태 변환:

7.3.2 아키텍처:

7.3.3 발송자 요청 배포:

7.3.4 요청 분석 요청:

7.4 기타 최적화

7.4.1 프로토콜 최적화:

7.4.2 하트비트 시간 연장:

7.4.3 자체 개발한 인트라넷 통신 라이브러리:

8. 미래 계획

끝으로: 질문이 있는 경우 이전 아키텍처에서 조언을 구할 수 있습니다.

추천도서

Supongo que te gusta