当前位置: 首页 > article >正文

grpc与rpcx的区别

      • 什么是微服务?
      • 微服务的主要区别
      • rpcx与grpc的区别
        • rpcx:
        • grpc:
          • 为什么grpc要使用http2,为什么不适应http1或者http3?
          • 为什么grpc要使用proto而不是json或者其他数据格式?
      • 为什么rpcx快,快多少?
        • rpcx的具体性能指标与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处理时间
客户端并发数50020005000
测试指标吞吐量(call/s)平均延迟(ms)p99延迟(ms)吞吐量(call/s)平均延迟(ms)
rpcx20万2520万
grpc14万2514万
  1. 模拟10ms处理时间
客户端并发数50020005000
测试指标吞吐量(call/s)平均延迟(ms)p99延迟(ms)吞吐量(call/s)平均延迟(ms)
rpcx5万102515万20
grpc5万10259万30
  1. 模拟30ms处理时间
客户端并发数50020005000
测试指标吞吐量(call/s)平均延迟(ms)p99延迟(ms)吞吐量(call/s)平均延迟(ms)
rpcx1.8万10257万30
grpc1.8万10256万20

参考:rpcx- GitHub

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


http://www.kler.cn/a/419153.html

相关文章:

  • ehr系统建设方案,人力资源功能模块主要分为哪些,hrm平台实际案例源码,springboot人力资源系统,vue,JAVA语言hr系统(源码)
  • jdk各个版本介绍
  • [MacOS] [kubernetes] MacOS玩转虚拟化最佳实践
  • 探索文件系统,Python os库是你的瑞士军刀
  • React+TS+css in js 练习
  • 时序约束进阶六:Set_Clock_Groups详解
  • Qt 面试题学习13_2024-12-1
  • 第n小的质数
  • 【韩顺平老师Java反射笔记】
  • SpringBoot 助力新冠密接者跟踪:大数据整合与深度挖掘的力量
  • 极致性能:19个Vue 项目的优化手段
  • C++关于二叉树的具体实现
  • (4)CHATGPT-3和GPT-4是生成式AI的一部分吗?
  • 【二分查找】力扣 2529. 正整数和负整数的最大计数
  • HTML CSS JS基础考试题与答案
  • springboot kafka在kafka server AUTH变动后consumer自动销毁
  • linux系统信号简介
  • Scala—列表(可变ListBuffer、不可变List)用法详解
  • FAT文件系统
  • 【ETCD】etcd简单入门之基础操作基于etcdctl进行操作
  • arkTS:持久化储存UI状态的基本用法(PersistentStorage)
  • 基于Java Springboot宠物医院微信小程序
  • UI设计-色彩、层级、字体、边距(二)
  • 民锋视角:数据分析如何助力金融决策
  • 【docker集群应用】Docker--harbor私有仓库部署与管理
  • C语言——管理系统