Differences Between SOA and Microservice Architecture, ESB vs API Gateway, and Dubbo Best Practices

1. Differences between SOA architecture and microservice architecture

SOA (Service Oriented Architecture) is a design method that groups multiple independent services, each running as a separate process and communicating over the network, whereas microservices build on SOA by emphasizing complete componentization and service‑orientation of business capabilities, splitting a monolithic system into many small, independently deployable applications.

Microservice architecture can be seen as 80% SOA ideas + 100% componentization + 80% domain modeling.

2. ESB and microservice API gateway

ESB (Enterprise Service Bus) acts as a pipeline that connects various service nodes, handling protocol conversion, message routing and transformation to enable heterogeneous systems to interoperate.

API Gateway is a single entry point server that encapsulates internal architecture, providing customized APIs for clients and handling cross‑cutting concerns such as authentication, monitoring, load balancing, caching, request throttling, and static response handling.

3. Characteristics of SOA architecture

System integration : organizes scattered enterprise systems into a manageable star‑topology, often requiring products like ESB and governance standards.

Service‑orientation : abstracts business logic into reusable services for rapid composition and reuse.

Business service‑orientation : abstracts enterprise functions into services to improve external service capability and efficiency.

4. Characteristics of microservice architecture

1. Componentization via services

Developers no longer need to coordinate deployments of other services.

2. Business‑capability‑driven service and team boundaries

Teams can choose technologies freely and expose APIs.

3. Decentralization

Each microservice owns its own database.

Services cannot directly access other services' databases; interactions go through service calls.

Complex transactions spanning multiple databases must be coordinated via service orchestration.

Different services may use different database technologies (SQL, NoSQL, etc.).

4. Infrastructure automation (DevOps, automated deployment)

Unlike monolithic Java EE EAR deployments, microservices are packaged as independent services, often containerized with Docker, deployed autonomously, communicate via lightweight HTTP APIs, and are managed centrally for DevOps scalability.

5. Main differences (illustrated)

6. Dubbo service best practices

Package separation

Place service interfaces, request models, and exception definitions in a dedicated API module for reuse.

Include Spring configuration references in the API module when appropriate.

Granularity

Design coarse‑grained interfaces where each method represents a complete business function to avoid distributed transactions.

Group related business scenarios into a single interface and avoid overly generic generic‑type interfaces.

Versioning

Define a version for each interface (e.g., Maven snapshot) and prefer two‑digit versions; third digit is used only for incompatible changes.

When upgrading incompatibly, roll out the new version gradually across providers and consumers.

Pre‑release environment recommendations

Configure consumer‑side properties (timeout, retries, thread pool size, load‑balance) on the provider side.

Assign multiple owners to the application for monitoring visibility.

Maintain registry and provider lists in Dubbo cache files.

References

http://www.uml.org.cn/zjjs/201708083.asp https://zhidao.baidu.com/question/1899225333752310100.html http://blog.sina.com.cn/s/blog_493a84550102wq50.html