Comprehensive Overview of Internet Company Technical Architecture: DNS, Load Balancing, API Gateway, Push, and Microservices

Overall Architecture

APP, PC, and third‑party callers obtain the load balancer IP via traditional LocalDNS or real‑time HttpDNS, then reach a unified access layer that maintains long connections. The API gateway serves as the entry point for microservices, handling protocol conversion, routing, authentication, traffic control, and caching. Business servers use a PUSH system for real‑time notifications (e.g., IM, alerts) and communicate with each other via a proprietary RPC protocol, while a NAT gateway accesses external third‑party services.

Domain Name Resolution

Traditional DNS

DNS (Domain Name System) is a distributed directory service that maps domain names to IP addresses, allowing users to access resources without remembering numeric IPs.

The resolution process involves the client recursively querying a LocalDNS (typically provided by the ISP) to obtain the IP, followed by iterative queries to retrieve the authoritative DNS server addresses.

HttpDNS

HttpDNS uses HTTP requests to DNS servers, avoiding ISP LocalDNS and mitigating domain hijacking and cross‑network access issues, thereby improving reliability for mobile internet services.

Compared with operator LocalDNS, Tencent Cloud HttpDNS offers advantages in speed, security, intelligence, and reliability, as shown in the table below.

Advantage

Tencent Cloud HttpDNS

Operator LocalDNS

Speed

Coverage of top 17 domestic operators, Southeast Asia, and North America; precise resolution and fast access.

Cross‑network access and resolution anomalies.

Security

Avoids operator LocalDNS, preventing hijacking and DNS pollution.

Results may be redirected to ad pages or third‑party ads.

Intelligence

Accurately identifies request source and directs traffic to the optimal node.

Simply forwards requests to other operators without recursion.

Reliability

Three‑site cluster redundancy with sub‑second failover, providing >99% SLA.

Inconsistent cache server maintenance leading to occasional failures.

Load Balancing

To address single‑machine performance limits and single‑point failures, load balancing horizontally distributes traffic across multiple servers, performing health checks and dynamically removing faulty nodes.

Solutions include hardware (e.g., F5) and software (LVS, NGINX, HAProxy). Load balancers operate at L4 (transport layer) or L7 (application layer).

L4 vs L7

L4 load balancing forwards packets based on transport‑layer information (e.g., TCP SYN) to selected servers, ensuring subsequent packets follow the same path.

L7 load balancing acts as a proxy, establishing a full connection with the client, parsing the application request, and then forwarding it to a chosen backend server.

LVS Forwarding Modes

LVS (IP load balancing) supports DR (Direct Routing), NAT, TUNNEL, and FULL NAT modes.

DR Mode (Direct Routing): rewrites the MAC address and forwards the request to the real server, which replies directly to the client. Requires the scheduler and real servers to share a physical network segment and configure a VIP.

NAT Mode (Network Address Translation): the scheduler rewrites the destination address to the real server; responses are rewritten back to the client, allowing the scheduler to function as a gateway.

TUNNEL Mode : the scheduler forwards the request via an IP tunnel to the real server; the real server replies directly to the client. Real servers must support tunneling and VIP configuration.

FULL NAT Mode : performs source NAT (SNAT) on top of NAT, ensuring response traffic passes through the load balancer, which simplifies network topology but hides the client’s real IP.

Scheduling Algorithms

Round Robin : distributes requests sequentially across servers, ignoring load.

Weighted Round Robin : assigns higher probability to servers with larger weights, useful for heterogeneous server capacities.

Least Connections : directs traffic to the server with the fewest active connections, balancing load when servers have similar performance.

Hash : maps a request key to a server using a hash modulo operation.

Consistent Hash : minimizes remapping when servers are added or removed, improving stability in distributed environments.

API Gateway

The API gateway is a clustered entry point that abstracts internal architecture and provides REST/HTTP APIs, handling authentication, monitoring, load balancing, caching, and traffic control.

API Management

Core functions include full lifecycle management (creation, maintenance, publishing, deprecation), multi‑environment testing, versioning, and rollback.

Configuration consists of front‑end (HTTP method, URL, parameters) and back‑end (service name, parameters) settings, enabling seamless translation from client requests to microservice calls.

Asynchronous Processing

By leveraging non‑blocking I/O and multiplexing (e.g., Netty+NIO, Tomcat/Jetty+NIO, Spring WebFlux), the gateway can handle massive concurrent traffic with minimal threads, boosting throughput and reducing costs.

Chain Processing

Implemented via a filter chain (responsibility‑chain pattern), providing routing, protocol conversion, caching, rate limiting, monitoring, and logging. Extensions should avoid time‑consuming operations.

Spring Cloud Gateway Workflow

Gateway receives client request.

Request matches routing rules.

Pre‑filters modify request (e.g., headers).

Request is forwarded to downstream service.

Post‑filters process the response.

Gateway returns response to client.

Rate Limiting

Protects the system from overload by limiting traffic at cluster, service, or API level. Implementations include cluster‑wide Redis storage or single‑machine in‑memory storage (recommended). Common algorithms: counter, leaky bucket, token bucket (recommended).

Circuit Breaking and Service Degradation

Service Circuit Breaker : when downstream services become unavailable or slow, upstream services stop calling them and return quickly, preserving resources; automatic recovery occurs when the target service recovers.

Service Degradation : under high load, non‑critical services can be degraded (e.g., return cached data) to ensure core service availability. Degradation granularity can be API, feature, or system level, requiring prior SLA definition.

Business Isolation

To prevent cross‑impact between business logic, isolation can be achieved via thread‑pool or cluster isolation; cluster isolation is preferred for Java due to thread overhead.

PUSH Notification System

The push system supports multiple channels (Apple, Huawei, Xiaomi, FCM) and provides both console‑driven and server‑side integration for real‑time user engagement, improving retention and experience.

Workflow includes device connection, registration, user binding, message persistence, push attempts via third‑party or custom TCP channels, acknowledgment handling, and retry on failure.

Microservice Architecture

A diagram illustrates the microservice ecosystem, highlighting service registration, discovery, and inter‑service communication.

--- End of technical content ---