Design of a Next‑Generation Qunar Database Automation Platform: Architecture, Communication Protocol, and Security

The document introduces the overall architecture of the next‑generation Qunar database automation platform, which is built in layers where each module focuses on specific functions; the Server acts as the initialization and control node, and Meta serves as the metadata center.

Key design goals include functional request handling, secure transmission of sensitive data (passwords, keys), authentication for high‑impact requests, and minimal reliance on external services.

Analysis of Communication Methods

Common communication protocols considered are TCP/UDP (transport layer, fully customizable but high development cost), RPC (application layer, mature with good performance but requires specific clients), and HTTP/HTTPS (application layer, widely supported, easy debugging, lower performance).

Given the low performance requirements and the need for simplicity, HTTP is chosen for Agent/Plugin‑Server communication.

Encryption Requirements

Only interfaces carrying sensitive information are encrypted; non‑sensitive data (e.g., server or hardware info) is transmitted in plain text to avoid unnecessary overhead.

Symmetric Encryption

Symmetric encryption uses the same key for encryption and decryption. Algorithms such as AES, DES, and 3DES are discussed, with AES recommended for its speed, high security, and low resource consumption.

密文=Func(明文,秘钥)

明文=Func(密文,秘钥)

Asymmetric Encryption

Asymmetric encryption uses a public‑private key pair; the public key encrypts data, and the private key decrypts it. Common algorithms include RSA, DSA, and ECC.

密文=Func(明文,公钥)

明文=Func(密文,私钥)

Process Design

Authentication Flow

When an Agent starts, it registers with the Server, which generates a unique securityKey for that Agent, encrypts the Agent’s configuration with the securityKey , and encrypts the securityKey itself with a shared binary‑embedded key . The Server then sends the encrypted configuration back to the Agent, which decrypts the securityKey using the shared key and subsequently decrypts its configuration.

Request Flow

The Server creates a token containing its identity, encrypts the token with the Agent’s securityKey , and sends the token with a command request. The Agent validates the token, decrypts the service information, checks the identity, and executes the command if verification succeeds.

Key Points

The shared key is only used to encrypt/decrypt the securityKey and never stored in configuration files.

Each Agent has a unique securityKey generated at registration, kept in memory, and used solely for encrypting sensitive data.

The token embeds encrypted Server identity information; the Agent verifies this information before processing requests.

This design forms part of the overall Qunar database automation platform, with future articles planned to detail the full construction process.