Why Switch to Java Spring Boot for Microservices? A Practical Exploration

Introduction to Microservices

Microservices are an architectural style where a large application is composed of small, loosely coupled services, each responsible for a single business capability. The concept traces back to Martin Fowler’s 2014 article.

Current Situation and Pain Points

At Huajiao, services are built with PHP, offering fast development but suffering from high coupling between service governance and business code, duplicated error codes, costly upgrades, slow scaling, and performance limits of the LNMP stack.

These issues motivate a shift toward a more mature Java‑based ecosystem such as Spring Cloud, which provides built‑in service registration, circuit breaking, gateways, and configuration management.

Existing Open‑Source Microservice Solutions

Alibaba: Dubbo (now Apache) and Spring Cloud Alibaba – a one‑stop solution still incubating.

Tencent: Tars – a high‑performance RPC framework with limited community activity.

Huawei: ServiceComb – Apache‑hosted, offering registration, discovery, and governance.

Spring ecosystem: Spring Boot and Spring Cloud – the most widely adopted Java stack.

Why Choose Spring Boot 2

Mature, stable, and backed by a large community.

Annotation‑driven development dramatically reduces configuration boilerplate.

Produces self‑contained JARs, eliminating the need for external web containers.

Seamless integration with Spring Cloud components (service registry, config server, etc.).

Actuator provides runtime health monitoring.

Easy to add third‑party HTTP or gRPC clients for cross‑language communication.

Data‑access layer: MyBatis is preferred over Hibernate for its lightweight nature and strong support via mybatis‑generator.

Web container: Undertow is selected for superior performance and lower footprint compared with Tomcat.

Code quality: Alibaba Java Coding Guidelines plugin enforces consistent style and detects potential issues.

Resulting stack :

springboot2 + mybatis + undertow packaged as a runnable JAR

Steady Improvement Plan

Maintain existing business while stabilizing the system by piloting changes on an “activity” project.

Project modules: activity‑java, activity‑core, common‑core, pepper‑client, pepper‑statistics, pepperbus‑client.

Architecture diagram:

CI/CD and Service Discovery Enhancements

Switch CI from Jenkins to GitLab, leveraging built‑in code review, automated pipelines, and Kubernetes integration.

Adopt Eureka or Nacos for service registration; discuss CAP trade‑offs (Eureka = AP, Zookeeper = CP, Nacos = hybrid).

Use OpenFeign with Hystrix for lightweight REST clients and circuit breaking.

Inject trace IDs via SLF4J MDC for future full‑stack observability.

Implement idempotency and concurrency control with annotations, Spring EL, and Redis.

Future Outlook: Service Mesh

Planned components: external gateway, Eureka registry, configuration center, logging service, service‑governance center, and Kubernetes‑based containerization.

Service Mesh provides a transparent sidecar proxy layer that decouples networking concerns (retries, timeouts, monitoring, tracing) from business code, similar to how TCP abstracted low‑level transport.

Key characteristics: application‑level communication middleware, lightweight proxies, zero‑awareness for apps, and unified handling of retries, timeouts, monitoring, tracing, and discovery.

Representative frameworks: first‑generation Linkerd and Envoy; second‑generation Istio and Conduit. Major Chinese tech firms (Ant Financial, Huawei, Tencent) have production‑grade Service Mesh deployments.

Reference links for deeper study (Spring Cloud, Istio, Service Mesh tutorials) are listed.