对于SOA的理解
in inbox with 0 comment

对于SOA的理解

in inbox with 0 comment

SOA就是一个面向服务的架构,它把应用程序的不同功能单元进行拆分,这些被拆出来的功能单元被称为服务,并且通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,独立于实现服务的硬件平台操作系统和编程语言。

意图是什么?

这样做的显而易见的好处就是可以在各个系统中用一种统一的和通用的方式进行交互。
接下来我们举一个例子
假如说现在需要做一套系统,它拥有三个客户端,一个是web端,一个安卓端,一个iOS端
然后他们都有一个这样的业务场景都需要从数据库中获取注册用户的列表。
接下来我们不使用soa的思想,那么网页端。安卓端iOS端都需要写向服务器查询的方法,显而易见的是,这很浪费,并且如果服务器端有所改动的话,三部分都需要重新改。但是采用soa的思想我们就可以把向数据库中查询数据这一部分操作独立起来,采用某种编程语言实现然后部署在一台服务器上面,其他人可以通过某种途径,比如说HTTP链接或者RPC调用访问这个方法,然后返回数据。通常来说数据是使用json或者xml格式,好,这个东西就被我们称为接口。
那么使用这种方法之后,我们就相当于把整个业务系统中的一部分功能独立出来,显然这样是可以实现上述功能的其实这样还带来一个隐含的好处,假如说当我们的系统面临巨大的压力的时候,我们会发现仅仅是系统中的某一部分承担了压力,这时候我们仅仅需要对这一部分进行集群或者进行其他操作,就可以缓解高峰期的压力。同样的我们也来举一个例子,某一天产品发起了一个活动,然后有很多新用户来注册,通常来说这种情况下人们只会注册,并不会做其他的事情,那么像其他的业务,比如说商品广告等服务器都不繁忙,唯独注册压力很大,此时部署了注册服务的服务器承受不了,这么高并发的时候,我们只需要对这台服务器进行集群或者其他操作,但是其他的业务我们不需要进行改动,只需要维持原样就可以。

坏处?特点?

但是这样做也有一个坏处,我们的系统被拆分成这样,很多的,小的服务的时候就会发现彼此之间的调用关系极其复杂。因此采用soa的思想,必须要有一个服务治理框架,可以让我们清晰的看到谁被谁调用谁调用哪些服务,哪些服务是需要进行单独注意的服务,这里说的单独注意就是热点服务
那么此时我们的系统就是完全的SOA形态。

Responses