SOA，即面向服务的架构，是一种架构风格。从字面意思理解，容易让人一头雾水，那么，我们从实际场景分析，来理解到底什么是SOA。

SOA简单理解：就是把系统按照实际业务需求，拆分成可以单独部署的功能模块，也可以称为是单独的工程，模块或工程之间互相调用以完成不同模块的实际需要。

场景说明：现有一个数据库，一个JavaWeb网站客户端，一个Android客户端，一个IOS客户端。

现在我要从这个数据库中获取注册用户列表，如果不用SOA的设计思想，实现步骤是这样的：

JavaWeb里面写一个查询方法从数据库里面查数据然后在网页显示；
Android客户端里面写一个查询方法查询后在App上显示；
IOS同样如此。

上述实现思想存在着很多缺点：

查询方法重复出现多次；
三个地方都有相同的业务代码；
一处修改，其他也要修改等问题。

于是出现了SOA的设计思想，比如用Java（或者是其他语言）单独创建一个工程部署在一台服务器上，并且写一个方法执行上述查询操作，然后使其他人可以通过某种途径（可以是http链接，或者是基于socket的RPC调用）访问这个方法得到json或者xml类型的返回数据。也就是说把这个操作封装到一个工程中去，然后暴露访问的方式，形成“服务”。这里就是注册用户服务，而关于注册用户的所有相关增删改查操作这个服务都会提供方法。

这样一来，JavaWeb这边可以访问这个服务然后得到数据使用，Android和IOS这里也可以通过这个服务得到数据。最重要的是，要修改关于注册用户的业务只要修改这个服务就好了，可以实现很好的解耦。同理，其他业务比如商品等其他业务都可以单独形成服务部署在服务器上。

还有就是如果哪天突然有一堆人要注册，假设这堆人仅仅只是注册而不做其他事情，其他业务比如商品、广告服务等都不用，唯独注册这个功能压力很大，而原有的一台部署了注册服务的服务器已经承受不了这么高的并发，这时候就可以集群部署这个注册服务，多提供几台服务器提供注册服务，而其他服务维持原样。

以上所描述的还不能完全称为SOA，因为这里少了服务治理这一环节。服务治理，就是当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱，需要对这些关系进行管理。

举例，还是上面的例子，假如我有一个用户服务，一开始有调用方1和调用方2来使用这个服务，后来越来越多，将近上百个调用方，这个时候作为服务方，它只知道提供服务，却不知道具体为谁提供了服务。而对于开发者来说，知道这N多调用方和N多服务方之间的关系是非常重要的。

所以这个时候就需要能进行服务治理的框架，比如Dubbo+ZooKeeper、SpringCloud，有了服务治理功能，我们就能清晰地看到服务被谁调用，谁调用了哪些服务，哪些服务是热点服务，需要配置集群，而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。这个时候就是更加完善一点的SOA了。当然，还可以更进一步，加上服务监控跟踪等之类的。

实际上SOA只是一种架构模式，而SOAP、REST、RPC就是根据这种架构模式衍生出来的规范：

SOAP就是http+xml的形式；

REST就是http+json的形式；

RPC就是基于socket的形式。

Dubbo就是典型的RPC框架，而SpringCloud就是遵守REST规范的微服务框架。