SOA, or service-oriented Architecture, is an architectural style. It can be confusing to take SOA literally, so let’s look at a real world scenario to understand what SOA really is.

SOA is simple to understand: it is to divide the system into functional modules that can be deployed independently according to the actual business requirements. It can also be called a separate project. Modules or projects call each other to fulfill the actual needs of different modules.

Scenario description: there is one database, one JavaWeb client, one Android client, and one IOS client.

Now I’m going to get a list of registered users from this database. Without SOA design ideas, the implementation steps look like this:

  • JavaWebWrite a query that looks up data from the database and displays it on the web;
  • AndroidClient inside write a query method after the query inAppOn display;
  • IOSThe same is true.

There are many disadvantages of the above implementation ideas:

  • The query method appears repeatedly;
  • All three places have the same business code;
  • One modification, others also need to be modified and so on.

Hence the SOA design idea, such as creating a single project in Java (or any other language) and deploying it on a server, writing a method to perform these queries, and then enabling others to do so in some way (HTTP links, perhaps, Or a socket-based RPC call) returns json or XML data. That is to say, encapsulate the operation into a project and then expose the access to form a “service”. This is the registered user service, and this service provides methods for all related add, delete, change and check operations of registered users.

This way, the JavaWeb side can access the service and get the data to use, and Android and IOS side can get the data from the service. Most importantly, to change the business about registered users, you just need to change the service, which is very decoupled. Similarly, other services, such as goods, can be deployed as separate services on the server.

Still have even if one day suddenly have a bunch of people who want to register, assume that people just registered and not do other things, other businesses such as goods, advertising services, such as all need not, only registered this feature a lot of pressure, and the original has a registration service server already cannot afford such a high concurrency, can deploy this registration service at this time, Provide a few more servers to provide registration services, while other services remain intact.

What is described above cannot be fully called SOA, because service governance is missing. Service governance is when there are more and more services and more and more callers, the relationships between them become very chaotic and need to be managed.

For example, let’s say I have a user service, and I have caller 1 and caller 2 using the service, and then more and more, almost hundreds of callers, at this point, as a service provider, it only knows that it provides the service, but it doesn’t know who it provides the service for. It is important for developers to know the relationship between N callers and N servers.

Therefore, we need a service governance framework, such as Dubbo+ZooKeeper and SpringCloud. With the service governance function, we can clearly see who calls services, who calls which services, which services are hot services, and need to configure the cluster. The load balancing of this service cluster is also one of the important functions that service governance can accomplish. This is where SOA gets a little more polished. Of course, you can go one step further and add service monitoring tracking and so on.

In fact, SOA is just an architectural pattern from which SOAP, REST, and RPC are derived specifications:

SOAP is HTTP + XML;

REST is HTTP + JSON;

RPC is based on sockets.

Dubbo is a typical RPC framework, while SpringCloud is a REST compliant microservices framework.