Cloud Foundry中gorouter对StickySession的支持

        Cloud Foundry作为业界出众的PaaS平台，在应用的可扩展性方面做得很优秀。

        详细来讲，在一个应用须要横向伸展的时候，Cloud Foundry能够轻松地帮助用户做好伸展工作，也就是创建出一个应用的多个实例，多个实例地位相等，多个实例共同为用户服务，多个实例共同分担訪问压力。

        大致来说，能够觉得是共同分担訪问压力，可是也不是针对全部该应用的訪问，都进行均衡，分发到不同的应用实例处。譬如：当Cloud Foundry的訪问用户訪问应用时，第一次的訪问，gorouter会将请求分发到应用的某个实例处，可是假设该用户之后的訪问都是有状态的，不希望之后的訪问会被分发到该应用的其它实例处。针对以上这样的情况，Cloud Foundry提供了自己的解决方式，使用StickySession的方式，保证请求依然分发给指定的应用实例。

        本文即分析Cloud Foundry中gorouter关于StickySession的实现方式。

        该部分内容须要对gorouter有一定的了解，能够參见笔者之前的博文：Cloud Foundry中gorouter源代码分析

        关于StickySession的信息，gorouter所做的工作，主要分为两个部分：怎样给HTTP请求加入�StickySession、怎样通过StickySession辨别应用的详细实例。

怎样给HTTP请求加入�StickySession

        在分析这个问题的时候，首先我们须要提出还有一个问题：什么情况下须要给HTTP请求加入�StickySession？

        首先，来看这种一个方法setupStickySession的go语言实现：

func (h *RequestHandler) setupStickySession(endpointResponse *http.Response, endpoint *route.Endpoint) {
        needSticky := false
        for _, v := range endpointResponse.Cookies() {
                if v.Name == StickyCookieKey {
                        needSticky = true
                        break
                }
        }

        if needSticky && endpoint.PrivateInstanceId != "" {
                cookie := &http.Cookie{
                        Name:  VcapCookieId,
                        Value: endpoint.PrivateInstanceId,
                        Path:  "/",
                }

                http.SetCookie(h.response, cookie)
        }
}
      

       紧接着，查看setupStickySession方法何时被调用的代码：

func (h *RequestHandler) HandleHttpRequest(transport *http.Transport, endpoint *route.Endpoint) (*http.Response, error) {
        h.transport = transport

        h.setupRequest(endpoint)
        h.setupConnection()

        endpointResponse, err := transport.RoundTrip(h.request)
        if err != nil {
                return endpointResponse, err
        }

        h.forwardResponseHeaders(endpointResponse)

        h.setupStickySession(endpointResponse, endpoint)

        return endpointResponse, err
}

        在setupStickySession方法中，能够看到：首先进入一个循环语句块中，当endpointResponse中的cookies中有名为StickyCookieKey的话，将needSticky字段置为true，跳出循环。这里也就回答了什么时候须要给HTTP请求加入�StickySession的问题。关于StickyCookieKey的值，能够先看一下gorouter的设置：

const (
        VcapCookieId    = "__VCAP_ID__"
        StickyCookieKey = "JSESSIONID"
)

        能够看到StickyCookieKey的值为JSESSIONID，而JSESSIONID是Tomcat对session id的称呼，在其它容器中就不一定叫JSESSIONID了。因此，假设平台运维者自己定义了一种容器的buildpack，而这个容器中对于session id的称呼不为JSESSIONID的话，那么Sticky Session在gorouter中将不能被实现，除非将这部分内容自行进行改写，或者改动该容器对session id的称呼。

       紧接着在setupStickySession中，通过一个推断，来给response创建一个cookie，创建的cookie有Name字段，Value字段以及Path字段。最后通过http.SetCookie(h.response, cookie)来实现对response的设置加入�cookie。

       读完setupStickySession方法的实现，如今进入调用该方法的HandleHttpRequest方法，该方法的主要工作是：将haproxy代理来的请求，转发给详细对应的DEA上的应用实例，最后构建该请求的response信息，并返回该响应信息。在返回response响应信息的之前，gorouter为该response信息设置了StickySession。

        以上便是怎样给HTTP请求加入�StickySession，下面分析怎样通过StickySession辨别应用的详细实例。

怎样通过StickySession辨别应用的详细实例

func (p *proxy) lookup(request *http.Request) (*route.Endpoint, bool) {
        uri := route.Uri(hostWithoutPort(request))

        // Try choosing a backend using sticky session
        if _, err := request.Cookie(StickyCookieKey); err == nil {
                if sticky, err := request.Cookie(VcapCookieId); err == nil {
                        routeEndpoint, ok := p.registry.LookupByPrivateInstanceId(uri, sticky.Value)
                        if ok {
                                return routeEndpoint, ok
                        }
                }
        }

        // Choose backend using host alone
        return p.registry.Lookup(uri)
}