中文介绍中文电子书

go get -u -v github.com/smallnest/rpcx/...

rpcx is a distributed RPC framework like Alibaba Dubbo and Weibo Motan. It is based on Go net/rpc and provides extra governance features.

php-rpcx is a php client for rpcx, created by Leon2012

Notice

Since rpcx 2.0, we replace underlying Go official rpc transport with customized rpc transport. So rpcx can support context in client side and server side.

If you want to use underlying Go official rpc transport, please use rpcx 1.3.

very very good performance. Much better than gRPC, Dubbo and weibo Motan.

When we talk about RPC frameworks, Dubbo is the first framework we should mention, and also Dubbox mantained by dangdang. Dubbo has been widely used in e-commerce companies in China, for example, Alibaba, Jingdong and Dangdang.

Though Dubbo still uses Spring 2.5.6.SEC03, and is no longer supported by Alibaba, some other companies still usea it and maintain their own branches.

DUBBO is a distributed service framework , provides high performance and transparent RPC remote service call. It is the core framework of Alibaba SOA service governance programs. There are 3,000,000,000 calls for 2,000+ services per day, and it has been widely used in various member sites of Alibaba Group.

Motan is open source now by Weibo. As Zhang Lei said, he is the current main developer of Motan:

Motan started in 2013. There are 100 billion calls for hundreds of service calls every day.

Those two RPC frameworks are developed in Java. There are other famous RPC frameworks such as thrift、and finagle。

The goal of rpcx is to implement an RPC framework like Dubbo in Go. It is developed in Go, and to be used in Go.

It is a distributed、pluggable RPC framework with governance (service discovery、load balancer、fault tolerance、monitoring, etc.).

As you know, RPC frameworks already exists, for example, net/rpc、grpc-go、gorilla-rpc, So why re-invent the wheel?

Although those Go RPC frameworks work well, their function is relatively simple and they only implement end-to-end communication. They lack some product features of service management functions like service discovery, load balancing, and fault tolerance.

So I created rpcx and expect it to become an RPC framework like Dubbo.

A similar project in go is called go-micro.

From wikiPedia:

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in another address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote.[1] This is a form of client–server interaction (caller is client, executer is server), typically implemented via a request–response message-passing system. The object-oriented programming analog is remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures is largely the same whether it is local or remote, but usually they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is useful.

RPCs are a form of inter-process communication (IPC), in that different processes have different address spaces: if on the same host machine, they have distinct virtual address spaces, even though the physical address space is the same; while if they are on different hosts, the physical address space is different. Many different (often incompatible) technologies have been used to implement the concept.

Sequence of events during an RPC

1. The client calls the client stub. The call is a local procedure call, with parameters pushed on to the stack in the normal way.
2. The client stub packs the parameters into a message and makes a system call to send the message. Packing the parameters is called marshalling.
3. The client's local operating system sends the message from the client machine to the server machine.
4. The local operating system on the server machine passes the incoming packets to the server stub.
5. The server stub unpacks the parameters from the message. Unpacking the parameters is called unmarshalling.
6. Finally, the server stub calls the server procedure. The reply traces the same steps in the reverse direction.

There are two ways to implement RPC frameworks. One focusses on cross-language calls and the other focusses on service governance.

Dubbo、DubboX、and Motan are RPC frameworks focusing on service governance. Thrift、gRPC、Hessian、and Hprose are RPC frameworks focusing on cross-language calls.

rpcx focus in on service governance.

• Based on net/rpc. a Go net/prc project can be converted to use rpcx with a few changes.
• Pluggable. Features are implemented by Plugins, such as service discovery.
• Communicate with TCP long connections.
• Support GeoLocation
• Support many codec. for example, Gob、Json、MessagePack、gencode、ProtoBuf.
• Service dicovery. support ZooKeeper、Etcd.
• Fault tolerance：Failover、Failfast、Failtry.
• Load banlancer：support randomSelecter, RoundRobin, consistent hashing, etc.
• Scalable.
• Other: metrics、log、timeout.
• Authorization.
• Compression:inflate and snappy.
• Alias name for services.
• kcp support: a full-featured reliable-UDP library for golang
• support OpenTracing and Prometheus
• support Header and Context
• support TCP, UDP and QUIC

rpcx has fixed/implemented the below issues in golang/go rpc and I believe those issues won't be fixed in the official library because the official rpc library will be frozen.

