Golang Beego框架之WebIM例子分析

beego框架算是golang比较成熟的一个框架了，最近看了下这个框架其中的一个在线聊天室的例子，觉得还是有很多可以学习借鉴的地方，所以就总结下。

这个例子的源码在这里，该例子配合bee工具可以很简单的进行运行。

首先看下这个项目的结构：

标准的beego框架，各个文件夹包含了不同的功能。

然后我们从main.go（这里是WebIM.go）看起：

package main

import (
    "github.com/astaxie/beego"
    "github.com/beego/i18n"

    "github.com/beego/samples/WebIM/controllers"
)

const (
    APP_VER = "0.1.1.0227"
)

func main() {
    beego.Info(beego.BConfig.AppName, APP_VER)

    // Register routers.
    beego.Router("/", &controllers.AppController{})
    // Indicate AppController.Join method to handle POST requests.
    beego.Router("/join", &controllers.AppController{}, "post:Join")

    // Long polling.
    beego.Router("/lp", &controllers.LongPollingController{}, "get:Join")
    beego.Router("/lp/post", &controllers.LongPollingController{})
    beego.Router("/lp/fetch", &controllers.LongPollingController{}, "get:Fetch")

    // WebSocket.
    beego.Router("/ws", &controllers.WebSocketController{})
    beego.Router("/ws/join", &controllers.WebSocketController{}, "get:Join")

    // Register template functions.
    beego.AddFuncMap("i18n", i18n.Tr)

    beego.Run()
}

虽然是从该文件看起，但是并非是从该文件开始执行的，而是import中的package中的init方法执行的，有关init方法的执行顺序可以看这里，好了，先收回来看这个文件，WebIM.go中主要是定义了路由，那我们来看下路由的细节：

请求/会跳转到controllers.AppController对应的Get方法，该方法直接返回welcome.html页面，页面如下：

然后在此处输入用户名并选择使用的连接技术，用户名很简单就是用户ID，使用的技术这里采用长轮询或者WebSocket的方式，稍后会专门谈谈这两种方式。

点击‘进入聊天室’后，就会请求/join，同时会携带两个参数，一个是用户名，另外一个参数是连接的方式（技术），该请求为post请求，根据beego.Router("/join", &controllers.AppController{}, "post:Join")可知，该请求会被AppController的Join方法：

func (this *AppController) Join() {
    // Get form value.
    uname := this.GetString("uname")
    tech := this.GetString("tech")

    // Check valid.
    if len(uname) == 0 {
        this.Redirect("/", 302)
        return
    }

    switch tech {
    case "longpolling":
        this.Redirect("/lp?uname="+uname, 302)
    case "websocket":
        this.Redirect("/ws?uname="+uname, 302)
    default:
        this.Redirect("/", 302)
    }

    // Usually put return after redirect.
    return
}

该方法首先获取到post请求的两个参数，然后判断用户名是否为空，若为空重新跳回欢迎页面，如不为空，开始判断当前连接方式（技术）是什么，根据不同分别跳转/lp?uname=uname和/ws?uname=uname，然后WebIM.go中的路由路由就会根据本次请求的方式分别请求不同的控制器，/lp将会请求controllers.LongPollingController{}的Join方法，/ws将会请求controllers.WebSocketController{}默认的Get方法，这两种请求的方式返回的前端页面是相同的，但是后台的处理是不同的。

那么，我们先区分一下这两种获取数据的方式有什么不同，首先是websocket的方式，websocket实现了服务器端主动向客户端浏览器进行消息的推送，实现了消息的同步，实质上是建立了一条socket连接，通过该链接进行通信，而长轮询则依旧是采用http的方式去请求数据，区别于轮询的方式，轮询是客户端浏览器每隔一段时间发起一次http请求，而长轮询则是发起一次请求，然后服务器端将该连接保持住（hold，暂时不拒绝也不响应），等到服务器端到达指定的情况（收到另一个消息）将该消息作为内容进行响应，客户端收到响应后再次发起长轮询请求，这样就能保证每次有新的消息到达的时候都能及时的收到响应。

在这个WebIM中是通过chan来维持长轮询的，在介绍维持长轮询这块之前，我们按次序来看下在这个例子中使用的数据结构models：

archive.go

package models

import (
    "container/list"
)

//用int类型重新定义客户端产生的事件类型
type EventType int

//三种事件类型：加入、离开、消息
const (
    EVENT_JOIN = iota
    EVENT_LEAVE
    EVENT_MESSAGE
)

