关于frpcAPI的优化

前言

因为很多人反馈，frpc API 过于复杂，太绕，不易理解，仔细看看，确实有优化的空间，这里记录下，优化的点，以及更加详细拆解下API的使用。

旧版本API回顾

frpc 远程调用是区分了one(简单负载均衡),all(广播)，byid(指定节点ID) 3个模式，API分别对应：

• one(简单负载均衡)
  one_balance_send
one_balance_call
one_mod_send
one_mod_call
one_broadcast
one_broadcast_call
one_send_by_name skynet别名方式
  one_call_by_name skynet别名方式

其中one是**节点(进程)**路由策略，balance|mod|broadcast|by_name是对端内部lua服务的路由策略。

基于module_name 的二级名称 instance_name 对端内部lua服务的路由策略。
one_balance_send_by_name
one_balance_call_by_name
one_mod_send_by_name
one_mod_call_by_name
one_broadcast_by_name
one_broadcast_call_by_name

其实理解起来跟contriner_client 内部服务的路由策略比起来就是多了节点路由。在我看来，可能导致理解困难的和API增多的原因有二点。

1. 没有把one这种节点路由拆成参数而是做成了函数命名，以至于又新增了all_***,byid_***相关API，导致API剧增。
2. skynet别名方式的函数跟module_name 的二级名称 instance_name 的命名有冲突，容易混淆。

优化方案

1. 把one|byid|all拆成参数传入new方法，减少API数量。
2. 避免skynet别名方式，命名混淆。

优化之后的API

new(mode, svr_name, module_name, instance_name)
balance_send
balance_call
mod_send
mod_call
broadcast
broadcast_call
send_by_alias skynet别名方式
call_by_alias skynet别名方式
balance_send_by_name
balance_call_by_name
mod_send_by_name
mod_call_by_name
broadcast_by_name
broadcast_call_by_name

这样API数量，减少了一些。

调用图

路由策略模式详解

节点路由

• one(简单负载均衡)
  内部逻辑就是一个每次调用累加的balance字段，假设存在2个对端 节点，就会1,2,1,2,1,… 这样轮询调用。

• byid(指定节点)
  通过调用set_svr_id指定节点ID就能发送到指定节点。

• all(广播)
  给所有svr_name的节点发。

对端进程内服务路由

到这里其实就跟contriner_client差不多了，区别就是多了通过别名的方式。

• balance(简单负载均衡)
  假设启动了2个 test_m，每次调用累加的balance字段，会在多个中轮询调用。

• mod(模除映射)
  假设启动了2个 test_m，我们可以设置调用set_mod_num 的3，调用时就用用 3 % 2(启动数) + 1 = 2，这样就用调用到2索引位置的服务。

• broadcast(广播)
  就是发给所有。

by_name尾缀API路由逻辑解释

比如上图的test_m的 instacne_name 分了QQQ和RRR，通过byname的API需要设置instance_name为QQQ或者RRR，这样只会在对应instance_name中zhixbalance或者mod策略了，相当于一个二级名称。