Fundamentals of Backend Infrastructure for Java Applications

1.1 Backend Infrastructure

The purpose of using Java backend technologies is to build business applications that provide online or offline services. The required technologies and underlying infrastructure determine which backend skills are essential. The diagram below outlines the indispensable backend components.

Backend infrastructure refers to the critical components or services that an application depends on to run stably online. Properly built infrastructure can support business for a long period, while many system services (load balancing, automated deployment, security, etc.) lie outside the scope of this chapter.

1.1.1 Unified Request Entry – API Gateway

Mobile app backends often need load balancing, API access control, and user authentication. A common approach is to use Nginx for load balancing and implement access control and authentication within each service, or encapsulate them into a shared library.

A more maintainable solution is to integrate these features into an API gateway service, which can be built in‑house or adopted from open‑source projects such as Kong or Netflix Zuul.

Because every request passes through the gateway, it can become a performance bottleneck. An alternative is to remove the gateway and let applications directly interact with a unified authentication center, optionally caching authentication results to reduce load.

1.1.2 Business Applications and Backend Frameworks

Business applications are divided into online (high traffic, low fault tolerance) and internal (high confidentiality, lower traffic) types. Java backend development typically relies on the following frameworks:

MVC frameworks (Spring MVC, Jersey, JFinal, WebX) for unified development flow.

IOC containers (Spring) for dependency injection.

ORM tools (MyBatis, Spring JDBC Template) for database access, with sharding solutions such as TDDL or Sharding‑JDBC.

Cache wrappers (Spring RedisTemplate, Jedis) for Redis/Memcached.

Performance monitoring libraries (JWebap) for request‑level metrics.

These components together form the skeleton of a typical backend service.

1.1.3 Cache, Database, Search Engine, Message Queue

These four foundational services directly affect overall application performance.

Cache: Redis (dominant) and Memcached to offload hot data from databases.

Database: Relational (MySQL, PostgreSQL) and NoSQL (MongoDB, HBase) options.

Search Engine: Solr and Elasticsearch (based on Lucene) for full‑text and dimensional queries.

Message Queue: Kafka for high‑throughput, RabbitMQ for reliable transactions; ZeroMQ as a lightweight pattern library.

1.1.4 File Storage

File storage must guarantee reliability, disaster recovery, and stability. Solutions range from traditional RAID to distributed systems like HDFS, NFS, or Samba. When storage becomes a bottleneck, SSDs are the most straightforward upgrade.

1.1.5 Unified Authentication Center

Provides registration, login verification, token authentication, and internal system user management, enabling single sign‑on across multiple apps.

1.1.6 Single Sign‑On (SSO) System

SSO allows a single login to access multiple applications. The open‑source CAS project (https://github.com/apereo/cas) is a widely used solution.

1.1.7 Unified Configuration Center

Manages configuration files (Properties, YAML, HOCON) centrally, supporting dynamic updates, environment segregation, and Java‑side injection via annotations or XML. Open‑source options include Baidu’s Disconf, Ctrip’s Apollo, often backed by Zookeeper.

1.1.8 Service Governance Framework

Internal service calls typically use RPC protocols such as RMI, Hessian, Thrift, or Dubbo. A governance framework registers providers/consumers, handles versioning, load balancing, traffic control, fault tolerance, and circuit breaking. Dubbo (now Apache) and Netflix Eureka + Ribbon are popular choices.

1.1.9 Unified Scheduling Center

Centralizes task scheduling (Cron expressions, dynamic modifications, sharding, workflow). Implementations include Quartz, Cron, Azkaban, Yahoo Oozie, and elastic‑job for elastic resource utilization.

1.1.10 Unified Logging Service

Collects logs from all services via a dedicated logging server. Implementations can extend Log4j or Logback with custom appenders and transmit logs via RPC.

1.1.11 Data Infrastructure

Distinguishes between offline (Hadoop, Spark) and real‑time (Storm, Spark Streaming, Flink) analytics. Discusses ROLAP vs. MOLAP solutions (Druid, Pinot, Kylin) and the importance of handling data skew.

1.1.12 Fault Monitoring

System monitoring (CPU, memory, disk) can use Nagios, Cacti, or cloud services; distributed cluster monitoring may use Ganglia, OpenFalcon, or custom solutions. Business monitoring tracks PV/UV, transaction failures, and requires instrumentation in code.

Alerting should include machine IDs, aggregation, severity levels, and can leverage WeChat for cost‑effective notifications.

Post‑mortem analysis relies heavily on log aggregation platforms such as ELK (Elasticsearch, Logstash, Kibana) with Elastalert for alerts, or distributed tracing systems like Zipkin, SkyWalking, Pinpoint, and Spring Cloud Sleuth.

To conclude, the article encourages readers to share the content, join the architect community, and continue advancing their backend engineering skills.