//定义事件结构（事件类型、用户名、事件、内容）
type Event struct {
    Type      EventType // JOIN, LEAVE, MESSAGE
    User      string
    Timestamp int // Unix timestamp (secs)
    Content   string
}

//用来保存服务器上能够保存的消息记录，保存最新的20条
const archiveSize = 20

// 事件归档保存
var archive = list.New()

// 将一个新的事件保存在archive中，若事件的个数已经大于等于20则删除第一个，只保留最新的20个
func NewArchive(event Event) {
    if archive.Len() >= archiveSize {
        archive.Remove(archive.Front())
    }
    archive.PushBack(event)
}

// 根据传过来的时间戳返回该时间戳之后的所有事件消息
func GetEvents(lastReceived int) []Event {
    events := make([]Event, 0, archive.Len())
    for event := archive.Front(); event != nil; event = event.Next() {
        e := event.Value.(Event)
        if e.Timestamp > int(lastReceived) {
            events = append(events, e)
        }
    }
    return events
}

看完了models才想起来上面还说到WebIM.go并不是程序执行的其实，而应该是import包时调用的init方法，由于此处导入了github.com/beego/samples/WebIM/controllerspackage，所以我们来看下controllers中的init方法。

在app.go中的init方法如下：

func init() {
    // 从配置文件中获取语言类型列表
    langTypes = strings.Split(beego.AppConfig.String("lang_types"), "|")

    // 根据语言类型加载语言环境文件
    for _, lang := range langTypes {
        beego.Trace("Loading language: " + lang)
        if err := i18n.SetMessage(lang, "conf/"+"locale_"+lang+".ini"); err != nil {
            beego.Error("Fail to set message file:", err)
            return
        }
    }
}

在chatroom.go中init方法如下：

func init() {
    go chatroom()
}

该方法直接启动一个goroutine，让其独立运行，下面我们就来看下这个chatroom方法的作用。

首先在chatroom.go中定义了一系列的变量，如：subscribe、unsubscribe、publish、waitingList、subscribers，其中subscribe、unsubscribe、publish都是chan类型，三个变量代表的含义分别是：订阅者，未订阅者，以及要进行发布的消息，之所以设置为缓冲为10的chan，这是为了应对同时多个客户端发起的请求事件。watingList表示的是当前等待长轮询的list，该list中存储的类型为无缓冲的chan类型，也就是通过这样一个无缓冲的chan类型来保证了长轮询的“保持（hold）”：当有长轮询请求到达时，该list添加一个空的chan，然后从该ch中读取数据，由于刚才是添加的空的chan，所以这里直接从chan中读取数据自然不能读取到，那么执行到此处的无缓冲的chan自然就会阻塞，这也就是长轮询可以保持住的原因！

那么，我们在看下当事件触发的情况下，长轮询返回响应的情况：

    // Notify waiting list.
    for ch := waitingList.Back(); ch != nil; ch = ch.Prev() {
        ch.Value.(chan bool) <- true
        waitingList.Remove(ch)
    }

当有事件触发时，此处循环waitingList，往list中的每个chan填入元素true，那么这时在上面使用chan读取数据来保持长轮询的部分将会被激活（启动），此时也将返回响应信息，完成一次长轮询的过程，进而开始下次的长轮询。此处使用chan来保持长轮询还是设计的很巧妙的！

我们再看下使用websocket方式来进行通信的场景。

wobsocket和longpolling共用了较多的数据，如所有的事件存档，当有新的websocket用户加入时，会调用如下函数：

websocket.go

// Join method handles WebSocket requests for WebSocketController.
//当有新的用户通过websocket方式加入时，调用执行该函数
func (this *WebSocketController) Join() {
    //获取加入的用户的用户名并进行是否为空的校验
    uname := this.GetString("uname")
    if len(uname) == 0 {
        this.Redirect("/", 302)
        return
    }

    // 从http请求升级到WebSocket。
    ws, err := websocket.Upgrade(this.Ctx.ResponseWriter, this.Ctx.Request, nil, 1024, 1024)
    if _, ok := err.(websocket.HandshakeError); ok {
        http.Error(this.Ctx.ResponseWriter, "Not a websocket handshake", 400)
        return
    } else if err != nil {
        beego.Error("Cannot setup WebSocket connection:", err)
        return
    }

    // 将该请求转换成的websocket联通用户名一起加入chatroom
    Join(uname, ws)
    defer Leave(uname)

    // 循环从websocket中读取数据，无数据时阻塞，有数据到达时往publish chan中添加事件，从而引起其他事件的响应
    for {
        _, p, err := ws.ReadMessage()
        if err != nil {
            return
        }
        publish <- newEvent(models.EVENT_MESSAGE, uname, string(p))
    }
}

