这个阶段,一般也是项目的初级阶段,由于人手不够,一个服务端的接口项目只有一个开发进行维护,根据开发的习惯,会把项目分成若干个模块进行开发,在一个项目下进行部署。
这样做的缺点在于项目会随着版本更新而变得不可维护。
随着每个模块功能的不断完善,代码变得更加臃肿。这时候需要对项目进行拆分,比如上面的图,分成用户体系项目、支付体系项目。
考虑如下的场景:
传统的Web应用, 一个进程, 一个请求, 天经地义. 然而, 当一个请求的处理中, 涉及到多出数据源, 并且他们之间具有一定的不依赖性.
还是传统的Web应用, 一个应用随着业务快速增长, 开发人员的流转, 就会慢慢的进入一个恶性循环, 代码量上只有加法没有了减法. 因为随着系统变复杂, 牵一发就会动全局, 而新来的维护者, 对原有的体系并没有那么多时间给他让他全面掌握. 即使有这么多时间, 要想掌握以前那么多的维护者的思维的结合, 也不是一件容易的事情…
那么, 长次以往, 这个系统将会越来越不可维护…. 到一个大型应用进入这个恶性循环, 那么等待他的只有重构了.
那么, 能不能对这个系统做解耦呢?
我们已经做了很多解耦了, 数据, 中间件, 业务, 逻辑, 等等, 各种分层. 但到Web应用这块, 还能怎么分呢, MVC我们已经做过了….
那么, RPC就是解耦方式
RPC是Remote Procedure Call的缩写
Procedure就是function的另类写法,RPC就是在本地调用远程服务器上的一个function,仅此而已。
RPC有多种协议。SOAP是HTTP+XML base的RPC protocol。Thrift是binary的RPC protocol。
RPC的主要目的是解决不同语言间互相调用的问题。一个足够复杂的集群中,有的服务器跑PHP,有的服务器跑Python,有的服务器跑C++,互相之间怎么传递信息?这需要有一个约定:函数名有什么要求?函数参数支持什么类型?int类型的变量是32bit unsigned还是16bit signed?服务器和客户端之间通讯的字节流是big endian还是little endian?这些约定就是所谓的RPC协议。
那什么是“远程调用”?
通常我们调用一个方法,譬如: localAdd(10, 20),localAdd方法的具体实现要么是用户自己定义,要么存在于该语言的库函数中,也就说在localAdd方法的代码实现在本地,它是一个本地调用!
“远程调用”意思就是:被调用方法的具体实现不在程序运行本地,而是在别的某个地方;
远程调用原理
譬如 A调用B提供的remoteAdd方法:
首先A与B之间建立一个TCP连接;
然后A把需要调用的方法名(这里是remoteAdd)以及方法参数(10, 20)序列化成字节流发送出去;
B接受A发送过来的字节流,然后反序列化得到目标方法名,方法参数,接着执行相应的方法调用(可能是localAdd)并把结果30返回;
A接受远程调用结果
RPC框架无非就是把我刚才说的那些细节通通封装起来,给用户暴露简单友好的API使用(ps:有些远程调用选择比较底层的socket协议,有些远程调用选择比较上层的HTTP协议);
远程调用好处:
解耦:当方法提供者需要对方法内实现修改时,调用者完全感知不到,不用做任何变更;这种方式在跨部门,跨公司合作的时候经常用到,并且方法的提供者我们通常称为:服务的暴露方法
RPC(远程过程调用)是什么
简单的说,RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器(服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。
RPC 会隐藏底层的通讯细节(不需要直接处理Socket通讯或Http通讯)
RPC 是一个请求响应模型。客户端发起请求,服务器返回响应(类似于Http的工作方式)
RPC 在使用形式上像调用本地函数(或方法)一样去调用远程的函数(或方法)。
rpc服务的组成部件
rpc服务本质上是一种c/s架构服务.所以在编写一个rpc组件时,需要编写client端,server端,还要编写传输的协议.rpc框架主要是实现这三种部件的编码.省去我们在去
编写这些RPC组件通用逻辑的地方.我们只需要编写我们的服务即可.
rpc服务的优点
是否需要引入rpc服务
创业公司初期通常不会引用rpc服务,当业务随着公司的发展,业务会不断的进行优化拆分,这时引用rpc服务,主要是用于解决服务之间的依赖关系和服务治理.
在初期,可能只有一个小团队,大家维护着一个项目.随着发展,团队随着业务进行拆分,这时大家可能根据业务创建多个项目,但各业务之间很少会独立存在,出现相互依赖的情况,
当出现这种情况,我们可以先简单的deploy一个直接查询db的jar供别人服务或者他组业务直接connection别人的db操作.这时出现了服务依赖的关系,这种架构发展下去会使服务
的可靠性\稳定性都会降低,服务升级也需要依赖的业务一起升级.这时就是引入rpc服务的合适时机.
rpc服务的特点
调用方式方便,像本地化调用一样
通过选择合适的传输协议,服务之间的调用效率将会提高
rpc服务一般都会有一个服务注册中心模块(比如国内的dubbo),通过该模块,可以实现服务的负载和故障迁移