Understanding Why Microservice Architecture and Service‑Oriented Design Matter

1. Understanding Microservice Architecture

1.1 What is Microservice Architecture

Microservice architecture adds the notion of “micro”. Amazon loosely defines a microservice project as a team of 6‑8 people that can finish a pizza together.

It is not merely a collection of Service classes packaged as a service; overly fine‑grained splitting can lead to huge operational costs, as seen in a large financial company in Hangzhou.

1.2 Why Do We Need Microservices?

Transitioning from SOA to microservices addresses several common problems in traditional enterprise systems:

Poor scalability

Low reliability

High maintenance cost

Duplicate functionality

Solutions include componentization and service‑orientation, which decouple the system by distributing components into independent services.

Componentization means breaking a large system into independent components based on technical or business dimensions (e.g., search component, cache component, user center, payment center) to achieve reuse and reduce coupling.

Alibaba’s “big middle platform, small front‑end” concept pushes componentization, plug‑in, and service‑orientation to the extreme, forming technical and business middle platforms.

2. Problems Before Service‑Orientation

2.1 Lack of Service‑Orientation Is Not the Same as Distributed or Clustered Systems

Distributed systems provide multiple instances of the same service, while service‑orientation focuses on communication between distinct services, involving registration, publishing, invocation, monitoring, load balancing, etc.

2.2 Issues Without Service‑Orientation

Consider ticket‑related services (ticketing, purchase, seat change) that each need to verify user identity by directly accessing the user database. Problems arise:

Code duplication – each service implements its own user‑DAO logic.

Low maintainability – changes to DB schema require updates in every service.

Database coupling.

Using a shared library (user‑DAO‑lib) solves duplication but introduces new challenges: library upgrades are costly and error‑prone.

Service‑orientation can solve these issues by centralizing functionality behind a service interface.

3. Benefits After Service‑Orientation

Database isolation – underlying storage details are hidden from callers.

Service‑to‑service communication via RPC/HTTP, etc.

Simplified calls – no need to duplicate user‑service code.

Code reuse through communication rather than shared libraries.

Business isolation.

Database decoupling.

Other advantages.

4. New Challenges Introduced by Microservices

1) Small or simple systems may not need microservices; the added complexity requires a full service‑governance solution. 2) Multiple module databases make distributed transactions challenging. 3) Development processes become more complex with added testing requirements.

Every benefit has a corresponding cost; the choice depends on the specific scenario.

5. Summary

The article focuses on the “why” rather than the “how”. Understanding the reasons for service‑orientation and the popularity of microservice architecture reveals benefits such as high scalability, reliability, lower maintenance cost, reduced duplication, simple calls, business isolation, and database decoupling.

Reference:

Internet Architecture – Why Service‑Orientation? https://mp.weixin.qq.com/s/S6ga8y88qaAjbKjuKMrowQ

https://zh.wikipedia.org/zh-sg/%E5%BE%AE%E6%9C%8D%E5%8B%99