在Cloud Foundry v1版本中,router作为路由节点,转发所有进入Cloud Foundry的请求。由于开发语言为ruby,故router接受并处理并发请求的能力受到语言层的限制。虽然在v1版本中,router曾经有过一定的优化,采用lua脚本代替原先的ruby脚本,由lua来分析请求,使得一部分请求不再经过ruby代码,而直接去DEA访问应用,但是,一旦router暴露在大量的访问请求下,性能依旧是不尽如人意。
为了提高Cloud Foundry router的可用性,Cloud Foundry开源社区不久前推出了gorouter。gorouter采用现阶段比较新颖的go作为编程语言,并重新设计了原有的组件架构。由于go语言本身的特性,gorouter处理并发请求的能力大大超过了router,甚至在同种实验环境下,性能是原先router的20倍左右。
由于gorouter的高性能,笔者也抱着期待的心态去接触go,当然还有gorouter。本文不会从go语言语法的角度入手gorouter,所以有一些go语言的基础再来看本文,是有必要的。本文主要是对gorouter的源码的简单解读,另外还包含一些笔者对gorouter的看法。
gorouter的程序组织形式
首先,先从gorouter的程序组织形式入手,可见下图:
以下简单介绍其中一些重要文件的功能:
common:common意指通用,所以该文件夹中也是一些比较通识的概念定义,比如varz,healthz,component等,以及关于项目过程的一些基本操作定义。
config:顾名思义,该文件夹中的文件为gorouter组件的配置文件。
log:定义gorouter的log形式定义。
proxy:作为一个代理处理外界进入Cloud Foundry的所有请求。
registry:处理组件或者DEA中应用到gorouter来注册uri的事件,另外还负责请求访问应用时查找应用真实IP,port。
route:主要定义在rigistry中需要使用到的三个数据结构:endpoint,pool和uris。
router:程序的主入口,main函数所在处。
stats:主要负责一些应用记录的状态,还有一些其他零碎的东西,比如定义一个堆。
util:其中一般是工具源码,在这里只负责给gorouter进程写pid这件事。
varz:主要涉及varz信息的处理,其实就是gorouter组件状态的查阅。
router.go: 主要定义了router的数据结构,及其实例初始化的过程,还有最终运行的流程。
gorouter的功能
gorouter的功能主要可以分为三个部分:负责接收Cloud Foundry内部组件及应用uri注册以及注销的请求,负责转发所有外部对Cloud Foundry的访问请求,负责提供gorouter作为一个组件的状态监控。
接受uri注册及注销请求
当Cloud Foundry内一个组件需要提供HTTP服务的时候,那么这个组件则必须将自己的uri和IP一起注册到gorouter处,典型的有,Cloud Foundry中Service Gateway与Cloud Controller通过HTTP建立连接的,另外Cloud Controller也需要对外提供HTTP服务,所以这些组件必须在gorouter中进行注册,以便可以顺利通信或访问。
除了平台级的组件uri注册,最常见的是应用级的应用uri注册,也就是在Cloud Foundry中新部署应用时,应用所在的DEA会向gorouter发送一个uri,IP和port的注册请求。gorouter收到这个请求后,会添加该记录,并保证可以解析外部的URL访问形式。当然,反过来,当一个应用被删除的时候,为了不浪费Cloud Foundry内部的uri资源,Cloud Foundry会将该uri从gorouter中注销,随即gorouter在节点处删除这条记录。
转发对Cloud Foundry的访问请求
gorouter接受到的访问请求大致可以分为三种:外部请求有:用户对应用的访问请求,用户对Cloud Foundry内部资源的管理请求;内部的请求有:内部组件之间通过HTTP的各类通信。
虽然说请求的类型可以分为三种,但是gorouter对于这些请求的操作都是一致的,找到相应的uri,提取出相应的IP和port,然后进行转发。需要注意的是,在原先版本的router中,router只能接收HTTP请求,然而现在gorouter中,已经考虑了TCP连接,以及websocket。
提供组件监控
Cloud Foundry都有自己的状态监控,可以通过HTTP访问。这主要是每个组件在启动的时候,都作为一个component向Cloud Foundry进行注册,注册的时候带有很多关于自身组件的信息,同时也启动了一个HTTP server。
gorouter的初始化及启动流程
Router对象实例的创建与初始化
gorouter的启动过程主要在router.go文件中,在该文件中,首先定义创建一个Router实例的操作并进行初始化,另外还定义了Router实例的开始运行所做的操作。
在router.go文件中,首先需要是Router结构体的定义:
- type Router struct {
- config *config.Config
- ……
- }
type Router struct {
config *config.Config
……
}
随后又定义了Router实例的初始化:
- func NewRouter(c *config.Config) *Router {
- router := &Router{
- config: c,
- }
- ……
- return router
- }
func NewRouter(c *config.Config) *Router {
router := &Router{
config: c,
}
……
return router
}
还有就是定义了Router实例开始运行时所做的操作:
- func (router *Router) Run() {
- ……
- }
func (router *Router) Run() {
……
}
查看源码可以发现Router结构体有以下几个属性:
- config:负责传入gorouter所需要的配置信息
- proxy:一个代理对象,负责完成请求的转发
- mbusClient:作为gorouter中的nats_client,负责与Cloud Foundry的消息中间件NATS通信
- registry:作为gorouter中的注册模块,完成Cloud Foundry中注册或注销请求的处理
- varz:处理gorouter自身作为一个组件的状态监控
- component:gorouter作为一个组件的信息,将自身的信息存入该component对象
在初始化Router对象实例的时候,都是通过传入的config文件中的配置文件来完成初始化。首先通过创建一个Router实例,并初始化该实例的配置信息:
- router := &Router{
- config: c,
- }
router := &Router{
config: c,
}
然后通过读取该配置属性的信息逐步完成Router实例其他属性的初始化。
创建完Router实例对象router之后,router首先做的是创建一个用来与Cloud Foundry中与nats_server建立联机的nats_client: mbusClient:
- router.establishMBus()
router.establishMBus()
然后分别初始化了router对象的registry,varz,proxy:
- router.registry = registry.NewRegistry(router.config, router.mbusClient)
- router.registry.StartPruningCycle()
- router.varz = varz.NewVarz(router.registry)
- router.proxy = proxy.NewProxy(router.config, router.registry, router.varz)
router.registry = registry.NewRegistry(router.config, router.mbusClient)
router.registry.StartPruningCycle()
router.varz = varz.NewVarz(router.registry)
router.proxy = proxy.NewProxy(router.config, router.registry, router.varz)
接着较为重要的是:router.component的创建和执行启动操作:
- router.component = &vcap.VcapComponent{
- Type: "Router",
- Index: router.config.Index,
- Host: host,
- Credentials: []string{router.config.Status.User, router.config.Status.Pass},
- Config: router.config,
- Varz: varz,
- Healthz: healthz,
- InfoRoutes: map[string]json.Marshaler{
- "/routes": router.registry,
- },
- }
- vcap.StartComponent(router.component)
router.component = &vcap.VcapComponent{
Type: "Router",
Index: router.config.Index,
Host: host,
Credentials: []string{router.config.Status.User, router.config.Status.Pass},
Config: router.config,
Varz: varz,
Healthz: healthz,
InfoRoutes: map[string]json.Marshaler{
"/routes": router.registry,
},
}
vcap.StartComponent(router.component)
最后返回了router实例对象之后,创建与初始化工作即完成了。
Router实例对象的运行操作
在Router对象的函数run()中,几乎执行了所有的Router实例对象的运行操作。
1.router对象使用mbusClient周期性地去连接Cloud Foundry的nats_server:
- for {
- err = router.mbusClient.Connect()
- if err == nil {
- break
- }
- log.Errorf("Could not connect to NATS: %s", err)
- time.Sleep(500 * time.Millisecond)
- }
for {
err = router.mbusClient.Connect()
if err == nil {
break
}
log.Errorf("Could not connect to NATS: %s", err)
time.Sleep(500 * time.Millisecond)
}
2.router通过mbusClient将自己作为一个component注册到Cloud Foundry: router.RegisterComponent()
3.router订阅其他组件和应用要注册或注销的消息:
- router.SubscribeRegister()
- router.HandleGreetings()
- router.SubscribeUnregister()
router.SubscribeRegister()
router.HandleGreetings()
router.SubscribeUnregister()
4.router通过SendStartMessage()发布router.start的消息:
- router.SendStartMessage()
- // Send start again on reconnect
- router.mbusClient.OnConnect(func() {
- router.SendStartMessage()
- })
router.SendStartMessage()
// Send start again on reconnect
router.mbusClient.OnConnect(func() {
router.SendStartMessage()
})
5.周期性的刷新活着的应用的app_id。
6.等待一个start信息的发送时间,以保证gorouter内registry映射表中已经有路由信息,以便而后在代理外部请求的时候,可以找到路由表的映射关系。所以,很显然大家可以发现,gorouter会将组件或者应用的uri注册信息存放在该自身的内存中,而gorouter关闭的时候,映射表中所有的信息丢失,每当重启的时候,需要通过发送一个start消息,然后靠订阅该消息的组件重新注册uri,从而获取所有的路由关系。
7.以TCP的方式监听本机的一个端口:
- listen, err := net.Listen("tcp", fmt.Sprintf(":%d", router.config.Port))
- if err != nil {
- log.Fatalf("net.Listen: %s", err)
- }
listen, err := net.Listen("tcp", fmt.Sprintf(":%d", router.config.Port))
if err != nil {
log.Fatalf("net.Listen: %s", err)
}
8.写pid文件:util.WritePidFile(router.config.Pidfile)
9.创建proxy中Server结构体的实例server,并最终一个协程来执行这个server服务于刚才创建的Listen对象:
- server := proxy.Server{Handler: router.proxy}
- go func() {
- err := server.Serve(listen)
- if err != nil {
- log.Fatalf("proxy.Serve: %s", err)
- }
- }()
server := proxy.Server{Handler: router.proxy}
go func() {
err := server.Serve(listen)
if err != nil {
log.Fatalf("proxy.Serve: %s", err)
}
}()
以上便是gorouter的router实例在运行时所需要作的操作,当然其中很多模块在实现功能的时候,还定义了其他的函数辅助实现,几乎都在router.go文件的函数定义部分,代码本身不难理解,可以对源码进行仔细阅读。
registry模块源码分析
registry模块接管的是Cloud Foundry中组件及应用的uri注册或者注销请求。从计算和存储的角度来分析该模块,即可发现该模块完成了请求的处理和自身内存路由表的设计与维护。
首先来分析一下registry的Registry对象:
- type Registry struct {
- sync.RWMutex
- *steno.Logger
- *stats.ActiveApps
- *stats.TopApps
- byUri map[route.Uri]*route.Pool
- table map[tableKey]*tableEntry
- pruneStaleDropletsInterval time.Duration
- dropletStaleThreshold time.Duration
- messageBus mbus.MessageBus
- timeOfLastUpdate time.Time
- }
type Registry struct {
sync.RWMutex
*steno.Logger
*stats.ActiveApps
*stats.TopApps
byUri map[route.Uri]*route.Pool
table map[tableKey]*tableEntry
pruneStaleDropletsInterval time.Duration
dropletStaleThreshold time.Duration
messageBus mbus.MessageBus
timeOfLastUpdate time.Time
}
在该对象中,有两个非常重要的属性byUri和table。
可以看到byUri属性是一个map类型,map的key类型为route.Uri,value类型为*route.pool。那么现在去route/uris.go和route/pool.go中去看一下这些数据结构。uris.go中由定义 type Uri string,那说明它本身就是一个字符串类型,而后可以发现,这是主要域名的形式。而pool类型要稍显复杂,可以理解为是一个路由池,因为在实际情况中,如果DEA上的一个应用由多个实例的话,那么一个uri会对应于多个IP+port的组合。pool拥有一个属性为endpoints,该属性又是一个map类型,key为string,value为Endpoint,具体形式如下:
- type Pool struct {
- endpoints map[string]*Endpoint
- }
type Pool struct {
endpoints map[string]*Endpoint
}
而Endpoint的定义在route/endpoint.go文件中,如下:
- type Endpoint struct {
- sync.Mutex
- ApplicationId string
- Host string
- Port uint16
- Tags map[string]string
- PrivateInstanceId string
- }
type Endpoint struct {
sync.Mutex
ApplicationId string
Host string
Port uint16
Tags map[string]string
PrivateInstanceId string
}
同样的table属性也是map类型,key为tableKey,value为*tableEntry,随后在相同文件中,有者两个属性的定义:
- type tableKey struct {
- addr string
- uri route.Uri
- }
- type tableEntry struct {
- endpoint *route.Endpoint
- updatedAt time.Time
- }
type tableKey struct {
addr string
uri route.Uri
}
type tableEntry struct {
endpoint *route.Endpoint
updatedAt time.Time
}
关于uri的注册,可以参看Resgister函数:
- func (registry *Registry) Register(uri route.Uri, endpoint *route.Endpoint) {
- registry.Lock()
- defer registry.Unlock()
- uri = uri.ToLower()
- key := tableKey{
- addr: endpoint.CanonicalAddr(),
- uri: uri,
- }
- var endpointToRegister *route.Endpoint
- entry, found := registry.table[key]
- if found {
- endpointToRegister = entry.endpoint
- } else {
- endpointToRegister = endpoint
- entry = &tableEntry{endpoint: endpoint}
- registry.table[key] = entry
- }
- pool, found := registry.byUri[uri]
- if !found {
- pool = route.NewPool()
- registry.byUri[uri] = pool
- }
- pool.Add(endpointToRegister)
- entry.updatedAt = time.Now()
- registry.timeOfLastUpdate = time.Now()
- }
func (registry *Registry) Register(uri route.Uri, endpoint *route.Endpoint) {
registry.Lock()
defer registry.Unlock()
uri = uri.ToLower()
key := tableKey{
addr: endpoint.CanonicalAddr(),
uri: uri,
}
var endpointToRegister *route.Endpoint
entry, found := registry.table[key]
if found {
endpointToRegister = entry.endpoint
} else {
endpointToRegister = endpoint
entry = &tableEntry{endpoint: endpoint}
registry.table[key] = entry
}
pool, found := registry.byUri[uri]
if !found {
pool = route.NewPool()
registry.byUri[uri] = pool
}
pool.Add(endpointToRegister)
entry.updatedAt = time.Now()
registry.timeOfLastUpdate = time.Now()
}
其中,lock()函数负责将registry对象上锁,随后的defer语句,表示当整个Register函数执行完毕后,有go语言来完成registry对象的解锁操作。
key为一个tableKey的实例,其中addr为"IP:port"形式的string值,同时创建一个Endpoint类型的endpointToRegister,对于需要注册的(uri,endpoint)组合,首先查看table属性中能都找到键为key的记录,如果找到,那说明该key(实为IP+port,uri的组合)已经存在于table中,所以将table中的记录赋值于endpointToRegister;如果没有找到,那说明该key还未存在于table中,属于一个全新的key,需要在table中相应的记录,则首先用请求中的endpoint赋值给endpointToRegister,然后在通过endpoint创建一个endtry对象,并使用语句:registry.table[key] = entry来实现最终在table中的存储。当gorouter需要解析域名的时候使用的是byUri数据结构,所以在注册的时候也要对byUri进行操作。首先通过请求中的uri来在byUri中查找是否存在该uri的路由表,如果没有找到的话,则需要新建一个路由池pool,在将整个路由池pool,映射到相应的域名上,也就是请求中的uri。随后还需要给该路由池pool添加endpointToRegister整个对象,由于pool的一条记录本身是map类型的,所以在执行添加时,以endpointToPoint的(IP+port)作为该记录的key,整个endpointToRegister作为value。最后再更新一些其他属性。
以上便是Register函数所做的一些工作,Unregister函数做的工作则是一些注销工作。
随后则是一些关于byUri的查找,主要由以下几种类型:
- Lookup(uri route.Uri) 通过uri查找,返回pool.Sample(),其实也就是将pool随机返回一条记录,具体可以查看pool的Sample()函数。
- LookupByPrivateInstanceId(uri route.Uri, p string) 通过 PrivateInstanceID查找,返回pool匹配该PrivateInstanceID的endpoint。
- lookupByUri(uri route.Uri) 通过uri查找,返回整个路由池pool。
以上是关于uri的注册或者注销,另外gorouter还会对路由表进行一定的管理,主要是清理一些很陈旧的路由记录。首先在Router实例对象的初始化中就有陈旧路由信息的剪枝:router.registry.StartPruningCycle(),然后通过建立一个协程进行go registry.checkAndPrune(),通过中间一系列的操作之后,执行pruneStaleDroplets(),遍历table对象中所有的记录,并按条件进行剪枝。
proxy模块源码分析
server部分
可以说作为一个路由节点,proxy是其最为重要的功能,registry这样的模块,其实也是为了能够服务于proxy。对于Cloud Foundry来说,所有通过uri访问Cloud Foundry内部资源的请求,都需要路由节点gorouter作代理。gorouter的proxy模块,首先监听底层的网络端口,然后再将端口发来的请求进行uri解析,最终将请求转发至指定的Cloud Foundry内部节点处。
在proxy模块,实现过程几乎可以从源码中百分百的呈现。从代理流程来讲,proxy模块可以认为是一个方向代理server端,接收所有从nginx发来的请求,并把请求转发至Cloud Foundry内的某些组件处。从实现方式来看,proxy模块建立一条nginx发来请求的连接,根据请求的内部具体信息,做相应的HTTP处理,最终构建该请求的response信息,并通过刚才的连接,将response信息返回给Nginx,当然Nginx最后也会把请求返回给发起请求的用户。其中,刚才提到的相应的HTTP处理,也就是如何将请求发给Cloud Foundry内的某些组件,并接收返回的信息。
粗略划分的话,proxy模块可以分为server端的实现与proxy代理流程的实现。首先从源码入手,第一个需要了解的自然是一些proxy模块中server的重要数据结构,位于server.go文件中。
- conn:代表一条连到proxy模块中server上的连接,或者说是从Nginx到gorouter的连接。其中,有需要访问的远程目标的地址,该连接连上的server对象等。
- type conn struct {
- remoteAddr string // network address of remote side
- server *Server // the Server on which the connection arrived
- rwc net.Conn // i/o connection
- lr *io.LimitedReader // io.LimitReader(rwc)
- buf *bufio.ReadWriter // buffered(lr,rwc), reading from bufio->limitReader->rwc
- hijacked bool // connection has been hijacked by handler
- }
type conn struct { remoteAddr string // network address of remote side server *Server // the Server on which the connection arrived rwc net.Conn // i/o connection lr *io.LimitedReader // io.LimitReader(rwc) buf *bufio.ReadWriter // buffered(lr,rwc), reading from bufio->limitReader->rwc hijacked bool // connection has been hijacked by handler }
- request:代表请求对象,其中包括http类型中的请求对象,也包含一个response返回信息的对象。
- type request struct {
- *http.Request
- w *response
- }
type request struct { *http.Request w *response }
- response:代表从server端返回去的一条response的HTTP信息,其中包括这条返回信息返回时的承载的连接,还有很多关于该HTTP响应的属性值。
- type response struct {
- conn *conn
- reqWantsHttp10KeepAlive bool
- reqMethod string
- reqProtoAtLeast10 bool
- reqProtoAtLeast11 bool
- reqExpectsContinue bool
- reqContentLength int64
- chunking bool // using chunked transfer encoding for reply body
- wroteHeader bool // reply header has been written
- wroteContinue bool // 100 Continue response was written
- header http.Header // reply header parameters
- written int64 // number of bytes written in body
- contentLength int64 // explicitly-declared Content-Length; or -1
- status int // status code passed to WriteHeader
- closeAfterReply bool
- requestBodyLimitHit bool
- }
type response struct { conn *conn reqWantsHttp10KeepAlive bool reqMethod string reqProtoAtLeast10 bool reqProtoAtLeast11 bool reqExpectsContinue bool reqContentLength int64 chunking bool // using chunked transfer encoding for reply body wroteHeader bool // reply header has been written wroteContinue bool // 100 Continue response was written header http.Header // reply header parameters written int64 // number of bytes written in body contentLength int64 // explicitly-declared Content-Length; or -1 status int // status code passed to WriteHeader closeAfterReply bool requestBodyLimitHit bool }
- server:代表接收请求,转发请求的server端,其中包含一个远程地址,另外还有一个非常重要的handler对象,用来处理HTTP请求,如果对Nginx源码熟悉的话,对Handler这个模块应该不会陌生。另外,这里的handler其实就是proxy.go文件中定义的proxy结构体。
- type Server struct {
- Addr string // TCP address to listen on, ":http" if empty
- Handler http.Handler // handler to invoke, http.DefaultServeMux if nil
- ReadTimeout time.Duration // maximum duration before timing out read of the request
- WriteTimeout time.Duration // maximum duration before timing out write of the response
- MaxHeaderBytes int // maximum size of request headers, DefaultMaxHeaderBytes if 0
- }
type Server struct { Addr string // TCP address to listen on, ":http" if empty Handler http.Handler // handler to invoke, http.DefaultServeMux if nil ReadTimeout time.Duration // maximum duration before timing out read of the request WriteTimeout time.Duration // maximum duration before timing out write of the response MaxHeaderBytes int // maximum size of request headers, DefaultMaxHeaderBytes if 0 }
源码本身是从结构体入手,并进行方法定义,为了便于理解,以下采用请求流程的方式对源码进行解读。
要想对server结构有初步的了解,那必须从server的函数Server()入手。简单代码形式如下(已省略部分异常处理等代码):
- func (srv *Server) Serve(l net.Listener) error {
- defer l.Close()
- var tempDelay time.Duration // how long to sleep on accept failure
- for {
- rw, e := l.Accept()
- ……
- c, err := srv.newConn(rw)
- ……
- go c.serve()
- }
- panic("not reached")
- }
func (srv *Server) Serve(l net.Listener) error {
defer l.Close()
var tempDelay time.Duration // how long to sleep on accept failure
for {
rw, e := l.Accept()
……
c, err := srv.newConn(rw)
……
go c.serve()
}
panic("not reached")
}
该Serve()函数的发起者为Server实例对象,传入的参数为对端口的监听对象。在执行该函数的时候,defer方法显性的定义了关于函数执行完毕后所需要处理的后续工作。关于server的具体执行操作,不难理解的服务器端需要不断轮询端口,并对端口处发来的请求进行相应的处理。在这里的代码实现即为一个for循环,在该循环中,首先server实例对象accept一个连接。这里的原理和socket的实现很类似,首先作为一个server端,先去监听listen,某一个端口,然后去accept这个端口发来的连接请求,也就是说,一旦有连接请求发来的话,server便会去accept该请求;然后作为一个client端,所需要做的操作就是去给server端的某一端口发送连接请求,如果有server监听了这个端口,那么它可以accept该连接请求;最后双方可以通信。
首先,server通过代码 rw, e := l.Accept() 实现对监听端口请求的接受;然后server再对这个net.Conn类型的rw,进行处理,最后生成一个新的连接,也就是上面涉及到的conn结构对象;接着,server创建一个协程来完成这条连接上的请求。可以发现的是,由于在gorouter中server对象只有一个,所以所有的请求都是经过这个server的,那在for循环中,server会接受很多的请求,创建很多的连接,然后对于对于一个连接上的请求,又会创建一个协程来完成,如果不借助协程的高并发处理能力,几乎不能应对大负载。
以上是对Server实例对象执行时的代码入口的解读,当真正处理请求的时候,是在go c.serve()处,其中go代表这开辟一个协程,c.serve()则是处理的具体实现。
以下是对serve()函数的分析,首先来看函数中的主要代码:
- func (c *conn) serve() {
- defer func() {
- ……
- }
- }()
- for {
- req, w, err := c.readRequest()
- ……
- // Expect 100 Continue support
- if req.expectsContinue() {
- ……
- } else if req.Header.Get("Expect") != "" {
- ……
- }
- handler := c.server.Handler
- ……
- handler.ServeHTTP(w, req.Request)
- ……
- req.finishRequest()
- if w.closeAfterReply {
- break
- }
- }
- c.close()
- }
func (c *conn) serve() {
defer func() {
……
}
}()
for {
req, w, err := c.readRequest()
……
// Expect 100 Continue support
if req.expectsContinue() {
……
} else if req.Header.Get("Expect") != "" {
……
}
handler := c.server.Handler
……
handler.ServeHTTP(w, req.Request)
……
req.finishRequest()
if w.closeAfterReply {
break
}
}
c.close()
}
defer关键字依旧是表示随后定义的函数是做来为serve()方法作善后处理。接着是一个for循环,在该for循环中,首先从连接中读取一个请求,然后对该请求的某些属性进行查阅并处理,接着创建一个handler,最后由该handler来处理HTTP请求,并结束一个请求,如果该请求是一个一次连接,那么关于该连接,如果该请求处于长连接上,则继续for循环的下一次迭代,继续从连接中读取请求并处理。
现在我们涉及函数中具体实现。 在for循环中,首先读取连接中的请求,代码形式为:req, w, err := c.readRequest(), 该实现,返回两个对象,一个为读取的请求,另一个为需要生成的response。在readRequest()函数中,代码的形式为(只显示主要部分):
- func (c *conn) readRequest() (r *request, w *response, err error) {
- ……
- var req *http.Request
- if req, err = http.ReadRequest(c.buf.Reader); err != nil {
- ……
- }
- c.lr.N = noLimit
- req.RemoteAddr = c.remoteAddr
- w = new(response)
- w.conn = c
- r = new(request)
- r.Request = req
- r.w = w
- ……
- return r, w, nil
- }
func (c *conn) readRequest() (r *request, w *response, err error) {
……
var req *http.Request
if req, err = http.ReadRequest(c.buf.Reader); err != nil {
……
}
c.lr.N = noLimit
req.RemoteAddr = c.remoteAddr
w = new(response)
w.conn = c
r = new(request)
r.Request = req
r.w = w
……
return r, w, nil
}
可见,执行该函数的时候,首先通过http的函数ReadRequest()来实现从连接c中读取请求,然后通过该请求,分别创建一个request对象和response对象。需要注意的是代码w.conn=c,也就是在说创建玩reponse对象后,对对象属性初始化时,将response的连接熟悉感conn,依旧赋值为c,那么当server将该请求转发给Cloud Foundry内部组件处理后收到回复,并对回复再进行处理,来完成这里的response重写后,依旧通过之前的连接发回去。这样的实现显得更加高效,之前我一直在考虑,想nginx之类的反向代理服务器,接收请求转发请求,接收回复转发回复的流程,如果都需要重新创建连接来完成的话,连接的开销会巨大,对于一些有长连接需求的http请求,重建连接的机制会显得非常笨重。在这里的go语言实现中,由于自定义了response的结构体,又轻松地实现了连接捆绑,所以不需要考虑连接的重新创建,但是这样的方式肯定也会付出一定的代价,比如说内存的消耗等,因为每个response实例对象中,都会存放一个连接信息。
在serve()函数可以看到,在读取连接请求readRequest()后,对请求进行一些处理之后,会创建一个handler对象来实现HTTP请求的处理,由于该部分的实现在proxy.go文件中,所以本文稍后即会涉及,简单来讲就是给后台做代理,将请求发给后台,并接收后台的回复。
当获得后台的响应请求后,server随即执行finishRequest()函数,其主要的功能就是将返回的后台回复,写入需要返回给用户的response对象中。然后判断response对象中的属性closeAfterReply,如果为真,则表示之前的请求是一个一次请求,该请求表明,自身发出之后接收到回复之后,不会再发起请求,就算有,也情愿是在创建一个连接来实现,所以程序跳出for循环,关闭连接;如果为假的话,那说明请求需要在一条长连接上进行操作,换言之,在请求的回复发给用户后,用户还会有请求通过这条连接发给server,这样的话,无需关闭连接,只需有server继续对这条连接执行readRequest()函数即可。
proxy部分
相比较而言,proxy部分做的工作要比server部分少一些,它主要的工作就是解析请求的uri和转发请求。
关于解析请求的uri的工作,在函数Lookup()中实现:
- func (proxy *Proxy) Lookup(request *http.Request) (*route.Endpoint, bool) {
- uri := route.Uri(hostWithoutPort(request))
- if _, err := request.Cookie(StickyCookieKey); err == nil {
- if sticky, err := request.Cookie(VcapCookieId); err == nil {
- routeEndpoint, ok := proxy.Registry.LookupByPrivateInstanceId(uri, sticky.Value)
- if ok {
- return routeEndpoint, ok
- }
- }
- }
- return proxy.Registry.Lookup(uri)
- }
func (proxy *Proxy) Lookup(request *http.Request) (*route.Endpoint, bool) {
uri := route.Uri(hostWithoutPort(request))
if _, err := request.Cookie(StickyCookieKey); err == nil {
if sticky, err := request.Cookie(VcapCookieId); err == nil {
routeEndpoint, ok := proxy.Registry.LookupByPrivateInstanceId(uri, sticky.Value)
if ok {
return routeEndpoint, ok
}
}
}
return proxy.Registry.Lookup(uri)
}
首先,找到请求中的host,然后对于该请求,检查是否有StickyCookieKey,如果有的话,直接从中获取sticky,再通过uri和sticky.value的组合找到相应的routeEndpoint,也就是请求的backend。这里可以稍微解释一下StickyCookieKey的作用。一旦一个请求中含有该cookie,而且能被解析到相应的uri和sticky值,也就是说这个请求,希望被处理的时候,能继续被上次处理过这个用户发出的请求的app instance上,这样的话,可以避免一些不必要的数据冲突等,或者减少DEA中 app instance的负载。如果没有找到cookie的话,那么proxy就老老实实通过host来找到相应的ip:port,如果一个host有多个instance实例的话,proxy会通过某种策略来决策由哪个Instance来服务。
在转发请求的时候,实现在函数ServeHTTP()方法中,在实现过程中,我们需要清楚其中的几个重要的方面即可:构建一个responseWriter并初始化某些属性,判断请求的类型并分别处理(TCP、websocket和HTTP),若为HTTP类型则通过transport.RoundTrip方法发送请求并接收响应,最后填写reponseWriter和设置cookie。这一部分的代码随着gorouter版本的更新会有一些形式上的不同,但是主要的功能和思想都是一致的。
以上就是对gorouter一些模块的源码分析
转自:http://blog.csdn.net/shlazww/article/details/11974411