Differences Between SOA and Microservice Architecture and Dubbo Best Practices

1. Differences Between SOA and Microservice Architecture

SOA (Service Oriented Architecture) is a design method that consists of multiple independent services communicating over a network, while microservice architecture builds on SOA by emphasizing complete componentization and service‑orientation of business capabilities.

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 connecting various service nodes, handling protocol translation, message routing, and integration of heterogeneous systems.

API Gateway: Serves as the single entry point for clients, similar to the Facade pattern, encapsulating internal architecture, providing customized APIs, and handling authentication, monitoring, load balancing, caching, request splitting, static responses, etc.

All client requests go through the gateway, which manages non‑business concerns and registers services for REST/HTTP access.

3. Characteristics of SOA Architecture

System Integration: Organizes disparate enterprise systems into a manageable star‑topology, often using products like ESB and standardized service management.

System Service‑orientation: Abstracts business logic into reusable, composable services for rapid business regeneration.

Business Service‑orientation: Turns enterprise functions into reusable services, enhancing external service capability and efficiency.

4. Characteristics of Microservice Architecture

1. Componentization Through Services

Developers no longer need to coordinate deployments of other services that affect theirs.

2. Business‑Capability‑Based Service and Team Division

Developers can freely choose technologies and provide API services.

3. Decentralization

Each microservice has its own private database for persisting business data.

Microservices can only access their own databases.

Cross‑database transactions are handled via service calls, not direct DB access.

Data decentralization reduces coupling and allows different database technologies (SQL, NoSQL) per service.

4. Infrastructure Automation (DevOps, Automated Deployment)

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

5. Main Differences (Illustrated)

6. Dubbo Service Best Practices

Packaging

Place service interfaces, request models, and exception definitions in an API module to follow reuse and publishing equivalence principles.

Include Spring configuration references in the API module or appropriate package.

Granularity

Design interfaces with coarse granularity; each method should represent a distinct functionality to avoid distributed transaction complexities.

Group interfaces by business scenarios and abstract related business to prevent interface explosion.

Avoid overly generic interfaces with ambiguous semantics.

Versioning

Define a version for each interface to support future compatibility (e.g., Maven snapshot).

Prefer two‑digit version numbers; the third digit indicates incompatible upgrades.

When introducing incompatible changes, roll out the new version gradually across providers and consumers.

Pre‑Release Environment Recommendations

Recommended Practices

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

Configure Administrator Information

Set multiple owners in the application configuration so they can view monitoring data.

Configure Dubbo Cache Files

Register center list.

Service provider list.

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