微服务框架的实现:舍与不舍（微服务主流框架）

生活中充满了各种trade-off（权衡），编程开发中也是如此。本文将通过实战的角度，分享在开发微服务框架的过程中，针对不同的组件做的一些抉择，包括，协议支持的多少？数据传输采用TCP还是UDP？网络处理是普通处理模型还是定制的epoll？序列化框架那么多，该用哪种？注册中心选哪家？路由方式哪种好，如何限流等等。

嘉宾介绍：Go微服务框架rpcx的作者，拥有20余年的软件开发经验，先后在清华同方、Motorola、微博等公司工作，出版了国内第一本原创Scala图书《Scala集合技术手册》，并在台湾发行了繁体版。Go语言的布道者，在GopherChina meetup/GopherChina大会上分享过《Go微服务框架实践》、《Go并发编程》等主题。

以下是晁岳攀老师在SACC2022大会的演讲实录：

• 协议的实现

事实上，每个拥有一定规模的互联网大厂都有自己的微服务框架。比如，阿里巴巴、哔哩哔哩、百度、今日头条、学而思、好未来等。因为业务繁多需要微服务来划分，中间的调用关系必须通过框架来实现。

如上图所示，采用压缩的方式来实现。第一个是Magic number（魔法数字），使用特殊的字节（0x08）来标明Request开头。第二个是Version（版本号），在做微服务设计的时候，要尽量做到协议的兼容性。

后面几个字节，比如Message Type、Heartbeat、Oneway、Compress Type、Message Status Type、Serialize Type、Reserred，使用bit做设置，将其压缩在一起，尽量减少内存的占用。

接下来，Message ID使用了8个字节的数据。最后是size of rest data，size of serrice Path，size of serrice Method，size of meta，size of payload等数据的处理。

dubbo的处理方式与rpcx是类似的，它使用两个字节做魔法数，分别是高位和低位。后面是标记它的请求响应、需要往返、事件、序列化ID、状态、RPC请求ID等信息，接下来是消息体数据长度。

motan的协议设计与rpcx是类似的。grpc是架构在HTTP2.0基础之上的协议，它的请求是Request-Headers，加一系列的Message。对于请求，EOS（流结束）是通过在最后接收到的数据帧上出现END_STREAM标志来表示的。

Response-Headers和Trailers-Only都在单个HTTP2报头帧块中传递。对于响应，流的结束是通过在最后一个接收到的带有Trailers的报头帧上的END_STREAM标志来指示的。

thrift框架中的message表示一次接口调用、接口调用结果或者异常。这个函数中主要是调用相应的write函数来序列和写入thrift的版本、message的name以及seqid等基本信息，name字段是函数的名字。

如果使用通用的请求，常用的协议有HTTP access、Restful API、JSON RPC2.0、WebSocket等。JSON-RPC是一个无状态且轻量级的远程过程调用（RPC）协议。从性能的角度来考虑，实现特定的协议是比较常用的一种手段。

• 数据传输

在协议实现之后，客户端通过哪种传输方式把消息传输给服务端，服务端又通过什么方式将消息返还给客户端。常见的数据传输方式有几种，比如HTTP、TCP、UDP、Unix domain socket等。如果想要实现更高性能网络，我们可以在特定网络协议基础之上做数据传输。

HTTP1.0的每一次请求都伴随着一次三次握手的过程，并且是串行的请求，增加了不必要的性能开销。HTTP1.1新增了长链接的通讯方式，减少了性能损耗。HTTP Pipelining是把多个HTTP请求放到一个TCP连接中一一发送，而在发送过程中不需要等待服务器对前一个请求的响应。

HTTP1.1安全性不足和性能不高；HTTP2.0完全兼容HTTP1.0，是“更安全的HTTP，更快的HTTPS”，头部压缩，多路复用等技术充分利用了带宽，降低了延迟。HTTP3.0的底层支撑协议QUIC基于UDP实现，又含TCP的特点，实现了又快又可靠的协议。

TCP提供了一个逻辑上的连接，在进行数据传输之前必须建立连接，在数据传输之后必须终止连接。TCP为了保证数据的可靠性，要求有应答机制，应答机制实际上是通过一个基本的序列号和相对应的回应号来进行完成的。TCP本质上是一种面向连接的、非常可靠的数据传输方式，是基于IP协议来做的。

KCP是一个基于UDP实现快速、可靠、向前纠错的的协议，能以比TCP浪费10%-20%的带宽的代价，换取平均延迟降低30%-40%，且最大延迟降低三倍的传输效果。纯算法实现，并不负责底层协议（如UDP）的收发。

