江邊望海的技術人生
分享真知
系统架构设计之RPC浅析
  1. 什么是RPC
  2. 什么是RESTful
    1. RESTful 是面向资源的
    2. RESTful的HTTP特征
  3. PHP与RPC
    1. Yar
    2. Swoole

什么是RPC

RPC全称为Remote Procedure Call,翻译过来为“远程过程调用”。目前,主流的平台中都支持各种远程调用技术,以满足分布式系统架构中不同的系统之间的远程通信和相互调用。

什么是RESTful

Restful是一种轻量级,跨语言,跨平台的web服务方式,他是一种设计理念,他强调将网络中的一切事物看成资源,对资源的所有的操作方式均定义成“查,插,删,改” 四种方式,向外界暴露API,用来调用,所有的操作都是无状态的。RESTful 有如下特征:

RESTful 是面向资源的

RESTful 是面向资源的,而资源是通过 URI 进行暴露。URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关,操作是通过 HTTP动词来体现,所以REST 通过 URI 暴露资源时,会强调不要在 URI 中出现动词。

比如:左边是错误的设计,而右边是正确的

GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗 
GET /rest/api/addDogs --> POST /rest/api/dogs 添加一个小狗狗 
GET /rest/api/editDogs/:dog_id --> PUT /rest/api/dogs/:dog_id 修改一个小狗狗 
GET /rest/api/deleteDogs/:dog_id --> DELETE /rest/api/dogs/:dog_id 删除一个小狗狗

左边的这种设计,很明显不符合REST风格,上面已经说了,URI 只负责准确无误的暴露资源,而 getDogs/addDogs...已经包含了对资源的操作,这是不对的。相反右边却满足了,它的操作是使用标准的HTTP动词来体现。

RESTful的HTTP特征

RESTful 是基于 HTTP 的,这样所有的HTTP客户端(如浏览器)能够直接访问资源。RESTful 很好的利用了 HTTP 特征,比如动词,状态吗,报头等。

HTTP动词

GET     获取一个资源 
POST    添加一个资源 
PUT     修改一个资源 
DELETE  删除一个资源 

实际上,这四个动词对应着增删改查四个操作,这就利用了HTTP动词来表示对资源的操作。

HTTP状态码

200 OK 
400 Bad Request 
500 Internal Server Error

在客户端与资源的交互当中,其结果无非就三种状态:

  • 所有事情都按预期正确执行完毕 - 成功
  • APP 发生了一些错误 – 客户端错误
  • API 发生了一些错误 – 服务器端错误

这三种状态与上面的状态码是一一对应的。

HTTP报头

Authorization 认证报头 
Cache-Control 缓存报头 
Cnotent-Type  消息体类型报头 
......

HTTP报头是描述HTTP请求或响应的元数据,它的作用是客户端与服务器端进行相互通信时,告诉对方应该如何处理本次请求。

使用RPC远程服务调用与传统http接口直接调用方式的差别在于:

  1. 从使用方面看,Http接口只关注服务提供方,对于客户端怎么调用,调用方式怎样并不关心,通常情况下,我们使用Http方式进行调用时,只要将内容进行传输即可,这样客户端在使用时,需要更关注网络方面的传输,比较不适用与业务方面的开发;而RPC服务则需要客户端接口与服务端保持一致,服务端提供一个方法,客户端通过接口直接发起调用,业务开发人员仅需要关注业务方法的调用即可,不再关注网络传输的细节,在开发上更为高效。

  2. 从性能角度看,使用Http时,Http本身提供了丰富的状态功能与扩展功能,但也由于Http提供的功能过多,导致在网络传输时,需要携带的信息更多,从性能角度上讲,较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据,传输数据更小,性能更高。

  3. 从运维角度看,使用Http接口时,常常使用一个前端代理,来进行Http转发代理请求的操作,需要进行扩容时,则需要去修改代理服务器的配置,较为繁琐,也容易出错。而使用RPC方式的微服务,则只要增加一个服务节点即可,注册中心可自动感知到节点的变化,通知调用客户端进行负载的动态控制,更为智能,省去运维的操作。

Restful架构是基于Http应用层协议的产物,RPC架构是基于TCP传输层协议的产物。RPC架构的吞吐量和执行速度优于Restful。所以,业内对微服务的实现,基本是确定一个组织边界,在该边界内,使用RPC; 边界外,使用Restful。这个边界,可以是业务、部门,甚至是全公司。


PHP与RPC

Yar

以下是鸟哥开发Yar要解决的场景

还是传统的Web应用, 一个应用随着业务快速增长, 开发人员的流转, 就会慢慢的进入一个恶性循环, 代码量上只有加法没有了减法. 因为随着系统变复杂, 牵一发就会动全局, 而新来的维护者, 对原有的体系并没有那么多时间给他让他全面掌握. 即使有这么多时间, 要想掌握以前那么多的维护者的思维的结合, 也不是一件容易的事情…
那么, 长次以往, 这个系统将会越来越不可维护…. 到一个大型应用进入这个恶性循环, 那么等待他的只有重构了.
那么, 能不能对这个系统做解耦呢?
我们已经做了很多解耦了, 数据, 中间件, 业务, 逻辑, 等等, 各种分层. 但到Web应用这块, 还能怎么分呢, MVC我们已经做过了….
基于此, Yar或许能解决你遇到的这俩个问题…

server.php

<?php
class Test
{
    public function Hello()
    {
        return 'Hello world';
    }
}
$service = new Yar_Server(new Test);
$service->handle();

client.php

<?php
$client = new Yar_Client('http://localhost/server.php');
$res = $client->Hello();
var_dump($res);

执行结果

[root@jiangbianwanghai]# php client.php
string(20) "Hello world"

Swoole