19 Go Web 框架(二):框架技术详解

一、 net/http包够用吗?

Go的net相关标准包提供web开发的大多数实现支持,如果你的项目的路径端点在十个以内,如一个简单的企业网站,这当然是够用的。但如果你的项目是构建一个大型电商网站,有成千上万个页面的路径端点,如下:

GET   /goods/:id
POST  /order/:id
DELTE /goods/:id
GET   /goods/:id/name
...
GET   /goods/:id/recommend

在这种情况下,如果只是用net/http包构建,那你不仅要手写url参数解析器,且单单写handler函数就足以让你奔溃。所以对于大多数中大型项目而言,使用框架技术开发是明智之举。

根据经验,只要你的路由带有参数,并且这个项目的API数目超过了10,就尽量不要使用net/http中默认的路由。在Go开源界应用最广泛的router是httpRouter,很多开源的router框架都是基于httpRouter进行一定程度的改造的成果。

二、Web框架技术

现代Web技术大多基于HTTP协议构建,所谓Web框架技术,其本质是在框架底层对HTTP进行有设计的再度封装,最基本的为对Request和对Response处理的封装,除此也包括路由调度,请求参数校验,模板引擎等。再附加一些加速开发和模块管理的套件,如:中间件、MVC分层设计、数据库IO处理等开发套件。使用框架的目的在于屏蔽一些通用的底层编码,封装对用户友好的调用方法,让你把精力集中在业务模块的开发。当然这种封装有利有弊。利在于你不用重复造轮子,有专业的框架团队帮你维护比较规范和安全的底层逻辑,因为框架规范,团队开发中也比较易于沟通;弊在于框架的通用设计有可能不适合你的产品特性,且如果你不深入研究框架底层实现,有可能在项目开发过程中出现一些不可控的bug,这意味着如果你使用一种框架,团队中必须有深入理解该框架的成员,才能让项目开发的进展在可控的范围内。

1. 框架类型:

开源社区有许许多多不同类型的web框架,帮助用户实现快速上手开发,根据不同的项目需求,你可能需要构建API,有可能构建web页面服务,也有可能构建分布式的微服务,这就区分出许多框架类型,以下为框架类型的划分及热度较高的开源项目:

  • Router型框架
    • Ace: 快速开发的Web框架。
    • api2go: Go的JSON API实现。
    • Gin: 一个微框架,类似Martinier的API,重点是小巧、易用、性能好很多,也因为 httprouter 的性能提高了40倍。
    • Goat: Go中的简约REST API服务器
    • goMiddlewareChain: 一个像express.js的中间件调用链框架。
    • Hikaru: 支持独立部署和谷歌AppEngine
    • Hitch: 将 httprouter, httpcontext, 和中间件 捆绑在一起。
    • httpway: 具有httprouter上下文的简单中间件扩展和具有正常关闭支持的服务框架
    • kami: 使用 x/net/context的小型Web框架。
    • Medeina: 灵感来自Ruby的 Roda 和Cuba。
    • Neko: 一个轻量级Web应用程序框架。
    • River: 一个简单轻巧的REST服务框架。
    • Roxanna:httprouter的合并,更好的日志记录和热重载。
    • siesta:具有上下文的可组合HTTP处理程序。
    • xmux: xmux is a httprouter fork on top of xhandler (net/context aware) aware)

基于httpRouter进行简单的封装,然后提供定制的中间件和一些简单的小工具集成比如gin,主打轻量,易学,高性能。

  • 迁移型框架
    • Beego:一个快速开发 Go 应用的 HTTP 框架,他可以用来快速开发 API、Web 及后端服务等各种应用,是一个 RESTful 的框架,主要设计灵感来源于 tornado、sinatra 和 flask 这三个框架,但是结合了 Go 本身的一些特性(interface、struct 嵌入等)而设计的一个框架。beego 是基于八大独立的模块构建的,是一个高度解耦的框架。设计之初就考虑功能模块化,用户即使不使用 beego 的 HTTP 逻辑,也依旧可以使用这些独立模块。
    • Iris:Iris的理念是为HTTP提供强大的工具,使其成为单页面应用程序,网站,混合或公共HTTP API的理想解决方案。