websocket.go中还有如下函数：

func broadcastWebSocket(event models.Event) {
    //将要进行广播的事件json格式化
    data, err := json.Marshal(event)
    if err != nil {
        beego.Error("Fail to marshal event:", err)
        return
    }

    //循环遍历通过websocket方式加入聊天室的用户，广播该事件（单条）
    for sub := subscribers.Front(); sub != nil; sub = sub.Next() {
     
        // Immediately send event to WebSocket users.
        ws := sub.Value.(Subscriber).Conn
        //若是通过longpolling方式加入的，则ws为nil
        if ws != nil {
     
            //如下是将事件消息写入websocket中，若写入失败（返回err）则证明客户端已关闭websocket，此时从订阅列表中将该用户删除
            if ws.WriteMessage(websocket.TextMessage, data) != nil {
                // User disconnected.
                unsubscribe <- sub.Value.(Subscriber).Name
            }
        }
    }
}

在chatroom.go中源码中有一段如下：

chatroom.go

//当有新的事件消息到达时，执行如下
case event := <-publish:
            // Notify waiting list.
            for ch := waitingList.Back(); ch != nil; ch = ch.Prev() {
                ch.Value.(chan bool) <- true
                waitingList.Remove(ch)
            }

            broadcastWebSocket(event)
            models.NewArchive(event)

            if event.Type == models.EVENT_MESSAGE {
                beego.Info("Message from", event.User, ";Content:", event.Content)
            }

此时，我发现了如下的问题，这里的chatroom实际上已经是一个单独的goroutine，即就是此处的添加消息事件和长轮询的响应处理函数是两个goroutine，所以这里就存在了同步的问题，我们先来看下这里有的两个goroutine的执行情况：

从图中可以看出，当chatroom的goroutine中收到事件消息时，首先是激活了长轮询的等待，然后依次是广播事件、添加事件消息到消息归档中，而在另一个goroutine中激活了长轮询的等待之后立刻就会去获取lastReceived之后新的事件消息，这里就有可能产生不同步，即就是事件消息在chatroom的goroutine中还未加入事件消息归档，这里就开始去获取，这样的话当然是不能获取到消息，也就是返回的消息响应为空！虽然这样理解但是并非每次都是这样，而且即便此时此刻返回的响应消息为空，依旧不会影响消息的获取，因为当前的请求返回空之后，立刻回发起一次新的fetch请求，这次请求的lastReceived依旧是上次请求的timestamp，所以消息不会遗漏，但是，消息事件响应的灵敏度就不够高，需要发起两次请求。

为了测试，我添加了如下的代码，用来模拟chatroom的goroutine运行较慢的情况：

            // Notify waiting list.
            for ch := waitingList.Front(); ch != nil; ch = waitingList.Front() {
                ch.Value.(chan bool) <- true
                waitingList.Remove(ch)
            }
            time.Sleep(time.Second * 2)

            broadcastWebSocket(event)
            models.NewArchive(event)

如下是收到空的事件消息的情况：

从请求中也可以看出，当返回响应消息为空时，下次请求的lastRecived依旧为上次请求的时间戳，所以消息并不会丢失。

关于两个goroutine的运行差不多就这样了，在这个例子中，源码的作者有这样一处小失误，代码如下：

            // Notify waiting list.
            for ch := waitingList.Back(); ch != nil; ch = ch.Prev() {
                ch.Value.(chan bool) <- true
                waitingList.Remove(ch)
            }

本来是想要循环遍历所有的长轮询的等待队列，遍历之后删除节点，但是由于循环条件出错，并不能达到预想的情况，而是遗漏了很多的节点。修改如下：

            // Notify waiting list.
            for ch := waitingList.Front(); ch != nil; ch = waitingList.Front() {
                ch.Value.(chan bool) <- true
                waitingList.Remove(ch)
            }

关于前端是如何请求以及后台模板的响应这里并没有介绍，还有前端的websocket以及长轮询自动发起的请求还需要自己去体会。。。

好了，就这些了，算是对这个例子的一点认识！！！