网站首页 » 架构 » SOA(面向服务的架构)

SOA(面向服务的架构)

July 27, 2021 架构

SOA介绍

SOA(Service-Oriented Architecture 面向服务的架构)

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规范的生态系统。

SOA 个人理解

SOA提倡建立中台服务,将用户的所有服务拆分成一个个服务中台。例如:用户有注册、登陆、认证服务。那么就建立一个用户中台,用户中台提供用户的注册、登陆和认证。在整个系统生态中,涉及到让用户注册、登陆、认证的时候,统一到用户中台去判定是否注册,进行用户登陆操作,进行用户身份认证操作。当用户的注册、登陆、认证流程发生改变时,我们只需要针对用户中台做调整,不影响用户的其他服务。同时,由统一的一个模块完成用户登陆、注册、认证服务可以提供整个系统生态的用户唯一登陆验证,可以很轻松的做到统一登陆。

添加新评论