SOA和RPC讲解

我们在学习Dubbo之前,需要先学习两个概念,第一个概念SOA,什么叫SOA呢,他不是一个技术,他是一种架构设计模式,

也就是在我们开发项目的时候,如何来设计项目的架构,也就是如何来设计项目能够更加好,SOA他的中文名称,我们来看英文名称吧,

面向服务架构,英文名称Service-Oriented Architecture,中文名称面向服务架构,SOA的定位,他不是一个技术,也不是一个语言,

它是一个如何设计在开发当中的一个项目,如何设计项目,在开发时更有效率,他的优点不光是这个,主要的是如何设计项目,重点

在这儿,准确来说,我来给他一个定位,它是一种思想,我们去解释一下,我们从哪里引出一个SOA的概念比如我们在设计的时候

我们在做项目的时候,是怎么来设计的,回顾一下我们之前是怎么做的,有一个父项目,叫ego-parent,有一个前台叫ego-portal,

还有一个后台叫ego-management,还有一个实体类,实际上实体类不是我们关注的重点,那我们现在看,portal和management,他们两个

是不是都可以去访问数据库,都是直接访问的数据库,所以再往下画一个柱状图,DB,这是我们昨天去设计的一个架构,他们都去访问数据库,

我们在写代码的时候,有没有感受到一个事情,哪块重复了,主要是我们在写的时候,ego-portal的mapper这块,和ego-manager的mapper

这块,感觉他们优点重复的感觉,其实在我们现在这种设计的时候,很多时候在公司的项目不允许所有的项目都访问数据库,知道为什么吗,

数据库里面存的是数据,数据是一个项目的核心,如果你要是能让所有的项目都能访问这里,那可能会导致数据的不安全,这是一个问题,

第二个,在开发时,数据访问层,他的代码可能会出现一个冗余的问题,就是写好多遍,相同的代码都是select by id,根据id查询,

可能好多项目都会写一遍,那SOA架构,这个架构就是专门解决这类问题的,解决什么样的问题呢

使用SOA架构之后,他就有一个专门访问数据库的服务,我们在这里称之为服务,实际上你可以理解为一个项目,你可以

这么来去理解,专门取访问数据库的一个服务,我们以后访问数据库的代码,是不是都调这个服务,都是调用这个服务,所谓的

面向服务的架构,面向服务架构,就是有一个专门提供服务的单元,其他单元都调用这个服务,这个服务就像我们银河系的太阳一样，

所有其他的人都围绕着他来转,在我们这里也是的,数据库DB,所有人你想走数据库,必须先走我,然后之后,在往下做的时候,

跟上面的一样了,能看出和之前什么区别吗,多了一层是吧,ego-portal,ego-management,实体我就不画了,主要是没有太大的作用,

以后所有来进行访问的时候,都走服务,也就是说,在我们现在这个项目中,portal他不具备数据库访问的能力,它是不具备直接访问数据库的

能力,你看这个箭头,他能直接到数据库吗,是不能,想访问数据库我必须得怎么样,就必须走这个服务,SOA架构就是这样的一个东西,

面向服务架构,所谓的面向服务就是这样的,有一个统一提供服务的项目,然后以后你想调数据库,全走我,那这样的话,其实我们在开发的时候,

开发时我们可以实现数据访问控制和代码复用,什么叫数据访问控制,是不是必须走服务才能走数据库,然后代码复用能感受到吗,

以前我们portal和management两个是可以在这里慢慢写,两个都写select by id,现在写几遍就行了,是不是在服务里写一遍,

所以这种架构,分布式项目基本上都是这种架构,SOA架构非常重要的一个概念,那现在我们目前实现SOA架构的话

实现SOA架构时,几种常用服务,用的比较多的,就是dubbo作为服务,这是咱们今天要讲的dubbo,除了他以外,再有

webservice,这是比较老的了,还有dubbo的升级版,都是阿里出的,还有的在用dubbox,是当当网出的,除了这些以外,

有一种比较特殊的,服务方,这种就比较特殊了,没有应用其他第三方技术,服务方其实就是一个web项目,我们是调用这个

web项目的控制器,什么意思,这个服务其实就是个web项目,以后我想在ego-portal项目中调他的话,调用它的控制器,

那通过一种特殊的技术,我们在讲电商的时候,HttpClient,这种技术,调别人的控制器,那现在我们看,今天主要是来学习

dubbo,刚才我们在说使用SOA架构的时候,这个服务层能够实现数据访问控制和代码复用,那在这里面,数据一定是所有项目的

一个核心,那这个数据访问控制在访问的时候,其他的ego-portal和ego-management他们两个就不需要再写mapper这两个包了,

挺清楚,不用写mapper这个包了,为啥,mapper数据访问的都在服务了,那service得写还是得写吧,service是项目的业务,

业务是该写得写的,只要调数据库就都得调他,我们为了保证服务方的一个安全性,我们下面需要再讲一个概念

远程调用协议,RPC,Remote Procedure Call,这是他的英文名称,中文名称叫远程过程调用协议,什么意思啊,

那我们现在说的RPC,我们聊天的时候都说,你们公司用什么RPC框架啊,都是这么聊天,就是用一个基于远程调用的一个框架,

RPC指的是什么啊,我解释一下RPC,客户端A通过互联网调用远程服务器,不知道远程服务器具体实现,只知道远程服务器提供了

什么功能,什么意思,我们画图,假设这里有一个客户端,然后再有一个服务器,我调你的时候我能调,但是我调的时候我知道,

你有一个功能,或者你有一个方法,假设叫A方法,这个方法我调完之后,我就能查询出A表中的数据,但是你里面具体怎么写的,

我不知道,所谓的RPC就是这样的,只有提供功能的列表,而没有具体功能实现,这样有什么好处,你看他达到的效果是什么,

你就只能调我,具体我怎么做的你是不知道的,那肯定是从一个安全性考虑,所以RPC一个最大的优点啊,就是一个安全性,

那现在有一个RPC的概念,有了RPC,有了Dubbo,和SOA,他两是一个相关的概念,如果我这个服务使用一个RPC框架的话,

会怎么样,是不是别人你调我的时候,我知道我可以调什么东西,但是我不知道里面具体的实现,那是不是安全性更高,

而且我们访问的是项目的核心数据库,所以数据库你就想呗,举一个最简单的例子,比如咱们手机上都有QQ,QQ有很多的

软件都是需要去授权一下,你授权干什么呢,获取用户数据呢,对吧,你说其他的一些软件,我在获取的时候,我只能获取到的

是一个状态,挺清楚,一旦授权之后我就能够登陆,我能获取到该用户的用户名什么的,这些东西基本能获到,能不能直接显示

我的密码是什么,不能,即使获得的也绝对是一个加密的,所以SOA这个架构的服务,一定要设计好,怎么设计,使用RPC来保证

数据的安全性