借鉴其它语言的编程风格,使用MVC开发模式的框架,例如beego、Iris-go等,这种框架方便从其它语言迁移过来的程序员快速上手,快速开发,很多PHP、JAVA程序员对这种框架更容易上手。

  • 代码生成型框架
    • Goa:Goa采用不同的方法来构建服务,使用简单的Go DSL 来描述服务API 的设计。Goa使用描述生成专门的服务帮助程序代码,客户端代码和文档。Goa可以通过插件扩展,例如 goakit插件生成利用Go套件库的代码。

使用GO DSL描述来生成服务或API代码,支持数据库schema设计,插件设计,大部分代码可直接生成。goa就是这种类型的框架,它着重于构建微服务和API的系统。如果你玩过Yii2或Laravel,你会感觉这种框架开发的套路很熟悉。

  • 微服务型框架
    • Goa:以上。
    • go-micro:Go Micro提供了分布式系统开发的核心要求,包括RPC、事件驱动的异步通信、消息编解码、基于服务发现的负载均衡以及可插拔的插件机制。
    • go-kit:Go kit是一个编程工具包,用于在Go中构建微服务(或优雅的整体)。解决了分布式系统和应用程序架构中的常见问题,因此你可以专注于开发业务。

微服务架构在近年来越来越盛行,在容器化服务的时代,微服务化的应用也代表着未来,go在微服务的开发方面也有得天独厚的优势,这类框架有go-micro、go-kit等,其中go-micro更像是构建微服务的框架,而go-kit更像是微服务开发的工具集。

2. 框架设计解析

Go在2009年才诞生,迄今也就十年历史,在框架技术方面很多都是借鉴于其他语言的框架设计经验,所以在很多使用框架开发的项目中beego很流行,主要是因为人们更熟悉MVC这种开发套路,但如果你使用beego开发过你会发现有些许别扭,相较于MVC的框架,许多Gopher更喜欢使用轻量级的Router型框架构建REST API,或使用微服务框架搭建运行于容器的应用。或许它更符合Go Web开发的设计理念。至于如何选择框架,这得考虑产品的特性和团队的成员技术栈了,没有唯一答案,适合的才是最好的。

下面我们来解析一下大多数框架设计的共同特性吧:

2.1 HTTP封装

Web系统的本质就是对网络通信协议的应用设计,大体上基于HTTP协议进行应用的封装,如许多RESTful风格的API框架,就是完全贴合HTTP协议而设计的。HTTP的一次交互可抽象为Request(请求)和Response(响应),在上一篇中我们了解了Request和Response的具体结构和信息,Request包含八种请求Method来表明客户对资源的操作方式,并赋予请求头、请求参数等信息(在此抽象概述先忽略其它请求报文的处理),而Response则包含服务端在接收到用户请求并进行业务处理后的响应信息,如响应头、状态码、响应体等(在此抽象概述先忽略其他响应报文内容)。这是Web服务端和客户端交互的简单抽象。go的标准库net/http包已实现这些基本的处理,大多web框架根据各自设计的特性进行Request和Response的深度封装,使其对用户开发更友好,或增强其他处理的特性等。

一般框架会对Request和Response进行接口设计或直接设计为结构体实现,在服务中的Handler处理器进行传递,这是net/http包原生的处理方法,但多数框架会把Request和Response以及其他的附加结构封装到一个统一的Context接口或结构体,在服务中的Handler处理器进行传递,如gin:

type Context struct {
    writermem responseWriter
    Request   *http.Request
    Writer    ResponseWriter

    Params   Params
    handlers HandlersChain
    index    int8

    engine *Engine

    // Keys is a key/value pair exclusively for the context of each request.
    Keys map[string]interface{}

    // Errors is a list of errors attached to all the handlers/middlewares who used this context.
    Errors errorMsgs

    // Accepted defines a list of manually accepted formats for content negotiation.
    Accepted []string
}

