Junedayday Blog

六月天天的个人博客

0%

Go语言学习 - RPC篇:理解标准库HTTP的hander实现逻辑

Go-Study

RPC框架

作为一名开发者,我们最常见的日常工作就是web类编程:即对于CRUD请求,开发相关的业务代码。

在Go语言中,常见的RPC包括HTTP/gRPC/Thrift等,但绝大多数的开发场景仍是基于HTTP。本文对RPC的讨论,主要是基于HTTP的场景。

如果我们能熟练地掌握一套主流RPC框架,至少能提升20%的开发效率,而优秀的框架能带来更大的帮助。提效是为了有更多时间提升个人能力,我们今天就先对RPC框架有一个概览。

RPC的处理过程

对一个web程序来说,它的核心功能就是处理一个请求。一个RPC的处理流程可以简单划分为3块:

  1. 解析请求数据
  2. 业务逻辑处理
  3. 返回结果

这个看似简单的流程,在实际开发过程中会遇到很多问题。抛开业务逻辑,我们重点看一下1、3两步:

解析请求数据:

  1. 要理解HTTP协议的标准,了解URL/Header/Body里的数据信息,如Content-Type
  2. 定义这个请求的数据结构,将数据 反序列化 到程序中的结构体

返回结果:

  1. 定义请求的返回数据结构,将程序中的结构体 序列化
  2. 异常情况下,如业务处理错误、程序崩溃等,如何保证返回的数据结构一致

简单来说,这两步的功能可以概括为:如何将数据按定义的标准,进行序列化与反序列化

常见的序列化工具如json/xml/protobuf等,新手主要了解 json 即可。

接下来,我们来看看标准库对请求的处理。

Go标准库的示例代码

我们先来看标准HTTP库,它的实现是我们学习RPC的基础:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
http.HandleFunc("/router", func(writer http.ResponseWriter, request *http.Request) {
type MyRequest struct {
Name string `json:"name"`
}
type MyResponse struct {
Errno int `json:"errno"`
}

var resp = new(MyResponse)

// 1. 解析参数
var req MyRequest
b, err := ioutil.ReadAll(request.Body)
if err != nil {
resp.Errno = 1
b, _ = json.Marshal(resp)
writer.Write(b)
return
}
json.Unmarshal(b, &req)

// 2. 业务逻辑处理

// 3. 返回结果
b, _ = json.Marshal(resp)
writer.Write(b)
return
})

两个关键参数

响应 http.ResponseWriter 与 请求*http.Request。这两个参数里面包含了许多信息,我这里列举最常用的几个:

  1. 结构体Request
    1. Method - http方法
    2. URL - http URL
    3. Header - http头
    4. Body - http消息体
  2. 接口ResponseWriter
    1. Write - 写Body
    2. WriteHeader - 写状态码

开发思路

我们梳理一下,一个新的HTTP接口的开发是什么样的逻辑:

1.如何匹配到handler

示例就是/router这个路由匹配,但实际情况中会更复杂:

  1. 如前缀匹配、模糊匹配等
  2. 按照RESTful协议,不同Method的处理逻辑不一样

对于第二点,我们自然也可以通过在handler函数中增加if-else的逻辑来覆盖,但这么写下来,显然会增加handler函数的复杂程度。

从RPC的编程术语来说,我们称这个匹配逻辑为mux,即多路复用。于是,我们就发现了http标准库中的2大优化点:

  1. 更灵活的URL匹配逻辑
  2. mux支持HTTP Method的区分

2.解析参数

解析参数可以分解为3个问题:

  1. 参数来源于哪?如URL/Header/Body
  2. 参数要怎么解析?如json/form/xml
  3. 参数要解析到那个Go结构体?

有经验的朋友能深刻体会其中的繁琐(这部分工作不难,但很费开发与排查问题的时间)。比如说,在写业务层代码时,发现某个参数没有解析到,我们要分析的点非常多,包括协议问题、字段名称、字段类型、解析的工具库等等。

对于程序员来说,当然是希望尽可能地将这部分高度重复的工作进行简化,提升效率。

3.返回结果

