grpc与rpcx的区别

什么是微服务?

整体功能通过多个程序实现,每个程序只关心特定的业务.

优点:

简化功能: 单个服务之需要关心部分业务,实现起来更容易

更灵活: 不同服务间互不影响,可以使用不同的语言与技术栈,以及交给不同的成员/团队实现,便于团队合作/外包

隔离: 部分服务出问题不影响其他服务的功能

拓展: 更容易针对借口的实际压力情况进行横向拓展.

rpc架构的主要区别

rpc架构的核心功能实际上是实现远程调用服务方法调用,客户端能像调用本地方法一样调用服务端和方法

那么核心问题就是如何实现接口的远程调用,选择什么网络协议,数据格式,这些决定了rpc架构是否跨语言,以及性能如何

可以写一个简单的rpc服务的demo去了解rpc是如何工作的

下面是一个很粗糙的demo;使用tcp进行通信,json进行编码的demo

public.go

package public
//公共的方法与类
import ("bytes""encoding/binary"
)func Encode(data []byte) []byte {l := len(data)lBytes := IntToBytes(l)return append(lBytes, data...)
}func IntToBytes(n int) []byte {data := int64(n)bytebuf := bytes.NewBuffer([]byte{})binary.Write(bytebuf, binary.BigEndian, data)return bytebuf.Bytes()
}func BytesToInt(bys []byte) int {bytebuff := bytes.NewBuffer(bys)var data int64binary.Read(bytebuff, binary.BigEndian, &data)return int(data)
}type ReqData struct {ServerName stringTag        string //标记哪个线程调用的服务,返回的时候带上可以将数据传输到对应的县城Data       []byte
}
type RspData struct {Tag  string //标记哪个线程调用的服务,返回的时候带上可以将数据传输到对应的县城Data []byte
}type AddReq struct {NumA intNumB int
}type AddRsp struct {Sum int
}

server.go