像你以上看到的,许多应用框架会把一次HTTP的交互中的所有要素统一抽象到一个上下文Context中,由路由调度指派的Handler处理器接收处理,于是你会看到gin框架的做法,也为多数web框架的做法:

package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.Default()
    //将访问路径/ping的请求的处理指派到一个handler匿名函数,传递的是*gin.Context。
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })
    r.Run() // listen and serve on 0.0.0.0:8080
}
2.2 路由设计

在Web交互中,客户端都是通过URL(统一资源定位符)对服务端资源进行HTTP 请求的,一个URL包含资源的请求路径,该路径应由系统路由(router)调度到请求处理器。在常见的Web框架中,router是必备的组件。Go语言圈子里router也时常被称为http的multiplexer。

net/http包内置的ServeMux来完成简单的路由功能,如果开发Web系统对路径中没有带参数要求的话,用net/http标准库中的mux就可以了,但现实并没那么简单,一个稍微复杂的项目都有路径划分及携带参数的要求,特别是RESTful风格的API设计,这就需要对请求路径的URL进行路由调度设计。

在RESTful中除了GET和POST之外,还使用了HTTP协议定义的几种其它的标准化语义。具体包括:

const (
    MethodGet     = "GET"
    MethodHead    = "HEAD"
    MethodPost    = "POST"
    MethodPut     = "PUT"
    MethodPatch   = "PATCH" // RFC 5789
    MethodDelete  = "DELETE"
    MethodConnect = "CONNECT"
    MethodOptions = "OPTIONS"
    MethodTrace   = "TRACE"
)

来看看RESTful中常见的请求路径:

GET /repos/:owner/:repo/comments/:id/reactions
POST /projects/:project_id/columns
PUT /user/starred/:owner/:repo
DELETE /user/starred/:owner/:repo

这是常见的几个RESTful API设计。RESTful风格的API重度依赖请求路径。会将很多参数放在请求URI中。除此之外还会使用很多并不那么常见的HTTP状态码。

如果我们的系统也想要这样的URI设计,使用http包的ServeMux显然不够。

较流行的开源go Web框架大多使用httprouter,或是基于httprouter的变种对路由进行支持。前面提到的github的参数式路由在httprouter中都是可以支持的。

因为httprouter中使用的是显式匹配,所以在设计路由的时候需要规避一些会导致路由冲突的情况,例如:

//conflict:
GET /user/info/:name
GET /user/:id

//no conflict:
GET /user/info/:name
POST /user/:id

简单来讲的话,如果两个路由拥有一致的http方法(指 GET/POST/PUT/DELETE)和请求路径前缀,且在某个位置出现了A路由是wildcard(指:id这种形式)参数,B路由则是普通字符串,那么就会发生路由冲突。路由冲突会在初始化阶段直接panic。

除了正常情况下的路由支持,httprouter也支持对一些特殊情况下的回调函数进行定制,例如404的时候:

r := httprouter.New()
r.NotFound = http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("oh no, not found"))
})
或者内部panic的时候:

r.PanicHandler = func(w http.ResponseWriter, r *http.Request, c interface{}) {
    log.Printf("Recovering from panic, Reason: %#v", c.(error))
    w.WriteHeader(http.StatusInternalServerError)
    w.Write([]byte(c.(error).Error()))
}

目前开源界较流行的Web框架gin使用的就是httprouter的变种。

2.3 中间件

