Comparison with Traditional Architecture
Introduction
In this section, we compare traditional architecture with ionet architecture. We selectively focus on several points rather than covering everything, because the more dimensions we compare, the more drawbacks traditional architecture exposes.
Traditional Architecture
In traditional architecture, the external server part is usually called a gateway (or player gateway). To keep understanding straightforward, we continue using ionet's term "external server" here.
Traditional architectures are usually directly interconnected. As shown in the diagram, each logic server needs connections with other logic servers for inter-service communication.
Due to limited space, the figure only shows 4 logic servers and 1 external server, yet the lines are already quite messy. Since traditional architecture requires mutual interconnection, the actual number of connections = N * (N-1). For convenience, we refer to this as the N*N problem below.
N * N Problem
As we can see, traditional architecture introduces the N*N problem. Here are other issues caused by it.
Connectivity
Assume we have 1,000 logic servers. Internal connections alone reach 1000*1000=1,000,000. Yes, one million internal connections. What about 10,000 logic servers? That is roughly 100 million internal connections.
Heartbeat Overhead
To detect connection liveness, heartbeats are required, including heartbeat requests and responses. So the per-cycle heartbeat handling count becomes 2*N*N between connections.
Even before considering anything else, heartbeat overhead is already huge. With 10,000 logic servers (about 100 million internal connections), even doing nothing else consumes about 200 million heartbeat operations per cycle (request + response).
As external servers and logic servers increase, total internal connections grow at a terrifying rate.
Middleware Dependency
In addition, you typically need many third-party middleware components that must be installed, such as Redis, MQ, ZooKeeper, and more, to keep the architecture running. Once you introduce install-required middleware, your architecture/framework is basically no longer lightweight.
Many developers cannot clearly judge whether an architecture/framework is lightweight. Some even use code size as the criterion. Spring has a large codebase, but to be clear: Spring is still a lightweight framework.
You might ask: Spring-Data often requires MySQL, MongoDB, Redis, etc., so why is Spring still called lightweight? First, Spring-Data is only a subproject of Spring. Second, those dependencies are introduced by business needs, not forced by Spring itself.
Whether an architecture/framework is truly lightweight depends on whether it relies on independently installed middleware.
You might still say: "If I do not install them, then it's lightweight." That statement is logically fine, but as your business grows, installing middleware becomes inevitable in traditional architecture by design.
Operations and Management
You must allocate an independent port for each logic server.
Using 10,000 logic servers as an example, you need to manage tens of thousands of ports.
Each time a new logic server goes online, it must fetch all logic-server ip:port entries from a registry center and establish connections.
If you use cloud servers, do not forget port opening/configuration, or other logic servers cannot connect. This small step often wastes a lot of developer time.
Development Cost
For distributed development experience, most traditional architectures do not support starting multiple logic servers in one process. This makes debugging and troubleshooting difficult, reduces developer efficiency, and increases workload. As your business grows, development cost can grow very high.
For business development itself, because traditional services are mutually connected, the system becomes more chaotic as it grows, and business complexity rises implicitly.
Cost
When using traditional architecture, cost considerations include middleware installation, maintenance, learning, and deployment.
From a stability perspective, the more middleware you install and use, the more instability factors you introduce. You may even need to consider misuse by team members.
Advantage
Because servers are directly connected, only one transmission hop is needed.
ionet Architecture
Besides retaining traditional architecture advantages, ionet architecture avoids all traditional drawbacks. Most importantly, there is no N*N problem.
Lock-free asynchronous and event-driven architecture; truly lightweight. You can build a distributed network communication server without any third-party middleware.
Built-in load balancing, distributed support, and dynamic machine scale-out/scale-in.
| Name | Scaling Mode | Responsibility |
|---|---|---|
| ExternalServer | Distributed | Responsible for user connections and interaction |
| LogicServer | Distributed | Responsible for specific business logic processing |
From this architecture overview, we know the overall architecture consists of external services and logic services. They can run independently or be integrated together.
P * P
Here, P means process.
ionet architecture has no N*N problem, mainly because:
- Multiple external and logic servers can start inside one process.
- Logic servers communicate through reliable UDP without long-lived connections.
Connectivity
Because ionet internal communication uses reliable UDP and has no long-lived connections, regardless of whether you have 1,000 or 10,000 logic servers, no long-lived links are established between them.
Heartbeat Overhead
A process can contain multiple external and logic servers, so heartbeat handling between processes is 2*P*P per cycle. Because each process can contain multiple services, heartbeat overhead is almost negligible.
Middleware Dependency
For lightweight design, the framework supports distributed network communication without any third-party middleware, requiring only a Java runtime. This means simpler usage and lower enterprise deployment/maintenance costs. With ionet, one dependency gives you the full framework without installing extra services such as Nginx, Redis, MQ, MySQL, ZooKeeper, or Protobuf compiler tools.
Operations and Management
From a security perspective, logic servers do not need to expose ports, naturally reducing scan-attack risks.
In ionet, you do not need to allocate an independent port for every external or logic server.
Because you do not need one independent port per logic server, using cloud services no longer requires worrying about individual port-open permissions.
Do not underestimate this step; such details often consume the most developer time.
Since we do not need to manage these IP:Port entries, this workload naturally disappears.
Better Distributed Development Experience
In distributed development, multiple processes are usually required. This makes debugging and troubleshooting difficult, reducing developer efficiency and increasing workload. Many frameworks cannot solve this well, but ionet does. ionet supports running multiple services in a single process, making distributed system development and debugging much easier.
Cost
ionet supports distributed architecture without relying on any third-party middleware or databases. Only a Java runtime environment is required. This avoids the cost of middleware installation, maintenance, learning, and deployment.
Because we do not need to operate and maintain middleware, that part of workload naturally disappears.
Advantage
Logic servers communicate through IPC with no network request overhead.
See Why Fast
Summary
This section provided only a simplified comparison.
- From the comparison, traditional architecture is heavyweight, while ionet architecture is lightweight.
- Traditional architecture usually depends on many third-party middleware components to operate properly; the more middleware introduced, the higher the instability risk.
- Introducing install-required middleware brings installation, maintenance, learning, and deployment costs.
- Traditional architecture has the N*N problem. Even when doing nothing else, heartbeat traffic can consume substantial machine resources.
- Traditional logic servers require startup ports per machine. On cloud platforms, do not forget to open/configure relevant ports, or other logic servers cannot connect. This step often wastes a lot of developer time. In ionet, logic servers do not require this work, so that workload naturally disappears.
This comparison has not yet covered communication styles. ionet provides multiple communication mechanisms to simplify cross-process communication, and these mechanisms are extensible. With these rich options, almost any business scenario can be covered.