How to Choose the Right Components When Building a Go Microservice Framework

Protocol Implementation

The rpcx protocol starts with a magic number 0x08 to identify a request, followed by a version field for compatibility. Subsequent bytes pack several flags into a single byte to minimise memory usage:

Message Type

Heartbeat

Oneway

Compress Type

Message Status Type

Serialize Type

Reserved

Message ID occupies eight bytes. The payload is described by a series of length fields: size of the remaining data, service path, service method, meta data, and the actual payload.

Similar designs are used by Dubbo and Motan (two‑byte magic numbers, request/response flags, RPC IDs, status). gRPC, built on HTTP/2, transmits request headers and messages, using the END_STREAM flag to terminate streams. Generic RPC protocols such as HTTP, RESTful API, JSON‑RPC 2.0, and WebSocket are also mentioned.

Data Transmission

After the protocol is defined, the transport layer can be chosen among HTTP, TCP, UDP, and Unix domain sockets.

HTTP 1.0 : three‑way handshake per request.

HTTP 1.1 : persistent connections.

HTTP 1.1 pipelining : multiple requests on a single TCP connection without waiting for responses.

HTTP 2.0 : header compression and multiplexing.

HTTP 3.0 (QUIC) : UDP‑based, combines speed and reliability.

TCP : reliable, connection‑oriented transmission with acknowledgements.

KCP : UDP‑based protocol offering faster delivery with forward error correction at the cost of ~10‑20% extra bandwidth. Implemented in Go by the kcp-go library.

Unix domain sockets : inter‑process communication on the same host, supporting datagram ( SOCK_DGRAM) and stream ( SOCK_STREAM) modes.

Network Processor

Go’s native network model uses I/O multiplexing (netpoll) and a goroutine‑per‑connection pattern. While goroutines are lightweight, creating too many can exhaust memory and CPU. A worker‑pool pattern, similar to Erlang’s gen_server , limits the number of active goroutines and prevents leaks.

The netpoll library provides a high‑performance non‑blocking I/O (NIO) reactor for RPC scenarios. Because I/O events are processed serially in a single sub‑reactor, tail latency may increase under heavy load.

Serialization Methods

Two categories of codecs are considered:

Cross‑platform generic codecs : Protobuf, MessagePack, JSON (standard library, json‑iterator/go, easyjson), XML, Thrift.

Language‑specific high‑performance codecs : Hessian 2, colfer, zebrapack.

Performance comparison of Marshal/Unmarshal for these serializers is available in the https://github.com/smallnest/gosercomp repository. The recommendation is to provide a pluggable serialization layer so that users can choose the format that best fits their needs.

Service Registry

A service registry is essential for microservice discovery. Common implementations include:

CP‑oriented: Zookeeper, etcd, Consul.

AP‑oriented: Eureka, Nacos, Polaris Mesh.

The choice involves CAP trade‑offs: CP guarantees strong consistency but may increase latency; AP favours availability with eventual consistency. Smaller teams often adopt etcd or Consul, while large Chinese tech firms tend to build AP‑style registries for higher availability.

Routing Selection

Simple random or round‑robin selection ignores node weight and performance. More sophisticated algorithms include:

Weighted random / smooth weighted round‑robin (as used by Nginx) to distribute load proportionally to node weight.

Consistent hashing based on service name, method, and request parameters to achieve stable node assignment.

Weight adjustments based on network quality, geographic proximity, or custom policies (e.g., same‑rack, same‑region preference).

Rate Limiting and Degradation

Degradation temporarily disables non‑core features during traffic spikes (e.g., flash sales). Rate limiting controls request rates on both client and server sides using token‑bucket or leaky‑bucket algorithms, handling burst traffic while protecting downstream services.

Testing Challenges

End‑to‑end RPC testing requires both client and server components, which can be problematic in CI environments where network connections are restricted. Mocking or in‑process connections (e.g., the github.com/akutz/memconn library) can simulate network traffic without external dependencies.