返回数据的代码看过去很简单,就是将数据序列化后返回。

但是,难点在于异常情况下的处理:例如,当handler中某个逻辑出错时,我们要怎么返回数据呢?最常见的方案,就是增加一个特殊的字段进行标记,如错误码errno,不为0时表示错误,为0时才表示正确、再去解析数据结构。

核心问题

上述3点没有什么技术上的难度,但在稍微复杂点的web程序时,会遇到什么问题呢?我们再次一起看看handler这个函数签名:

1
handler func(http.ResponseWriter, *http.Request)

如果你随意编写一个handler,也可以轻松编译通过,例如:

1
2
3
func(writer http.ResponseWriter, request *http.Request) {
return
}

因此,最主要的问题是在于:没办法对开发者在编写HTTP接口时,提供一定的强制规范

质量低 - 容易失误

由于handler这层的无法强制性地标准化,容易出现下限很低的失误,例如:

  1. 用错了请求的数据结构,尤其是ctrl+c/ctrl+v
  2. 返回的数据结构没有强限制,完全可以自定义

效率低 - 重复编码

对于解析参数和返回数据,往往需要大量的重复编码。这部分虽然可以通过封装一些库来缓解,但每个handler都至少仍有2个调用:

  • 解析数据的函数,如Bind
  • 返回数据的函数,如WriteResponse

而对于有异常情况的,如发生error,WriteResponse的调用量相应增加

标准化低 - 内部实现各异

由于handler内的 解析请求返回响应 没有任何代码限制,所以可以采用任意开源或自研的组件。

这些组件的实现各异,一旦扩散后很难收敛,很容易遇上不兼容的问题:

  • 如果只是程序内实现的不兼容,还可以通过修改完成兼容
  • 但如果多个调用方发生了不兼容,那就很难控制了

测试难 - 单测难覆盖

整个handler的可测试性是很低的,构造一个单测堪比写一大串业务代码,调试时很复杂。

所以,开发者往往更愿意靠 启动go程序+postman发请求 这样相对重量级的接口测试。

更大规模下的问题

实现与接口文档的不一致

随着平台的迭代,我们经常会去修改一些接口。

但在Go语言中,它无法直接生成接口文档(如swagger文档)。普遍的方案会利用注释,但注释依旧无法和代码里的实现保证强一致性(如接口文档为OrderV1,但实际已经升级到了OrderV2)。

调用方的开发工作

对于接口调用方,有4个工作是必须做的:

  1. 定义URL/方法等
  2. 定义请求的数据结构
  3. 定义返回的数据结构
  4. 拼接处一个HTTP请求

每个服务调用方,都需要重复地做这部分的工作。

这个问题可以通过统一建设公共库(SDK)来减轻,但SDK库如何与服务端的实现保证一致,是比较复杂的问题:例如新增了一个url+handler的处理逻辑,如何保证SDK会自动更新?

业务逻辑的兼容性问题

业务逻辑往往是复杂的,我们更多的时间是投入在业务逻辑处理上,但传统的方式容易出现各种兼容性问题,比如:

开发者可能只是发现某个内部bug,改了某个字段的数据结构,但却导致所有调用方整个解析失败(如json.Unmarshal)。

总结

也许,有的朋友看了上述问题,会觉得不以为然:如果能搞好工具库和标准,以上问题都能解决

没错,上述问题都不致命,否则业界也早就出现明确的标准了。但是我们要考虑到两点:

  1. 人员的不确定因素:不同的能力阶段、人员流动性
  2. 效率与质量:将开发时间更多地投入到业务逻辑上,提升质量

就像是你要从上海到北京出差,你当然可以自驾、歪歪扭扭地沿着高速公路到达目的地,有很高的选择自由度;但有了更快的高铁路线,何乐而不为呢?毕竟,从出差这件事来看,最重要的是保证准时地到达目的地,

那么RPC的“高铁方案”是怎么样的呢?下一节我们继续展开。

Github: https://github.com/Junedayday/code_reading

Blog: http://junes.tech/

Bilibili: https://space.bilibili.com/293775192

公众号: golangcoding

二维码