如何通俗易懂地解释什么是SOA？

对于SOA，感觉这个概念性的东西没那么容易理解，看了各位大神的解释感觉很多都说的很抽象，所以想尝试用自己的语言解释下，仅做参考。

SOA粗暴理解：把系统按照实际业务，拆分成刚刚好大小的、合适的、独立部署的模块，每个模块之间相互独立。

比如现我有一个数据库，一个JavaWeb（或者PHP等）的网站客户端，一个安卓app客户端，一个IOS客户端。

现在我要从这个数据库中获取注册用户列表，如果不用SOA的设计思想，那么就会这样：JavaWeb里面写一个查询方法从数据库里面查数据然后在网页显示，安卓app里面写一个查询方法查询后在app上显示，IOS同样如此。这里就会出现查询方法重叠了，这样的坏处很明显了，三个地方都有相同的业务代码，要改三个地方都要改，而且要改的一模一样。当然问题不止这一个。

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

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

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

当然，还有很多其他好处。

以上我所描述的就是基本的SOA思想了，按照业务功能将本来一整块的系统拆分为各个不同的子系统分别提供不同的服务，服务之间通过接口相互调用。这就是所谓的“面向服务的架构”。

后来又有了微服务的概念，个人理解微服务和SOA就是孪生子。如今生产实践中提到的微服务，在SOA的基础上更进一层，引入了很多新的东西如服务治理、链路跟踪、配置管理等等可以帮助企业构建高可用高并发高性能的系统的组件。

什么是服务治理，就是当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱，需要对这些关系进行管理。举例，还是上面的例子，假如我有一个商家服务，一开始有购物车服务和订单服务来使用这个服务，后来越来越多其他服务需要调用该商品服务，将近上百个调用方，这个时候作为服务方，它只知道提供服务，却不知道具体为谁提供了服务，并且这个商家服务不但是服务提供者角色，它自己也是服务调用者，比如它可能需要调用商品服务、用户服务器等等。而对于开发者来说，知道这N多调用方和N多服务方之间的关系是非常重要的。

以Java开发为例，现在最流行的微服务框架如：Dubbo、SpringCloud，都有服务治理的功能，这样就能清晰地看到服务被谁谁谁调用，谁谁谁调用了哪些服务，哪些服务是热点服务需要配置服务器集群。此外，通过一些负载均衡组件如SpringCloud的Ribbon，服务集群的负载均衡也帮你搞定了，调用的时候只要指名服务名称，请求时会帮你完成负载均衡把请求打到集群中某台较空闲的服务器上，也是服务治理可以完成的重要功能之一。

当然，还可以更进一步，加上服务监控跟踪等等等等之类的。

实际上SOA只是一种架构设计模式，而SOAP、REST、RPC就是为了实践这种设计模式而设计的数据通讯方式，其中SOAP通俗理解就是服务间通过http+xml的形式完成数据交换，REST就是http+json的形式，RPC是基于socket的形式。CXF框架就是典型的SOAP/REST框架，Dubbo就是典型的RPC框架，而SpringCloud就是遵守REST规范的微服务生态系统。