我们来看看现实开发的场景,假如你正在编写一处产品提出的业务需求,和往常一样,你使用一个路径绑定一个Handler处理器实现业务编码,而正在这时,你的开发主管为了统计每个业务中的耗时任务,要求开发成员在业务代码中插入耗时计算的逻辑,你照做了;再过一段时间,你的开发主管为了收集用户的行为数据,要求开发成员在用户的业务逻辑上安插日志记录,以供后期离线计算,你也照做了;后来随着业务不断扩大,系统业务衍生出了“大会员”子系统,需要对符合要求的用户进行鉴权并过滤,要求开发人员在每个业务处理做权限控制,这时你崩溃了,系统已经随着业务发展变得越来越复杂,而且掺杂了各种业务和非业务的逻辑代码,你还继续一个一个改吗?很显然你已经陷入代码泥潭!

所谓中间件,是在实际处理用户业务逻辑的生命周期中,在对应的节点安插逻辑处理,可以在核心业务逻辑前或后,是剥离非业务逻辑的重要系统组件。

中间件设计像是一个调用链,context在链中各节点传递,各节点进行各自的功能处理:

19 Go Web 框架(二):框架技术详解_第1张图片
中间件.png

看上图大家就明白,在核心业务的前后,将非业务逻辑剥离出来,实现预先处理和后置处理的效果,这就是中间件的本质。

实现中间件思路非常简单,Go的高阶函数编程可以非常容易的实现中间件设计,还是以Gin的中间件设计为例:

//编写一个Logger中间件,该中间件统一返回一个HandlerFunc,每个HandlerFunc都传递Context。
func Logger() gin.HandlerFunc {
    return func(c *gin.Context) {
        t := time.Now()

        // 设置 example 变量
        c.Set("example", "12345")

        //请求前...

        //执行下一层调用节点,根据Use()方法的调用顺序执行,执行完所有中间件后再进入核心业务Handler。
        c.Next()

        //请求后...
        latency := time.Since(t)
        log.Print(latency)

        // 获取发送的 status
        status := c.Writer.Status()
        log.Println(status)
    }
}

func main() {
    s := gin.New()
    //使用中间件调用Use()方法即可
    s.Use(Logger())

    s.GET("/test", func(c *gin.Context) {
        example := c.MustGet("example").(string)

        // 打印:"12345"
        log.Println(example)
    })

    // 监听并在 0.0.0.0:8080 上启动服务
    s.Run(":8080")
}
2.4 请求参数校验
19 Go Web 框架(二):框架技术详解_第2张图片
请求参数校验波动拳.jpg

你或许看过上图,这是社区中嘲笑PHP校验请求参数的例子,实际上,这种做法与语言无关,很多没有设计的参数校验都是这种粗糙的写法。这种if-else风暴组织的代码无疑是丑陋的。从代码的易读性和逻辑性角度看,都应该对条件分支进行重构,其实许多if嵌套都可重构为顺序条件结构,来提高代码的优雅程度,在此不便展开。回到正题,其实在Handler写一大堆参数校验的代码是挺难看的,既然参数校验是每个请求必须的流程,有没有什么方法可以把参数校验分离出Handler处理器呢?答案是Validator验证器设计。

从设计的角度讲,我们一定会为每个请求都声明一个结构体。

这里我们引入一个新的validator库:https://github.com/go-playground/validator

以下为使用示例:

import "gopkg.in/go-playground/validator.v9"

type RegisterReq struct {
    // 字符串的 gt=0 表示长度必须 > 0,gt = greater than
    Username       string   `validate:"gt=0"`
    // 同上
    PasswordNew    string   `validate:"gt=0"`
    // eqfield 跨字段相等校验
    PasswordRepeat string   `validate:"eqfield=PasswordNew"`
    // 合法 email 格式校验
    Email          string   `validate:"email"`
}

validate := validator.New()

func validate(req RegisterReq) error {
    err := validate.Struct(req)
    if err != nil {
        doSomething()
        return err
    }
    ...
}

这样就不需要在每个请求进入业务逻辑之前都写重复的validate()函数了。本例中只列出了这个校验器非常简单的几个功能。

我们试着跑一下这个程序,输入参数设置为:

//...

