理解SOA

理解SOA

面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。
SOA是一种设计方法,其中包含多个服务,而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用,而非采用进程内调用的方式进行通信。

打个比方,开饭店普通饭店,第一桌10个人,点菜、做饭、上菜、结账…第二桌又来了20个人,点的菜有的和刚才10个人点的重复,也有不一样的,但是会出现这样一个问题,这20个人,除了小李和老王其他都不喜欢吃猪蹄,结果呢老王吃把菜点上了,结果最后剩下很多造成了浪费,而且因为店面人手不足的问题,如果出现一下来了好几拨人情况,会忙不过来.所以老板决定开自助餐厅,先不考虑客人想吃什么,在饭点之前先把各式各样的菜先烧好,你来10个人也好,100个人也好,自己真正喜欢吃什么,有什么需求自己去对应的位置拿菜。

面向服务的体系架构soa的来源
刚开始，每个系统都是独立的，功能简单，使用单一应用架构；
随着发展，业务需求增加，单一应用架构已不能支持业务体系的发展，于是产生了垂直应用架构体系。垂直应用架构体系解决了单一应用架构面临的扩容问题，流量可以分散到各个子系统中，且系统体积可控，提升了开发效率；
但是当垂直应用越来越多时，应用之间相互交互，相互调用，已避无可避。刚开始的做法是，不同系统之间存在重叠的业务，这样就出现了一个几个形容名词，此架构容易形成信息孤岛，重复造轮子。因此相对核心的业务会被抽取出来，作为单独的系统对外提供服务，形成业务之间的相互复用，解决了重复造轮子的问题，即面向服务的体系架构（SOA）。

举个例子，比如现我有一个数据库，一个JavaWeb（或者PHP等）的网站客户端，一个安卓app客户端，一个IOS客户端。现在我要从这个数据库中获取注册用户列表，如果不用SOA的设计思想，那么就会这样：JavaWeb里面写一个查询方法从数据库里面查数据然后在网页显示，安卓app里面写一个查询方法查询后在app上显示，IOS同样如此。这里就会出现查询方法重叠了，这样的坏处很明显了，三个地方都有相同的业务代码，要改三个地方都要改，而且要改的一模一样。当然问题不止这一个。于是乎出现了这样的设计思想，比如用Java（或者是其他语言皆可）单独创建一个工程部署在一台服务器上，并且写一个方法（或称函数）执行上述查询操作，然后使其他人可以通过某种途径（可以是http链接，或者是基于socket的RPC调用）访问这个方法得到返回数据，返回的数据类型是通用的json或者xml数据，就是说把这个操作封装到一个工程中去，然后暴露访问的方式，形成“服务”。比如这里就是注册用户服务，而关于注册用户的所有相关增删改查操作这个服务都会提供方法。这样一来，JavaWeb这边可以访问这个服务然后得到数据使用，安卓和IOS这里也可以通过这个服务得到数据。而且最重要的是，要修改关于注册用户的业务方法只要改这个服务就好了，很好的解耦。同理，其他业务比如商品、广告等业务都可以单独形成服务部署在单独服务器上。还有就是一旦哪天突然有一堆人要注册，假设这堆人仅仅只是注册而不做其他事情，其他业务比如商品、广告服务等都不忙，唯独注册这个功能压力很大，而原有的一台部署了注册服务的服务器已经承受不了这么高的并发，这时候就可以单独集群部署这个注册服务，提供多几台服务器提供注册服务，而其他服务还不忙，那就维持原样。当然，还有很多其他好处。
以上我所描述的都还不能完全称为SOA，还不够完整，因为它少了服务治理这一环节。什么是服务治理，就是当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱，需要对这些关系进行管理。举例，还是上面的例子，假如我有一个用户服务，一开始有调用方1和调用方2来使用这个服务，后来越来越多，将近上百个调用方，这个时候作为服务方，它只知道提供服务，却不知道具体为谁提供了服务。而对于开发者来说，知道这N多调用方和N多服务方之间的关系是非常重要的。所以这个时候就需要能进行服务治理的框架，比如dubbo+zookeeper，比如SpringCloud，有了服务治理功能，我们就能清晰地看到服务被谁谁谁调用，谁谁谁调用了哪些服务，哪些服务是热点服务需要配置服务器集群，而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。这个时候就是完全形态的SOA了。
实际上SOA只是一种架构设计模式，而SOAP、REST、RPC就是根据这种设计模式构建出来的规范，其中SOAP通俗理解就是http+xml的形式，REST就是http+json的形式，RPC是基于socket的形式。上文提到的CXF就是典型的SOAP/REST框架，dubbo就是典型的RPC框架，而SpringCloud就是遵守REST规范的生态系统。

再举个例子，比如你现在有很多服务：新闻服务（提供新闻的发布，查看，修改，删除），订单服务（订单添加，订单修改，订单查看，订单删除等）财务服务（收入，支出，统计等等）员工服务（新增，修改，查看，统计）考勤服务（签到，签退，导出，统计等）销售服务（卖出上报，销售统计。）假如你是一个销售集团，有1000家经销商，有50个分公司，有400个办事处，它们都需要软件办公。但是你不可能做一个最全的系统开放他们用。因为很多分公司，经销商，办事处都有定制功能。那你应该开发多少套，多少种系统呢？每种系统都从头开始写代码，直接访问数据库吗？假如在加上，手机版，aap版，平板电脑版，电脑版桌面版，网页版。你怎么办呢？这个时候再去看看SOA的概念就容器理解了，其实单靠soa无法解决这么复杂的问题，还需要很多组合方法。