Design Evolution of Cloud Development Gateway: From Dual‑Layer to Single‑Layer Architecture

CloudBase (Tencent CloudBase, TCB) is a cloud‑native, integrated development environment and tool platform that provides highly available, auto‑scaling backend services such as compute, storage, and serverless capabilities for various front‑ends (Mini‑Programs, public accounts, Web, Flutter, etc.). This article details the migration of the Cloud Development gateway architecture from a dual‑layer to a single‑layer design and discusses its practical implications.

1. Introduction

The Cloud Development gateway, built on Envoy, offers a private link, traffic governance, and weak‑network acceleration. Its core capability is a secure private link that protects traffic from MITM attacks. Although HTTPS already encrypts traffic, additional private‑link encryption is necessary for high‑security scenarios such as e‑commerce price data or appointment booking systems.

1.1 Problems with HTTPS

HTTPS encrypts data using TLS 1.2/1.3, making brute‑force decryption infeasible. However, attackers can still perform MITM attacks if they can install a malicious root certificate, which is difficult in most cases. Certain high‑risk domains (e.g., price comparison, ticketing) require protection beyond standard HTTPS.

1.2 Countermeasures against MITM

Use mTLS for mutual authentication.

Apply SSL Pinning to bind domains to certificates.

Detect proxy or VPN usage.

Encrypt business data again via a private link.

These measures have limitations on mobile, H5/Web, and mini‑programs due to certificate access restrictions and the ease of bypassing SSL Pinning with tools like Xposed or Frida.

2. Dual‑Layer Architecture

In the dual‑layer design, the gateway consists of a separate encryption/decryption module followed by an Envoy cluster. All HTTP traffic (request line, headers, body, and response components) is encrypted before reaching the gateway, then decrypted inside the gateway for further processing. This approach forces the traffic to downgrade from L7 to L4, which works for native apps but not for browsers that cannot use raw sockets.

2.1 Business Traffic Encapsulation

Business requests are encrypted and placed into the private‑link payload (e.g., using Protocol Buffers). The encrypted payload is then forwarded through Envoy, preserving HTTP semantics while adding a secure layer.

2.2 Early Architecture Design

The initial design added a dedicated encryption/decryption module between the client SDK and the Envoy cluster. This module required significant CPU resources, health‑check logic, and custom Prometheus metrics, increasing operational complexity and cost.

3. Single‑Layer Architecture

By integrating the encryption/decryption logic directly into Envoy (via filters), the architecture collapses into a single layer. Envoy now handles both traffic forwarding and private‑link processing, simplifying health checks, monitoring, and resource management.

3.1 Envoy Filters

Envoy supports various filters, such as Lua Filter and External Processing (gRPC) Filter. The gRPC filter can intercept request/response headers and bodies, allowing decryption before rate‑limiting and encryption after response processing.

3.2 Filter Execution Order

Filters execute top‑down on the request path and bottom‑up on the response path. A typical flow is: Lua pre‑processing → gRPC decryption filter → business logic → gRPC encryption filter → Lua post‑processing.

4. Conclusion

Adding an intermediate encryption layer solves many security challenges but introduces additional resource overhead and operational complexity. Merging this layer into the gateway (single‑layer design) unifies monitoring, logging, and alerting, offering a more efficient and cloud‑native solution.