什么是微服务?

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

优点:

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

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

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

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

微服务的主要区别

微服务中每个服务都是一个独立运行的程序,他们要进行合作才能实现完整和功能.

基本功能: 通信(接口调用),服务注册,发现

不同架构的主要区别: 通信协议,数据传输格式,中间件支持等

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%请求的平均延迟)要更加优秀.