Traffic Planning and Transparent Multi-Level Routing: Network Request Process, Frontend/Backend Component Combinations, LB Load Systems, and VIP/RIP Mapping

Introduction – Modern enterprise or internet systems require traffic planning to achieve transparent multi‑level routing. The flow from client to server passes through non‑functional components such as client cache, DNS, transport links, CDN, load balancer, and server cache, providing high‑availability and high‑concurrency benefits.

1. Network Request Process

1.1 General Request Process – Diagram of a typical request (see Image 1).

1.2 Terminology

RIP: Real IP (virtual machine or container IP)

VIP: Virtual IP, not cross‑datacenter, allocated online, provides load‑balancing and health‑check functions; includes public VIP and internal VIP.

Internal network: Within a datacenter, strict firewall policies, internal VIP enables load‑balancing for inter‑application traffic.

Office network: Personal computers in office area accessing internal applications via reverse proxy.

Public network: Internet users accessing internal applications through DNS + public VIP.

1.3 Front‑end Network Component Pairing – External access architecture: VIP → jen‑nginx (proxy) → static applications (1‑N). Images 2 and 3 illustrate multiple front‑end project architectures.

1.4 Back‑end Network Component Pairing – Back‑end calls are either HTTP or JSF. Typical flow: Front‑end app —(HTTP/HTTPS)—> back‑end front‑proxy —(JSF private protocol)—> JSF microservice. Load distribution between front‑proxy and JSF service is usually handled by the consumer.

2. LB Load System Overview

VIP itself is just an IP; the real traffic splitter is the LB load balancer.

Two load‑balancing rules:

Default rule: domain‑based, directs traffic to a backend cluster.

Dedicated rule: VIP‑based, assigns a specific backend cluster to a VIP (higher priority).

Table compares commonalities and differences of the two rules.

2.1 Default Rule – Unique mapping of domain + port + cluster.

2.2 Dedicated Rule – Unique mapping of VIP + port + cluster; a VIP can have multiple ports (e.g., HTTP 80/443, TCP 2000‑2014).

3. VIP and RIP Mapping (Important)

Mapping relationships:

One‑to‑one: one datacenter, one VIP ↔ one RIP.

One‑to‑many: one datacenter, one VIP ↔ multiple RIPs.

Many‑to‑many: multiple datacenters, each VIP ↔ multiple RIPs within that datacenter.

Guidelines: keep VIP‑RIP mapping within the same datacenter to limit impact scope and simplify network outage drills.

4. Internal Domain Name Resolution

VIP is used as the datacenter entry point.

All views must resolve to an online‑available VIP.

Prefer the VIP of the local datacenter for intra‑datacenter traffic.

Legacy datacenters should prefer their own VIPs; overseas apps use overseas VIPs.

5. Public Domain Name Resolution

POP (Point of Presence) is the network edge entry point. New applications should request a POP‑associated VIP. Resolution steps:

Apply for POP entry VIP in advance.

Test VIP availability offline via host binding.

Configure DNS according to the operator’s POP VIP.

When no VIP is needed, use the public IP directly.

6. Summary

The simplest request process is the most practical; use straightforward, well‑tested component pairings to achieve traffic distribution without adding unnecessary complexity.