환경 모니터링 IoT 시스템을 처음부터 설계하기(2)

센서 데이터를 수신하는 주요 입구인 IOT 게이트웨이는 주로 로그, 보안 보호, 흐름 제어, 프로토콜 변환 등의 기능을 가지고 있습니다.

그림 1 IOT 게이트웨이

앞서 IOT 게이트웨이가 Python의 뒤틀린 프레임워크를 기반으로 구현되었다고 언급한 바 있습니다. 초기에는 IOT 게이트웨이의 주요 기능이 데이터 수신 및 변환 기능과 보안 보호였습니다.

여기서 데이터 수신 및 변환 기능은 매우 간단합니다. 데이터 상호 작용 형식이 작성된 후 IOT 게이트웨이는 이를 합의된 형식에 따라 구문 분석한 다음 추가 작업을 위해 이를 백엔드 서비스로 전달합니다. 처리

보안 보호를 위해 주로 하드웨어에 기록된 SN 번호에 따라 장비를 구별합니다. SN 번호에는 생산 배치, 장비 모델 등과 같은 많은 정보가 포함되어 있습니다. 제조사에게 완벽한 보안 보호를 제공할 수는 없습니다. 센서와 IOT 게이트웨이 간의 상호 작용은 그리 복잡할 수 없습니다. 이론적으로 보안 보호에는 장치 액세스에 대해 하나의 유형, 하나의 암호화 또는 하나의 시스템, 하나의 암호화가 필요하며 TLS/SSL 보안 통신 프로토콜도 프로토콜에서 활성화되어야 합니다.

그림 2 인증

보안 보호를 위해 SSL과 같은 보안 통신 프로토콜이 필요한 경우 장비 제조업체의 통신 모듈 구현 능력, 장비 전력 소비 및 장비 성능(저사양 장비) CPU 성능이 저하될 수 있으므로 대칭 암호화를 고려할 수 있음), IOT 게이트웨이에도 해당 모듈을 도입해야 합니다.

또한 인증은 향후 성능 고려 사항을 바탕으로 이루어지며, 장치 정보를 캐시하기 위해 redis와 같은 인메모리 키-값 데이터베이스를 추가하여 인증 성능을 향상시킬 수 있습니다. 기준 치수.

실제로 우리의 센서는 기본적으로 배터리로 구동되므로 우리의 IOT 게이트웨이는 기본적으로 짧은 링크를 지향합니다(나중에 우리는 직접 전원 공급을 위해 외부 전원 공급 장치에 의존하는 모니터링 장비를 갖게 될 것입니다. 연결)이므로 연결이 시작될 때마다 인증을 수행해야 합니다. 인증이 통과된 후 장치는 센서 모니터링 데이터와 장치 자체 상태를 업로드할 수 있습니다.

그림 3 데이터 상호작용 과정

이 분야의 디버깅 작업은 기본적으로 하드웨어 공급업체 외에 주로 안정화되기까지 약 반년 동안 진행되었습니다. 안정성, 디버깅도 진행 중이었으며, 전송된 문자열이 깨졌거나(C 언어 처리 문제), 패킷이 막히거나(제조업체 개발자가 TCP 프로토콜에 익숙하지 않음), 전송 효율성을 최적화하고 코르크를 끄는 것으로 나타났습니다. 또는 Nagle 알고리즘(전송 패킷이 매우 작음).

IOT 게이트웨이는 능동적으로 연결을 끊을 수 없기 때문에 이론적으로 IOT 게이트웨이에는 연결의 유효성을 보장하기 위해 센서와 함께 하트비트 프로토콜이 있어야 합니다. 이를 방지하기 위해 장비 제조사에서는 데이터 처리 상호작용이 완료된 후에도 연결을 종료하지 않고 바로 휴면 상태에 들어갔으며, 이로 인해 게이트웨이가 위치한 서버에 대한 연결의 파일 디스크립터가 정상적으로 해제되지 않았습니다. 이 현상은 나중에 운영 체제 수준에서 keepalve 타이머를 켰습니다. 실패한 연결을 재활용하려면(시스템 기본 시간은 약 2시간이므로 실패 시간을 단축했습니다.) 이론적으로는 애플리케이션 수준에서 구현하여 하트비트 프로토콜을 구현해야 합니다. .

전체 IOT 게이트웨이 설계는 상태 비저장이며 확장 가능합니다. 단일 게이트웨이는 일반 EC에서 수백 tps에 쉽게 도달할 수 있습니다.