var req = RegisterReq {
    Username       : "Fun",
    PasswordNew    : "abc12138",
    PasswordRepeat : "ABC12138",
    Email          : "[email protected]",
}

err := validate(req)
fmt.Println(err)

// Key: 'RegisterReq.PasswordRepeat' Error:Field validation for
// 'PasswordRepeat' failed on the 'eqfield' tag

错误信息可以针对每种tag定制,各位可查阅各验证器文档,开源社区有许多验证器的独立项目,也可以参考各框架的验证器实现,如有特殊需求也可以自定义验证器。

2.5 数据库交互

在《Go进阶系列》前三篇中,我们已经了解Go操作数据库的大体实现方法,对关系型数据库的操作,主要基于标准库的database/sql包,开源社区也有许多对sql包的再度封装项目,但这些库的使用许多都是对sql原生语句的操作,使用这些包的项目中,你会发现许多非常相似的sql语句,当项目比较大时会充斥许多冗余代码。于是为了提高项目生产效率,许多框架或独立开源项目都提供了ORM或SQL Builder的支持。在进阶系列开篇我们简单使用了gorm。

数据库交互在Web系统中可为是标配组件,因为数据持久化的场景随处可见,在其他语言的框架中,许多框架都内置了数据库交互组件,如PHP的Laravel、Yii等,数据访问层都是框架的标配,但许多静态语言的框架中,数据访问层是独立的框架,如JAVA的Hibernate,框架的设计依赖于语言的特点,由于Go包管理的特点,Go的框架中大部分数据库访问层是独立的,类似在Go Web框架中Router型框架占多数,它们只专注于处理HTTP相关的核心部分,其他的由更专业的数据访问层框架来做,如gorm、xorm等ORM框架,然而有些迁移型框架也包揽数据访问层,如beego、goa等,但这种框架的数据访问层也是独立的模块,是可独立使用的。

Go的数据访问层框架相对比较自由,数据访问层的库大体分三种:

  • 基于database/sql进行再度封装:如sqlx;
  • ORM框架:如gorm、xorm、beego/orm;
  • SQL Builder:如 gendry、 goqu
ORM 利弊

使用ORM框架的项目,基本已经屏蔽了SQL语句的编写,所有的数据库交互都使用对象映射的方式,用操作对象替代SQL语句,这无疑对OOP程序员是福利。

ORM的目的就是屏蔽掉DB层,实际上很多语言的ORM只要把你的类或结构体定义好,再用特定的语法将结构体之间的一对一或者一对多关系表达出来。那么任务就完成了。然后你就可以对这些映射好了数据库表的对象进行各种操作,例如save,create,retrieve,delete。至于ORM在背地里做了什么阴险的勾当,你是不一定清楚的。使用ORM的时候,我们往往比较容易有一种忘记了数据库的直观感受。ORM设计初衷就是为了让数据的操作和存储的具体实现所剥离。但是在上了规模的公司的人们渐渐达成了一个共识,由于隐藏重要的细节,ORM可能是失败的设计。其所隐藏的重要细节对于上了规模的系统开发来说至关重要。

SQL Builder 利弊

相比ORM来说,SQL Builder在SQL和项目可维护性之间取得了比较好的平衡。首先sql builer不像ORM那样屏蔽了过多的细节,其次从开发的角度来讲,SQL Builder简单进行封装后也可以非常高效地完成开发:

where := map[string]interface{} {
    "order_id > ?" : 0,
    "customer_id != ?" : 0,
}
limit := []int{0,100}
orderBy := []string{"id asc", "create_time desc"}

orders := orderModel.GetList(where, limit, orderBy)

读写SQL Builder的相关代码都不费劲,也非常接近SQL语句所表达的意思。所以通过代码就可以对这个查询是否命中数据库索引,是否走了覆盖索引,是否能够用上联合索引进行分析了。

