基于项目，微服务和服务（在 SOA 中）可以是同一个东西吗？

Question

There are many sources that explain microservices and SOA. But the problem is none of them make side-to-side comparisons for the same real-life scenario. Let's assume that we're working on a centralized cryptocurrency exchange.

Parts of this project:

• User service (Authentication & Authorization, user profiles, etc.)
• Wallet service (Balances, transfers, etc.)
• Trading service (Orders, favorite pairs, etc.)
• Matching service (Matching buyers and sellers)
• Live Data Service (Tickers, open positions, etc.)

These are the most important parts of the system. How can we call this architecture? Microservices or SOA? Because all of these parts can be named as a microservice or service.

Is the difference between microservices and SOA just about the communication between these or about the sharing same database or having its own data?

Answer 1

Indeed in first glance these 2 approaches sound very similar, but when you look into it, there are a few key differences, mostly in terms of the services' scope - in microservices the services are very granular, each one of them has a single purpose. In contrast, in SOA the granularity of the services can vary.

Of course there are more differences, I'd recommend to read this article in DZone (which I recommend in general for architecture topics).

Answer 2

The long and short of it is that it doesn't matter

the point is you want/need to build the business as composition of autonomous (as possible) components. You also want to have clear boundaries so you won't get a knot of a distributed monolith on one end and a micro-services-death-star filled with nano-services on the other.

Personally I'd like to distinguish between service where the logical boundaries exists and reasons to build separate executables that are actually just different aspects of a service (but maybe have different scale requirements). You can see for example, how netflix went this way in their third generation of architecture

but in any event the point is to provide agility and speed in answering changing business requirements. the service/micro-service principles are there to help you build the components better and the exact naming is a much lower concern.