• #16449: proposal: support custom method names in net/rpc
• #15236: net/rpc: expected Timeout based alternatives to functions for rpc.Dial, rpc.DialHTTP, rpc.DialHTTPPath [proposal].
• #13395: net/rpc: Server.ServeHTTP assumes default http mux
• #10929: net/rpc/jsonrpc: Missing support for JSON-RPC 2.0
• #7946: net/rpc: add client support for RPC over https
• #4591: Authentication for RPC and HTTP
• #4584: net/rpc: access to client's IP address
• #3615: rpc: allow aliasing methods

rpcx-ui provides a web ui for services management.

rpcx contains three roles : RPC Server，RPC Client and Registry.

• Server registers services on the Registry
• Client queries the service list and select a server from the server list returned from the Registry.
• When a Server is down, the Registry can remove the server from the list, and subsequently the client can remove it too.

So far rpcx supports ZooKeeper and Etcd as Registry，Consul support is in developement.

you can found more examples at rpcx-examples2

Test Environment

• CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 24 cores
• Memory: 16G
• OS: Linux Server-3 2.6.32-358.el6.x86_64, CentOS 6.4
• Go: 1.7

Test request is copied from protobuf project and encoded to a proto message. Its size is 581 bytes. The response update two fields of decoded requests so the server goes through decoding and encoding.

The test proto file is:

syntax="proto2"; packagemain; optionoptimize_for=SPEED; messageBenchmarkMessage{requiredstringfield1=1; optionalstringfield9=9; optionalstringfield18=18; optionalboolfield80=80 [default=false]; optionalboolfield81=81 [default=true]; requiredint32field2=2; requiredint32field3=3; optionalint32field280=280; optionalint32field6=6 [default=0]; optionalint64field22=22; optionalstringfield4=4; repeatedfixed64field5=5; optionalboolfield59=59 [default=false]; optionalstringfield7=7; optionalint32field16=16; optionalint32field130=130 [default=0]; optionalboolfield12=12 [default=true]; optionalboolfield17=17 [default=true]; optionalboolfield13=13 [default=true]; optionalboolfield14=14 [default=true]; optionalint32field104=104 [default=0]; optionalint32field100=100 [default=0]; optionalint32field101=101 [default=0]; optionalstringfield102=102; optionalstringfield103=103; optionalint32field29=29 [default=0]; optionalboolfield30=30 [default=false]; optionalint32field60=60 [default=-1]; optionalint32field271=271 [default=-1]; optionalint32field272=272 [default=-1]; optionalint32field150=150; optionalint32field23=23 [default=0]; optionalboolfield24=24 [default=false]; optionalint32field25=25 [default=0]; optionalboolfield78=78; optionalint32field67=67 [default=0]; optionalint32field68=68; optionalint32field128=128 [default=0]; optionalstringfield129=129 [default="xxxxxxxxxxxxxxxxxxxxx"]; optionalint32field131=131 [default=0]}

The test is run with 100, 1000, 2000 and 5000 concurrent clients. The total number of requests per clients is 1,000,000.

Test Result

you can use test code in _benchmark to test. server is used to start a server and client is used as clients via protobuf.

The above test is with a client and a server running on the same mechine.

If I run them on separate servers, the test results are:

When running in cluster mode, with one machine with one client and another two running as servers, the test results are:

[root@localhost rpcx]# go test -bench . -test.benchmem PASS BenchmarkNetRPC_gob-16 100000 18742 ns/op 321 B/op 9 allocs/op BenchmarkNetRPC_jsonrpc-16 100000 21360 ns/op 1170 B/op 31 allocs/op BenchmarkNetRPC_msgp-16 100000 18617 ns/op 776 B/op 35 allocs/op BenchmarkRPCX_gob-16 100000 18718 ns/op 320 B/op 9 allocs/op BenchmarkRPCX_json-16 100000 21238 ns/op 1170 B/op 31 allocs/op BenchmarkRPCX_msgp-16 100000 18635 ns/op 776 B/op 35 allocs/op BenchmarkRPCX_gencodec-16 100000 18454 ns/op 4485 B/op 17 allocs/op BenchmarkRPCX_protobuf-16 100000 17234 ns/op 733 B/op 13 allocs/op 

gRPC is the RPC framework by Google. It supports multiple programming lanaguage. I have compared three cases for rpcx and gRPC. It shows rpcx is much better than gRPC.

current gRPC version is 1.0.

The test results for rpcx can be found above. Below is the test results for gRPC.