说白了SQL Builder是sql在代码里的一种特殊方言,如果你们没有DBA但研发有自己分析和优化sql的能力,或者你们公司的DBA对于学习这样一些sql的方言没有异议。那么使用SQL Builder是一个比较好的选择,不会导致什么问题。

另外在一些本来也不需要DBA介入的场景内,使用SQL Builder也是可以的,例如你要做一套运维系统,且将MySQL当作了系统中的一个组件,系统的QPS不高,查询不复杂等等。

一旦你做的是高并发的OLTP在线系统,且想在人员充足分工明确的前提下最大程度控制系统的风险,使用SQL Builder就不合适了。

小结

使用什么框架作为数据访问层并无同一说法,完全看项目特性,如项目中对SQL的审核非常严格,建议使用基于database/sql封装的库,这样sql语句就会相对透明;如果你的团队不太注重SQL细节且非常注重开发效率,可使用ORM;相对以上两种而言,SQL Builder是比较折中的做法,如果你能控制系统风险,并可牺牲一些高并发性能,SQL Builder是不错的选择。

2.6 分层架构

说到分层,我们就会想到大名鼎鼎的MVC分层设计模式,在前后端分离架构大热前,MVC分层设计的框架可谓大行其道。在那时MVC单体架构可谓“万能”,只要做web项目第一个想到的就是MVC。

在MVC中,为了方便对业务模块进行划分和团队的分工合作,将程序划分为:

  • 控制器(Controller)- 负责转发请求,对请求进行处理。
  • 视图(View) - 界面设计人员进行图形界面设计。
  • 模型(Model) - 程序员编写程序应有的功能(实现算法等等)、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
19 Go Web 框架(二):框架技术详解_第3张图片
MVC.jpeg

但随着移动互联网的兴起,C/S结构的软件又再度兴起,许多web应用的客户端都独立运行,逐渐兴起大前端热潮,MVC中的V从此分离出去,衍生出MC+V的程序结构:

19 Go Web 框架(二):框架技术详解_第4张图片
前后端分离交互图.png

其实在Go兴起的年代,移动互联网应用已是主流,编写Go后端程序很多是不倡导使用MVC模式的,这与go的设计思想不符。但Go是新兴的语言,许多开发者对软件开发的理解还没与Go的设计思想适配,于是乎出现了许多迁移型框架,提供熟悉的设计方法方便其他语言的程序员迁移过来,这当中beego就是代表,其mvc设计是该框架的核心组件,最近兴起的Iris也对MVC结构的程序提供框架级别的支持。对于这种现象其实也有利有弊,利在于让更多的程序员更容易使用GO上手实际项目,弊在于这可能对Go设计Web程序的思想有点误导,Go倡导大道至简,许多更简单高效的Router型框架更切合Go Web的设计思想。

以下提供一个Iris实现MVC的编写示例:

package main

import (
    "github.com/kataras/iris"
    "github.com/kataras/iris/mvc"

    "github.com/kataras/iris/middleware/logger"
    "github.com/kataras/iris/middleware/recover"
)

func newApp() *iris.Application {
    app := iris.New()

    app.Use(recover.New())
    app.Use(logger.New())

    // Serve a controller based on the root Router, "/".
    mvc.New(app).Handle(new(ExampleController))
    return app
}

func main() {
    app := newApp()
    app.Run(iris.Addr(":8080"))
}

// 定义一个控制器
type ExampleController struct{}

