postman调用rpc服务器接口

RPC 是什么（what）

Remote Procedure Call，缩写为 RPC

远程过程调用

客户端和服务器端约定好一个接口（eg： SOA api 里边的接口）

客户端调用接口的时候，去请求服务器端

服务器端进行处理，返回结果

A、user-system启动一个socket-server，监听某个端口，用json作为传输数据的协议；

B、blog-system则用socket去connect我们的server，并按要求发送一个json数据给server；

C、server收到请求以后，取出json数据中的user_id，从数据库中查出user，并打包成一个json，返回给client；

D、blog-system收到返回的json，包装成对应的格式，展示给用户。

为什么用 RPC （why）

它可以简化分布式系统内，不同服务间的数据交换。
因为这些东西被封装简化了，所以，他顺带带来的好处就是：代码极大的简化。

一般这种调用的封装还支持多语言、多操作系统，所以，他能帮我们极好的实现跨平台跨语言。
更高效的数据传输。因为RPC封装了数据交换的协议，所以可以在里面极大的优化数据传输的算法，和传输方式。从而压缩数据传输的量

底层原理（how）

How IT works ？整体流程

1）服务消费方（client）调用以本地调用方式调用服务；

2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；

3）client stub找到服务地址，并将消息发送到服务端；

4）server stub收到消息后进行解码；

5）server stub根据解码结果调用本地的服务；

6）本地服务执行并将结果返回给server stub；

7）server stub将返回结果打包成消息并发送至消费方；

8）client stub接收到消息，并进行解码；

9）服务消费方得到最终结果。

RPC的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。

再举个例子：

古代有个将军在外边打仗，遇到一拨人，说是友军，但他没见过。

于是他为了查证这些人，要将这些人的信息传回给总部。根据总部的回复来判断。

1他给身边的军师说：问一下司令部，这些穿着迷彩服，拿着 ak 的人是的上级是哪里的？哪个分部的？

服务消费方（client）调用以本地调用方式调用服务

2军师就写信给司令部：我们在某某地方遇到穿着迷彩服，拿着 ak 的人是的上级是哪里的？哪个分部的？

client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体

3然后选择了飞鸽传书或者是（让下边的小弟快马加鞭），将这封信送到了司令部。

client stub找到服务地址，并将消息发送到服务端；

4司令部的通讯员接收到这封信，

server stub收到消息后进行解码；

5然后把内容读给司令部参谋长，

server stub根据解码结果调用本地的服务；

6 参谋长说告诉通讯员：这不是友军，这是骗子啊。

本地服务执行并将结果返回给server stub

7司令部通讯员把参谋长的话记录下来，写到信里，通过同样的方式返回给军师

server stub将返回结果打包成消息并发送至消费方

8军师收到信，拆开阅读

client stub接收到消息，并进行解码；

9军师告诉将军结果

服务消费方得到最终结果。

How IT works ？协议层

协议层（2，5，7）

public interface HelloWorldService {

String sayHello(String msg);

}

IDL（Interface Description Language）：接口定义语言。

service TUserService{

struct.TUser getUser (1: required i32 uid);

}

传输什么

接口名称 HelloWorldService

方法名 sayHello

参数类型&参数值 string String

超时时间

请求信息（eg: unique RequestId，版本号）

如何传

即序列化与反序列化

语言层面 jvm自带， kyro 等

语言无关 json Hessian

How IT works ？通信层

主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。

当我们要启动一个server的时候，最简单的就是按我们之前的那种方式，启动一个server-socket。但是这个模型太简单，以至于只要轻轻的给一些压力，服务就可能崩塌。因此，我们需要一个高承载能力的server模型。

现在在linux平台上，大家基本都使用epoll模型。这个是非阻塞的事件驱动模型，能够根据请求事件来触动业务逻辑。所以具有很强的负载能力。现在主流的服务器，比如：nginx、mina、netty等等，都基本采用这种底层模型。

细节是魔鬼

负载均衡

有多台提供服务，我该选择哪一台？

1.轮询

2.随机

3.最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差，使慢的机器收到更少请求

4.一致性Hash，相同参数的请求总是发到同一提供者

容错策略

访问出错了，该怎么办？

1.失败自动切换，当出现失败，重试其它服务器，通常用于读操作（推荐使用）

2.快速失败，只发起一次调用，失败立即报错,通常用于非幂等性的写操作

3.失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作

路由规则

设定某些请求只有个别服务器可以/不可以处理。

现有的一些 rpc 框架

DUBBO

http://dubbo.io

Motan

http://weibo.com/ttarticle/p/show?id=2309403951077522312320

GRPC （跨语言）

参考资料

https://zh.wikipedia.org/wiki/遠程過程調用

http://mp.weixin.qq.com/s?__biz=MzA3MDExNzcyNA==&mid=2650392260&idx=1&sn=5a4978d02326cdd38e2ea1cd9586b4df

http://blog.jobbole.com/92290/

http://dubbo.io