kcp-go是用go实现了KCP协议的一个库，其实KCP类似TCP，协议的实现也很多参考TCP协议的实现，滑动窗口，快速重传，选择性重传，慢启动等。KCP和TCP一样，也分客户端和监听端。

Unix domain socket又叫IPC（inter-process communication进程间通信）socket，用于实现同一主机上的进程间通信。它有SOKCET_DGRAM（数据包套接字）和SOCKET_STREAM（流套接字）两种模式，类似于UDP和TCP，但是面向消息的UNIX socket也是可靠的，消息既不会丢失也不会顺序错乱。

• 网络处理库

Go基于I/O multiplexing和goroutine构建了一个简洁而高性能的原生网络模型（基于Go的I/O多路复用netpoll），提供了goroutine-per-connection这样简单的网络编程模式。

虽然goroutine是轻量级的，但也并非创建的越多越好。其中有几个原因，goroutine只负责消息读取解析，当它的数量较大时，会占用很大的内存，消耗大量的CPU资源。

worker pool是一个Erlang进程池，其中的工作进程是Erlang的gen server模式进程。工作中常用worker pool模式，可以控制goroutine的数量, 防止goroutine泄露和暴涨。

Netpoll是一款Go语言高性能、I/O非阻塞（NIO）网络库，专注于RPC场景。由于EpollWait回调之后，SubReactor内是串行处理I/O事件的，导致排在最后的事件可能会有长尾问题。

• 序列化方式

编解码主要有“通用跨平台”和“专有高性能”两种方式，通用跨语言库有Protobuf、MessagePack、JSON（标准库JSON、json-iterator/go、easyjson等）、XML、Thrift。特定语言的编解码方式有Hessian 2、andyleap/gencode、colfer、zebrapack。

上图参考https://github.com/smallnest/gosercomp，我们可以看出，各个序列化方式Marshal与Unmarshal的数据。我们不要把自己的平台限制在某一种序列化方式，而是应该支持定制化，将决定权交给用户。

• 注册中心

在微服务框架之下，我们要引入注册中心，它是微服务框架依赖的一个基础服务。常见的注册中心有分布式一致性的平台，比如zookeeper（CP）、etcd（CP）、consul（CP）、Eureka（AP）。

分布式注册中心遵循CAP原理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition Tolerance（分区容错性），三者无法同时满足。

当满足CA时，要保持数据一致性，就必须进行节点数据的同步；同时要满足可用性，则响应时间必须较短，就要去数据同步时间很短，这样就不能部署太多的节点，也就无法满则高可用性。

当CP满足时，要进行数据同步，且机器数量较多，这样数据的同步时间就会比较长，无法保证较快的响应。当满足AP时，既要有一定机器数量，又要保证较快的响应时间，就无法进行节点数据的同步。

国内互联网大厂一般自研注册中心，实现AP系统，来保证可用性。比如，阿里nacos、微博vintage、腾讯Polaris Mesh。那么，中小企业如何选择注册中心？可以选择etc, consul，做好zk +本地缓存的功能；使用dns、redis、mysql等云服务；采用大厂的AP系统。

• 路由选择

最简单的方式是利用随机函数选择节点，有无法区分权重；无法根据性能实时调整；无法进行复杂情况下的选择；随机不随机，比如可能出现111112222233333的情况等问题。

利用轮询的方式选择节点，每个节点可以均匀，压力也平均，但面临无法区分权重；无法根据性能实时调整；无法进行复杂情况下的选择等问题。

基于权重，可以避免随机算法可能的压力集中。Nginx的算法可以平均生成每个节点: smooth weighted round-robin balancing algorithm。

基于请求的服务和方法，以及请求参数，利用一致性哈希算法，总是选择固定的节点，动态调整节点。

网络质量优先，client定期测试各节点的网络质量，根据网络质量分配权重。地理位置优先，同机房优先，同区域优先，国内优先。

基于特殊的需求，允许用户定制，比如正常调用同机房优先；如果失败，第二次从备份机房调用。

• 限流与降级

降级是临时禁用非核心功能，比如明星出轨、结婚离婚等重大公共事件，秒杀、抢红包等流量激增的时候，功能屏蔽但是不下线。

限流是客户端和服务端限流，从“根”上限制，避免无意义的带宽传输；无法避免业务偷偷放量；基于令牌桶和漏桶，需要处理burst场景。

• 测试

rpc测试的困难，需要客户端和服务端才能真正模拟，持续集成框架机器可能不允许网络连接，配置服务端和客户端略微复杂。网络传输单独测试，客户端和服务端业务测试时使用mock。虚假连接，把客户端请求直接给服务端处理，把客户端请求直接给服务端处理github.com/akutz/memconn。