// Get serves
// Method:   GET
// Resource: http://localhost:8080
func (c *ExampleController) Get() mvc.Result {
    return mvc.Response{
        ContentType: "text/html",
        Text:        "

Welcome

", } } // GetPing serves // Method: GET // Resource: http://localhost:8080/ping func (c *ExampleController) GetPing() string { return "pong" } // GetHello serves // Method: GET // Resource: http://localhost:8080/hello func (c *ExampleController) GetHello() interface{} { return map[string]string{"message": "Hello Iris!"} } func (c *ExampleController) BeforeActivation(b mvc.BeforeActivation) { anyMiddlewareHere := func(ctx iris.Context) { ctx.Application().Logger().Warnf("Inside /custom_path") ctx.Next() } b.Handle("GET", "/custom_path", "CustomHandlerWithoutFollowingTheNamingGuide", anyMiddlewareHere) } func (c *ExampleController) CustomHandlerWithoutFollowingTheNamingGuide() string { return "hello from the custom handler without following the naming guide" }

相比之下,直接使用Router + Handler的编写方式会简单得多:

package main

import (
    "github.com/kataras/iris"

    "github.com/kataras/iris/middleware/logger"
    "github.com/kataras/iris/middleware/recover"
)

func main() {
    app := iris.New()
    app.Logger().SetLevel("debug")

    app.Use(recover.New())
    app.Use(logger.New())

    // Method:   GET
    // Resource: http://localhost:8080
    app.Handle("GET", "/", func(ctx iris.Context) {
        ctx.HTML("

Welcome

") }) // same as app.Handle("GET", "/ping", [...]) // Method: GET // Resource: http://localhost:8080/ping app.Get("/ping", func(ctx iris.Context) { ctx.WriteString("pong") }) // Method: GET // Resource: http://localhost:8080/hello app.Get("/hello", func(ctx iris.Context) { ctx.JSON(iris.Map{"message": "Hello Iris!"}) }) // http://localhost:8080 // http://localhost:8080/ping // http://localhost:8080/hello app.Run(iris.Addr(":8080"), iris.WithoutServerError(iris.ErrServerClosed)) }

个人建议:不要为了MVC而MVC!在分层设计方面,使用经典的三层架构就可以了,表现层的前端独立分离,后端实现业务逻辑层和数据访问层使软件结构足够精简,更何况我们渐渐进入了容器服务时代,许多大型应用会进化成分布式微服务独立运行,没必要再坚守单体架构的MVC模式了。

2.7 插件机制

所谓插件,是系统中与业务无关的可插拔工具集。插件机制是面向接口编程应用的典范,一个类型的插件可有多个具体的插件实现,系统只对插件接口设计特定的签名方法即可。如缓存插件,RABC插件,日志插件。插件是一种框架的机制设计,当系统允许某些组件是可替换时,把组件编写出插件形式,即编写特定的接口规范,具体的插件实现可由第三方实现,也可由用户自定义。

如Beego框架为了实现某些组件可替换、可由用户自定义,规范了以下插件:

  • gorelic
  • 支付宝 SDK
  • pongo2
  • keenio
  • casbin - RBAC ACL plugins

这种设计有助于用户定制自己的系统。

更极致的使用插件机制的框架像go-micro,它是一个微服务框架。Go Micro为每个分布式系统抽象出接口。因此,Go Micro的接口都是可插拔的,允许其在运行时不可知的情况下仍可支持。所以只要实现接口,可以在内部使用任何的技术。

Go Micro对整个框架的核心组件都做了插件机制的设计,你可以随意选择消息总线插件、RPC通信插件、编解码插件、服务注册插件、负载均衡插件、消息传输插件等。你可以自由选择插件库中的第三方库替换插件,也可以自己实现插件,只要符合框架定义的接口规范。

插件 描述
Broker PubSub messaging; NATS, NSQ, RabbitMQ, Kafka
Client RPC Clients; gRPC, HTTP
Codec Message Encoding; BSON, Mercury
Micro Micro Toolkit Plugins
Registry Service Discovery; Etcd, Gossip, NATS
Selector Load balancing; Label, Cache, Static
Server RPC Servers; gRPC, HTTP
Transport Bidirectional Streaming; NATS, RabbitMQ
Wrapper Middleware; Circuit Breakers, Rate Limiting, Tracing, Monitoring

我们来看一下其实现,以Broker插件为例:

//定义了Broker类型插件的接口
// Broker is an interface used for asynchronous messaging.
type Broker interface {
    Init(...Option) error
    Options() Options
    Address() string
    Connect() error
    Disconnect() error
    Publish(topic string, m *Message, opts ...PublishOption) error
    Subscribe(topic string, h Handler, opts ...SubscribeOption) (Subscriber, error)
    String() string
}

...

我们再看一看一个具体的使用Redis作为Broker的定义:

// Package redis provides a Redis broker
package redis

import (
    "context"
    "errors"
    "strings"
    "time"

    "github.com/gomodule/redigo/redis"
    "github.com/micro/go-micro/broker"
    "github.com/micro/go-micro/codec"
    "github.com/micro/go-micro/codec/json"
    "github.com/micro/go-micro/config/cmd"
)

//此处省略代码...


// broker implementation for Redis.
type redisBroker struct {
    addr  string
    pool  *redis.Pool
    opts  broker.Options
    bopts *brokerOptions
}

// String returns the name of the broker implementation.
func (b *redisBroker) String() string {
    return "redis"
}

// Options returns the options defined for the broker.
func (b *redisBroker) Options() broker.Options {
    return b.opts
}

// Address returns the address the broker will use to create new connections.
// This will be set only after Connect is called.
func (b *redisBroker) Address() string {
    return b.addr
}

// Init sets or overrides broker options.
func (b *redisBroker) Init(opts ...broker.Option) error {
        //此处省略代码...
}

// Connect establishes a connection to Redis which provides the
// pub/sub implementation.
func (b *redisBroker) Connect() error {
    //此处省略代码...
}

// Disconnect closes the connection pool.
func (b *redisBroker) Disconnect() error {
    //此处省略代码...
}

// Publish publishes a message.
func (b *redisBroker) Publish(topic string, msg *broker.Message, opts ...broker.PublishOption) error {
        //此处省略代码...
}

// Subscribe returns a subscriber for the topic and handler.
func (b *redisBroker) Subscribe(topic string, handler broker.Handler, opts ...broker.SubscribeOption) (broker.Subscriber, error) {
    //此处省略代码...

}

// NewBroker returns a new broker implemented using the Redis pub/sub
// protocol. The connection address may be a fully qualified IANA address such
// as: redis://user:secret@localhost:6379/0?foo=bar&qux=baz
func NewBroker(opts ...broker.Option) broker.Broker {
    // Default options.
    bopts := &brokerOptions{
        maxIdle:        DefaultMaxIdle,
        maxActive:      DefaultMaxActive,
        idleTimeout:    DefaultIdleTimeout,
        connectTimeout: DefaultConnectTimeout,
        readTimeout:    DefaultReadTimeout,
        writeTimeout:   DefaultWriteTimeout,
    }

    // Initialize with empty broker options.
    options := broker.Options{
        Codec:   json.Marshaler{},
        Context: context.WithValue(context.Background(), optionsKey, bopts),
    }

    for _, o := range opts {
        o(&options)
    }

    return &redisBroker{
        opts:  options,
        bopts: bopts,
    }
}

可见Redis Broker插件实现了Broker插件类型的接口签名方法。Micro框架就是根据插件机制搭建的,你可以根据插件自由的定制自己的微服务系统。

三、总结

Web技术发展日新月异,框架也层出不穷,面对如此眼花缭乱的技术,我们难免会心生畏惧,那么多框架,那么多技术该如何选择?刚学完这个框架,又有更新更好的框架出来。对于这个问题,我认为我们不应该迷信框架,Web技术的本质是什么,它的底层核心技术是什么?我们只要理解其本质,其他从其衍生的技术都万变不离其宗。Web框架的设计初衷是屏蔽开发底层的逻辑使我们更专注于业务,但由于其屏蔽底层逻辑,我们更需要深入理解它,读懂它。

至此《Go进阶系列》告一段落,之后计划输出《Go实战系列》和《Go高级系列》,如果对你有帮助,不要忘了点个赞或关注本人哈,谢谢!

你可能感兴趣的:(中间件,数据库,java,rest,go)