package mainimport ("bufio""encoding/json""fmt""net""rpc_demo/public"
)type Server struct{}func (s *Server) Add(a *public.AddReq) *public.AddRsp {return &public.AddRsp{Sum: a.NumA + a.NumB}
}// 服务调用
// 服务名+方法名
// 封装对应的服务调用过程:根据方法名解析数据,并调用对应的方法
// 数据打包返回
// 这里做简化板手写处理:1. 没有实现自动化的服务方法注册;2. 我暂定使用uuid进行标识请求,以便于客户端可以将数据读取到对应的请求线程上,但事实上uuid过长,应该使用更为简单的标识方式
func serve(conn net.Conn) {defer conn.Close()reader := bufio.NewReader(conn)for {//解析长度lBytes := make([]byte, 8)_, err := reader.Read(lBytes[:])if err != nil {fmt.Printf("数据读取失败%v\n", err)return}l := public.BytesToInt(lBytes)reqBytes := make([]byte, l)_, err = reader.Read(reqBytes)if err != nil {fmt.Printf("数据读取失败%v\n", err)return}go func(reqData []byte) {req := new(public.ReqData)err = json.Unmarshal(reqData, req)if err != nil {fmt.Printf("json 解析失败%v\n", err)return}//解析处理(这里只注册了一个服务接口)switch req.ServerName {case "Server.Add":s := &Server{}data := new(public.AddReq)err := json.Unmarshal(req.Data, data)if err != nil {fmt.Printf("json 解析失败%v\n", err)return}rsp := s.Add(data)result, err := json.Marshal(rsp)if err != nil {fmt.Printf("数据编码失败%v\n", err)return}rspBytes, err := json.Marshal(&public.RspData{Tag: req.Tag, Data: result})if err != nil {fmt.Printf("数据编码失败%v\n", err)return}rspData := append(public.IntToBytes(len(rspBytes)), rspBytes...)conn.Write(rspData)default:conn.Write([]byte("该方法没有注册"))}}(reqBytes)}}func main() {listen, err := net.Listen("tcp", "127.0.0.1:9999")if err != nil {fmt.Println("Listen() failed, err: ", err)return}for {conn, err := listen.Accept() // 监听客户端的连接请求if err != nil {fmt.Println("Accept() failed, err: ", err)continue}go serve(conn) // 启动一个goroutine来处理客户端的连接请求}
}

client.go

package mainimport ("bufio""encoding/json""fmt""net""rpc_demo/public""time""github.com/google/uuid"
)type Client struct{ Conn net.Conn }func NewClient() *Client {conn, err := net.Dial("tcp", "127.0.0.1:9999")if err != nil {fmt.Println("err : ", err)return nil}return &Client{Conn: conn}
}// 每次调用都生成单独的uuid,并作为key,请求后select uuid对应的chan,直到有数据,读取数据,关闭通道,清除对应的map记录
var M map[string]chan ([]byte)// 启动客户端连接服务端并解析数据
func (c *Client) Run() {defer c.Conn.Close() // 关闭TCP连接reader := bufio.NewReader(c.Conn)for {lBytes := make([]byte, 8)_, err := reader.Read(lBytes[:])if err != nil {fmt.Printf("数据读取失败")return}l := public.BytesToInt(lBytes)reqBytes := make([]byte, l)_, err = reader.Read(reqBytes)if err != nil {fmt.Printf("数据读取失败")return}//解析数据体并写入对应的chango func(data []byte) {rspData := new(public.RspData)err := json.Unmarshal(data, rspData)if err != nil {fmt.Printf("数据解析失败")return}M[rspData.Tag] <- rspData.Data}(reqBytes)}
}// 我这边就不封装自动call了,直接手动call
func (c *Client) Call(serverAndfunc string, data []byte) []byte {//生成uuidtag := uuid.New().String()reqData := &public.ReqData{ServerName: serverAndfunc, Tag: tag, Data: data}r, err := json.Marshal(reqData)if err != nil {fmt.Println("编码错误")return nil}Ch := make(chan []byte)defer close(Ch)defer delete(M, tag)M[tag] = Chc.Conn.Write(append(public.IntToBytes(len(r)), r...))return <-Ch
}func main() {// 初始化mapM = make(map[string]chan []byte)//建立tcp连接服务端client := NewClient()// 启动处理go client.Run()//模拟调用call方法req1 := &public.AddReq{NumA: 1,NumB: 2,}reqdata1, err := json.Marshal(req1)if err != nil {fmt.Println("编码错误")return}req2 := &public.AddReq{NumA: 2,NumB: 2,}reqdata2, err := json.Marshal(req2)if err != nil {fmt.Println("编码错误")return}//模拟多线程调用服务端go fmt.Printf("线程1调用结果:%s\n", string(client.Call("Server.Add", reqdata1)))go fmt.Printf("线程2调用结果:%s\n", string(client.Call("Server.Add", reqdata2)))time.Sleep(10 * time.Second)
}

client运行结果:

线程1调用结果:{"Sum":3}
线程2调用结果:{"Sum":4}

• 当然这只是最简单的demo,模拟了使用tcp进行rpc远程调用,
• 是否跨语言就在于双方时候都支持相同时协议与数据格式,比如使用了tcp的通信协议,那么只要支持tcp的的语言就可以使用打包成相同的数据结构就可以被服务端解析,而那些跨语言的rpc(比如grpc)在这方面做得更好,他们隐式的生成了接口代码,你不需要知道他是如何编码与解码的.可以直接使用,这对使用者是非常友好的.

rpcx与grpc的区别

rpcx:

• 通信协议: 支持tcp,http,quic,kcp
• 数据格式: 支持json,proto等多种解码器
• 服务发现。支持 peer2peer、configured peers、zookeeper、etcd、consul 和 mDNS。
• 其他: 多功能支持 https://github.com/smallnest/rpcx?tab=readme-ov-file
• 性能优越

grpc:

• 通信协议:http2
• 数据格式: proto
• 服务发现: 支持etcd等多种组件.
• 其他:https://www.cnblogs.com/leijiangtao/p/4453914.html
• 自动生成photo文件规范,节省开发时间,方便快捷的部署微服务,跨语言开发等多种优势

为什么grpc要使用http2,为什么不适应http1或者http3?

1. http1是一次请求一次响应的形式,要等上一次请求完成才能下一次请求,效率太低;而http2:每个请求都是一个双向流,一个连接可以包含多个流,等于是同时发起多个请求,效率更高
2. 当时,http3技术不成熟,并且http3相对来讲比较复杂.并且http2对于grpc来讲已经够用了.

为什么grpc要使用proto而不是json或者其他数据格式?

1. proto格式只包含数据,即T-(L)-V（TAG-LENGTH-VALUE）方式编码,没有额外不用的:与{,不像json那样包含字段名+数据的格式,数据结构更紧凑.数据体更小,传输的性能更好
2. grpc作为一个跨语言的rpc架构,指定特定的数据类型可以更好的对接不同语言的接口

参考: https://segmentfault.com/a/1190000039158535

为什么rpcx快,快多少?

我翻阅了许多博客,他们都没有讲清楚为什么rpcx快.大多数都是在将rpcx与其他的比如grpc,阿里的Dubbo进行性能测试对比

rpcx的作者想做一个性能强大,服务治理的golang的rpc框架来补充golang rpc框架的空缺(虽然grpc与一些rpc架构开始支持go,但是他们都是走跨语言路线的.)

rpcx作者的发展历程介绍到开始的rpcx就是对标准库的rpc进行的封装,rpc标准库就是一个性能非常优秀的库;客户度通过tcp连接和服务器通讯，协议分为header和payload两部分，header很简单，包括服务名、方法和seq，payload包括序列化的数据。简单的数据格式,高效的网络通信使得他的性能非常的优秀.

rpcx开始的版本就是根据标准库进行封装的,封装了服务发现,各种fail处理以及丰富的路由支持.所以rpcx事实上继承了标准rpc库的性能优势,并且在后期重构了代码并且提供了更加丰富的功能.

参考: rpcx简史

rpcx的具体性能指标与grpc比较:

1. 模拟0ms处理时间

客户端并发数	500			2000	5000
测试指标	吞吐量(call/s)	平均延迟(ms)	p99延迟(ms)	吞吐量(call/s)	平均延迟(ms)
rpcx	20万		25	20万
grpc	14万		25	14万

2. 模拟10ms处理时间

客户端并发数	500			2000	5000
测试指标	吞吐量(call/s)	平均延迟(ms)	p99延迟(ms)	吞吐量(call/s)	平均延迟(ms)
rpcx	5万	10	25	15万	20
grpc	5万	10	25	9万	30

3. 模拟30ms处理时间

客户端并发数	500			2000	5000
测试指标	吞吐量(call/s)	平均延迟(ms)	p99延迟(ms)	吞吐量(call/s)	平均延迟(ms)
rpcx	1.8万	10	25	7万	30
grpc	1.8万	10	25	6万	20

参考:rpcx- GitHub

总结: 在并发数量增加的情况下,rpcx相比grpc的吞吐量与与p99延迟(处理99%请求的平均延迟)要更加优秀.