<微服务设计>1.3节：SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式。 

通俗易懂的讲SOA 

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

比如现在有一个数据库，一个JavaWeb网站客户端，一个IOS客户端，一个安卓客户端。

现在我要从这个数据库中获取用户注册列表，如果不用SAO设计理念，那么就会这样：JavaWeb端网站里面写一个查询方法从数据库中获取数据然后现在在网页上，IOS客户端里面也写一个查询方法获取数据显示，IOS也是这样。弊端就是，三个地方都有相同的业务代码，如果要改的话，就要改三个地方，而且改的一模一样，当然，问题可能不止这一个。

于是乎，出现了这样的设计思想，比如用Java(或者其他语言皆可)单独创建一个工厂部署在一台单独的服务器上，并且写一个方法执行查询用户注册列表这个操作。然后其他人通过某种途径(可以是http链接或者是基于socket的RPC)访问这个方法返回数据，返回的数据类型可以是xml，也可以是json。简单来说，就是把这个操作封装到一个工程当中去，然后暴露访问的方式，形成"服务"。所有增删改查都通过这个服务进行。

这样一来，JavaWeb可以访问这个服务，IOS和安卓客户端也可以访问这个服务。更重要的是如果要修改注册业务的方法，只要改这个服务就可以了。同理，其他业务，比如订单，广告都可以单独形成服务部署在单独的服务器上。

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

当然，好处肯定不止这些。

以上的描述还不能完全称为SOA，还不够完成，因为还缺少了服务治理这一环节。

什么是服务治理，就是当服务越来越多，调用方也越来越多，他们之间的关系就变得非常混乱，需要对这些关系进行管理。还是上面的例子，一个用户服务，后来有上百个调用方，这个时候作为服务方，它只提供服务，却不知道为谁提供了服务。对于开发者来说，知道这N多服务方之间的关系非常重要。所以这个时候就需要服务治理的框架，比如dubbo+zookeeper，比如Spring Cloud，有了服务治理功能，我们就可以清晰的看到服务被谁调用了，谁调用了哪些服务，哪些服务是热点服务，需要配置服务器集群，而对这个服务器集群的负载均衡也是服务治理的可以完成的重要功能之一。

这个时候就是更加完善一点的SOA了，当然，还可以更进一步，加上服务监控跟踪等等。