好久不在博客上写有关足球的文章了。上一次聊足球，还是在去年世界杯决赛后，就是那个让全世界阿根廷球迷、梅西球迷伤心的日子。梅西登上领奖台瞥视大力神 金杯而不能举起的场景曾让无数梅西球迷心碎。不过梅西的足球世界大部分时间是快乐的，才用不到一年，梅西就用职业生涯的第二个“三冠王”告诉大家：王者梅西回来了 ！

今天早上8：30，用了2个多小时看完了CCTV5 尤文vs巴萨的2015年欧冠决赛的录像。没错，的确看的是录像。虽然是巴萨球迷，梅西死忠，但周日固定的家庭活动计划已经让我无法在2：45起床收看比 赛了。实际上整个这个赛季收看巴萨直播的次数也屈指可数，不过这一切都不影响我对巴萨和梅西的热爱。

经历了上个赛季的触底，实际上我对巴萨这个赛季并没有过高的期望，能收获一个冠军，止住下滑，重新企稳，我就满意了。

不过巴萨在西甲却出人意料的高开了。赛季初，巴萨连续取得胜利，并保持多场比赛不失球，这瞬间吊起了萨迷们的胃口，渐渐的大家都调高了对这 只巴萨期望。但就在这时，巴萨却连续在强强对抗中打平或失利，并在第一次国家德比输球后拱手让出榜首位置，成为追赶者。球迷对巴萨的不满气氛在巴萨冬歇期 后客场输给皇家社会后到达顶点。记得那场比赛后，我还在微博中发泄了一下，痛斥恩里克的情商不配做巴萨主帅。也正是这场比赛成为了巴萨整个赛季的拐点，值 得庆幸的是，这次是向上拐。

赛季末经媒体报道得知，这个拐点是球员与主教练的合力促成的：
1、以梅西、哈维等大佬为首的球员们内部达成了一致，要团结，不能内乱，不能再给隔壁任何机会；
2、恩里克教练团队也认识到了梅西在团队中无可替代的核心地位。

至此以后，梅西就再也没有出现在替补席，巴萨基本没有再犯低级错误，MSN三叉戟磨合期过，大放异彩，三线皆喜报频传。

于是乎就有了以下三个场景：
1、西甲第37轮，梅西一球定江山，巴萨登顶西甲冠军。
2、诺坎普国王杯决赛，梅西千里走单骑，打入史诗进球，3:1立克毕巴，摘取国王杯桂冠。
3、今天凌晨，内马尔压哨进球，巴萨3:1击溃老妇人尤文图斯，站上欧洲之巅。

巴萨触底反弹，并以绝对超出预期的表现，直接拿到俱乐部历史第二个三冠王，这是巴萨团队合力的结果。

我们来谈谈这个赛季的巴萨团队。

【管理层】

不得不说，巴萨管理团队于上个赛季中后期的内乱真是让球迷们烦透了。巴萨将士士气低落，战绩不佳，与管理层的“乱”有着直接关系。历史上，巴萨的阶段性没 落也基本上都源于管理团队的内乱。从罗塞尔辞职，到苏比萨雷塔因巴萨收到FIFA禁止转会处罚而被炒鱿鱼，巴萨内乱终于渐渐平息了一些。也就是在这段“和 平”时期，巴萨将关注放回赛场，战力逐渐恢复。巴萨管理层这个赛季的表现仅仅算得上及格罢了，这个分数还是看在表现异常优异的苏牙（苏亚雷斯）和辣鸡（拉 基蒂奇）才给出的。巴萨下个赛季还要进行主席大选，巴萨球迷心中又得忐忑一阵了。

【恩里克】

来巴萨之前，恩里克的执教“名声”似乎不那么好，在罗马以失意告终，上个赛季也仅仅实现塞尔塔保级罢了。恩里克自封“球队老大”的行事风格总是会触发更衣 室矛盾，这也是他在罗马这样的意甲豪门吃不开的原因（在罗马不尊重狼王托蒂，结果好不到哪去）。最初恩里克的行为特征充满我行我素，缺少一些妥协和平衡， 这也是其情商被球迷和媒体诟病的原因。与皇家社会一役让恩里克似乎顿悟。我们局外人很难了解到细节，恩里克是如何让球队走上正轨的。但与梅球王的关系缓和 绝对是恩里克本赛季取得成功的重要原因之一。恩里克学会了妥协，也就是说不再那么自我了。

不过恩里克也的确给巴萨带来了变化，我个人觉得其最大的贡献是在巴萨目前的阵容下找到了最适合现在巴萨的首发11人（还记得这个赛季中前期恩里克用过多少 种首发阵容吗？）以及适合的风格和踢法。恩里克很清楚不能模仿瓜帅的巴萨，现在的巴萨已经不再具备再踢那种tiki taka绝对控球风格足球的能力了。双核已老，巴萨传球的精确性下降，控制力下降，很容易丢球被打反击。

获得三冠王的恩里克，总是无法避免被和当年的瓜帅对比。所有人都看得出来，现在的巴萨风格与瓜帅鼎盛时期巴萨的风格有大不同。个人拙见：如果真正比起来， 还是瓜帅那支巴萨更强，那种强强在气势上，强在任何要与巴萨为对手的欧洲球队面对巴萨都会采集一种战术：大巴。而现在这只巴萨，任何人都想也都能和他拜拜 手腕。

关于恩里克的轮换让巴萨将士保持健康和状态的观点，我觉得见仁见智。梅西没有轮换，依旧健康，也依旧好状态。

总而言之，恩里克成功了，成功的度过了第一个赛季的信任危机。之后如何表现，如何变化（被对手研究透后）才是体现恩里克真实能力的体现，前提是下个赛季恩 里克继续执教。我还是希望他能继续执教的，毕竟能保持冠军球队的连续性和稳定性。毕竟萨米们还期待着六冠王的梅开二度呢！

【梅西】

竭尽全力，将阿根廷送入决赛，但却没能帮助阿根廷最终捧杯，要说伤心，谁也比不过梅西。多伤心只有他自己知道。不过还是那句话，梅西天生为足球而生， 天生为快乐足球而生。沉溺于快乐的足球中，梅西才能发挥出外星人般的威力。经历了两个不算太成功的赛季后，梅西也终于大爆发了。一方面这得益于梅西将重心 重新放回到俱乐部，梅西承认14年为世界杯留力了。另一方面则是对荣誉的新的渴望。这些都正面的表现在赛场上、日常训练上以及梅西减肥的态度上了。我们要 庆幸，庆幸梅西没有走肥罗的老路。严格遵守营养师的建议让梅西重归轻盈，再次获得了凌波微步的能力，也避免了再受伤病侵袭，这是本赛季梅西重回巅峰的基 础。

另外梅西有意识的自我进化，让我们再次看到梅西的足球境界是多么的高深。这个赛季，在MSN组合中梅球王更多的是扮演搭台的角色，内马尔和 苏牙唱戏。梅西长传日益精准和飘逸，45度角长传找内马尔或阿尔巴的进攻路线屡屡敲碎对方防线。直塞、任意球、撞墙配合、突破传中无所不能，勺子点球也带 给球迷一丝惊艳。词穷是梅吹们的共同心声。这里再套用一次俗语格式：梅西是“中场里进球最多的，前锋中组织、助攻、突破、传威胁球最多、后撤最深的”。

凭借本赛季的三冠王，以及下个赛季的可能的“六冠王”，梅西基本上预定了下一个“金球奖”，梅西的纪录只有梅西自己去打破了！

【布拉沃】

巴萨联赛最后一道闸门，联赛上半段连续不失球，绝对是能力的体现。布拉沃的成就让我想起了巴萨历史最佳门神：巴尔德斯。如果巴尔德斯没有走，他的荣誉簿中 就又多了一次三冠王。不过布拉沃也应该清楚，小狮王特尔施特根才是未来巴萨重点培养的对象，中流砥柱。不知道下个赛季巴萨如何在两位顶级门将中抉择。

【内马尔】

公认巴萨王储。这个赛季在进球数上是仅次于梅西的第二功臣，屡屡有关键比赛的关键进球。个人觉得内少最大的优点就是清楚的知道现在梅西是球队的核心，还没 到他立腕的时候，安心辅佐梅西才能带来个人能力和成绩上的最大收益。内马尔的能力毋庸置疑，但要学习的还有很多。年轻就是内马尔最大的优势。内马尔后续的 职业生涯如何，能否像梅西那样，连续N年持续保持最高状态，还是要看他自己的自律了。一般来说，巴西球员，尤其是巨星，到目前为止还少有能持续保持巅峰状 态的，比如大罗和小罗，希望内马尔能为巴西球员做出表率！

【小白】

欧冠决赛MVP，这个赛季低开高走，状态在最后的欧冠决赛彻底释放，让我们依稀看到带球飘逸的小白。在哈维离开巴萨后，小白义不容辞成为巴萨的绝对大佬，带领新一期巴萨梦之队走向一个有一个巅峰。

【皮克】

皮总这个赛季终于也随着“大盘”进入牛市了。在经历了两个赛季低迷后，皮总和梅西同步的回到了巅峰，再次成为后防线上那个让人放心的带刀后卫了。

【苏牙】

头顶欧洲金靴和世界杯“亮牙”的光环，苏牙从英超来到了西甲，并出人意料的与梅西、内马尔组成了史上最强三叉戟。苏牙个人能力太强，跑位、前插、卸球、射 门一气呵成，估计连皇马球迷都不得不承认：“太销魂”了！巴萨自埃托奥之后的9号魔咒似乎对苏牙也不起什么作用。下个赛季相信苏牙能表现更好，巴萨历史最 佳中锋名号在等待着苏牙。

【辣鸡】

巴萨本赛季最佳引援之一。欧冠决赛的第一个进球是大家对他最深的印象，实际上整个赛季，拉基蒂奇都有着优异的表现。在巴萨中场承前启后，与梅西不断配合、 换位、保护。前插得分能力是辣鸡一大特色，跑不死是辣鸡的招牌！相信88年出生的辣鸡必将成为巴萨新一代王朝的中流砥柱。

【哈维】

“新陈代谢”，自然规律无法抗拒。西班牙足球史上最佳中场哈维本赛季以三冠王的荣誉完美谢幕。本赛季哈维更多的是坐在替补席发挥着自己的光和热。在输球于 皇家社会后，是哈维带领大家自我反省，达成一致，从而使得巴萨走出低谷的。哈维在他在巴萨的最后一个赛季，发挥了居功至伟的作用。“三冠王”是送给哈维最 好的离别礼物。相信未来，哈维还会回到巴萨，并以主教练身份带领巴萨走向欧洲巅峰。

【布斯克茨】

兢兢业业，勤勤恳恳，作为巴萨的单后腰，布教授是巴萨中轴线上重要的一枚棋子，这个赛季也有着上佳的发挥。尤文教练甚至认为，只要封住梅西和小布，就能封住巴萨，可见小布在巴萨阵容和战术中的重要性。

【阿尔维斯】

这几个赛季阿尔维斯随着年龄的增大，状态却有下滑，梅西回归中路后，与梅西的那种配合也少见了。但这个赛季似乎是梅西回归右路后，又激发了阿尔维斯的状 态。这个赛季的阿尔维斯似乎又重新回到了巅峰时刻：助攻犀利，防守到位。无奈合同即将到底，未来还不确定。从阿尔维斯目前的身体情况和状态而言，再为巴萨 打两个赛季不成问题，真心不希望阿尔维斯出走，尤其是在巴萨特别需要他的时候。

欧冠落幕，欧洲联赛告一段落。不过阿根廷球迷、梅西粉丝却不担心，因为还有即将开打的美洲杯赛，我们仍旧会看到梅西、小马哥。阿根廷目前的实力在南美还是数一数二的。前锋线自不必提，牛B前锋太多；中场稍弱，但与其他南美球队中场比起来，巴内加、帕斯托雷等也不逞多让。后防线有当红的瓦伦中卫奥塔门迪领衔，也是让人可以相对放心的。

目前唯一担心的就是梅西赛季全勤后的体能状况。一般来说这种洲际大赛表现突出的都是那些在欧洲联赛中没有消耗多少体力的，像阿根廷对中的阿圭罗、迪玛利 亚，我觉得在本次美洲杯中会有上佳发挥。因此梅西可以选择在小组赛面对弱队时，适当做做替补席，虽然这明显不符合梅西的性格。但要走的更远，在关键比赛中 有上佳发挥，体力是基本保证啊。

期待本届美洲杯，阿根廷能载誉而归，也该轮到梅西拿拿国家队层面的冠军了！

这是一个Web Server的时代，apache2与nginx共舞，在追求极致性能的路上，没有最高，只有更高。但这又是一个追求个性化的时代，有些Web Server并没有去挤“Performance提升”这一独木桥，而是有着自己的定位，Caddy就是这样一个开源Web Server。

Caddy的作者Matt Holt在caddy官网以及FAQ中对caddy的目标阐释如下： 其他Web Server为Web而设计，Caddy为human设计。功能定位上，与经常充当最前端反向代理的nginx不同，caddy致力于成为一个易用的静态 文件Web Server。可以看出Caddy主打易用性，使用配置简单。并且得益于Go的跨平台特性，caddy很容易的支持了三大主流平台:Windows、 Linux、Mac。在Caddy开发者文档中，我们可以看到caddy还可以在Android(linux arm)上运行。caddy目前版本为0.7.1，还不稳定，且后续版本可能变化较大，甚至与前期版本不兼容，因此作者目前不推荐caddy在生产环境被 重度使用。

关注caddy，是因为caddy填补了go在通用web server这块的空白(也许有其他，但我还不知道)，同时Web server in go也“响应”了近期Golang去C化的趋势(Go 1.5中C is gone！)，即便caddy作者提到caddy的目标并非如nginx那样。但未来谁知道呢？一旦Go性能足够高时，一旦caddy足够稳定时，自然而 然的就会有人将其用在某些应用的生产环境中替代nginx或apache2了。一套全Go的系统，在部署、运维方面也是有优势的。

一、安装和运行caddy

和诸多go应用一样，我们可以直接从caddy的github.com releases页中找到最新发布版(目前是0.7.1)的二进制包。这里使用的是caddy_darwin_amd64.zip。

下载解压后，进入目录，直接执行./caddy即可将caddy运行起来。

$caddy
0.0.0.0:2015

在浏览器里访问localhost:2015，页面上没有预期显示的类似"caddy works!”之类的默认Welcome页面，而是“404 Not Found"。虽然这说明caddy已经work了，但没有一个default welcome page毕竟对于caddy beginer来说并不友好。这里已经向作者提了一个sugguestion issue。

二、caddy原理

Go的net/http标准库已经提供了http server的实现，大多数场合这个http server都能满足你的需要，无论是功能还是性能。Caddy实质上也是一个Go web app，它也import net/http，嵌入*http.Server，并通过handler的ServeHTTP方法为每个请求提供服务。caddy使用 http.FileServer作为处理 静态文件的基础。caddy的诱人之处在于其middleware，将诸多middleware串成一个middleware chain以提供了灵活的web服务。另外caddy中的middleware还可以独立于caddy之外使用。

caddy从当前目录的Caddyfile（默认）文件中读取配置，当然你也可以通过-conf指定配置文件路径。Caddyfile的配置格式 的确非常easy，这也符合caddy的目标。

Caddyfile总是以站点的Addr开始的。

单一站点的Caddyfile样例如下：

//Caddyfile
localhost:2015
gzip
log ./2015.log

Caddy也支持配置多个站点,类似virtualhost的 配置(80端口多路复用)：

//Caddyfile
foo.com:80 {
    log ./foo.log
    gzip
}

bar.com:80 {
    log ./bar.log
    gzip
}

为了实现风格上的统一，单一站点也最好配置为如下这种格式(代码内部称之为    Server Block)：

localhost:2015 {
    gzip
    log ./2015.log
}

这样Caddyfile的配置文件模板样式类似于下面这样：

host1:port {
    middleware1
    middleware2 {
        … …
    }
    … …
}

host2:port {
    middleware1
    middleware2 {
        … …
    }
    … …
}
… …

关于middleware，在caddy文档中有较为详细的说明和例子。对于caddy这样一个年轻的开源项目而言，其文档还算是相对较全的，虽 然现在还不能和nginx、 apache比。

caddy中的middleware就是一个实现了middleware.Handler接口的struct，例如gzip这个 middleware:

// middleware.go
type Middleware func(Handler) Handler
type Handler interface {
        ServeHTTP(http.ResponseWriter, *http.Request) (int, error)
}

// gzip/gzip.go
type Gzip struct {
    Next middleware.Handler
}

func (g Gzip) ServeHTTP(w http.ResponseWriter, r *http.Request) (int, error) {
    if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {
        return g.Next.ServeHTTP(w, r)
    }
    …. …
    gz := gzipResponseWriter{Writer: gzipWriter, ResponseWriter: w}

    // Any response in forward middleware will now be compressed
    status, err := g.Next.ServeHTTP(gz, r)
    … …
}

middleware.Handler的函数原型与http.Handler的不同，不能直接作为http.Server的Handler使用。caddy使用了下面这个idiomatic go pattern:

type appHandler func(http.ResponseWriter, *http.Request) (int, error)

func (fn appHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if status, err := fn(w, r); err != nil {
        http.Error(w, err.Error(), status)
    }
}
当然这个pattern有很多变种，但思路大致类似。一个middleware chain大致就是handler1(handler2(handler3))的调用传递。

前面说过caddy是基于http.FileServer的静态文件Web Server，FileServer总会作为middleware chain的最后一环，如果没有配置任何middleware，那你的server就是一个静态文件server。

三、caddy典型应用

【静态文件Server】

caddy的最基础应用实际就是一个静态文件Server，底层由http.FileServer承载，当然caddy封装了http.FileServer，做了一些拦截处理，最后将w, r传递给http.ServeContent去处理文件数据。

第一次执行./caddy，实际上就启动了一个静态文件Server。但这个server不默认支持你navigate directory。如果你知道website root目录(如果没有指定root，则caddy执行的当前路径会作为website的root路径)下的文件名，比如foo.txt，你可以在浏览器 中输入：localhost:2015/foo.txt，caddy会执行正确的服务，浏览器也会显示foo.txt的全文。

对于静态文件Server，caddy支持在website的root路径下首先查找是否有如下四个文件：

//caddy/middleware/browse/browse.go
var IndexPages = []string{
    "index.html",
    "index.htm",
    "default.html",
    "default.htm",
}

如果查到有其中一个，则优先返回这个文件内容，这就是静态站点的首页。

如果要支持目录文件列表浏览，则需要为website配置browse middleware，这样对于无index file的目录，我们可以看到目录文件列表。

localhost:2015 {
    browse
}   

【反向代理】

caddy支持基本的反向代理功能。反向代理配置通过proxy middleware实现。

localhost:2015 {
    log ./2015.log

    proxy /foo localhost:9001
    proxy /bar localhost:9002
}

当你访问localhost:2015/foo时，实际上访问的是9001端口的服务程序；
当你访问localhost:2015/bar时，实际上访问的是9002端口的服务程序。

【负载均衡】

Caddy支持负载均衡配置，并支持三种负载均衡算法：random（随机）、least_conn（最少连接）以及round_robin(轮询调度)。

负载均衡同样是通过proxy middleware实现的。

localhost:2015 {
    log ./2015.log

    proxy / localhost:9001 localhost:9003 {
        policy round_robin
    }
    proxy /bar localhost:9002 localhost:9004 {
        policy least_conn
    }
}

【支持fastcgi代理】

caddy同样支持fastcgi代理，可以将请求通过fastcgi接口发送给后端的实现fastcgi的server。我们以一个"hello world"的php server为例。

mac os上自带了php-fpm，一个实现了fastcgi的php cgi进程管理器。caddy将请求转发给php-fpm监听的端口，后者会启动php-cgi解释器，解释index.php，并将结果返回给caddy。

mac os上的php-fpm默认没有随机启动。我们需要简单配置一下：

$mkdir phptest
$mkdir -p phptest/etc
$mkdir -p phptest/log
$cd phptest
$sudo cp /private/etc/php-fpm.conf.default ./etc
$cd ./etc
$sudo chown tony php-fpm.conf.default
$mv php-fpm.conf.default php-fpm.conf

编辑php-fpm.conf，保证下面两项是非注释状态的：

error_log = log/php-fpm.log
listen = 127.0.0.1:9000 

我们通过network socket进行fastcgi通信。

回到phptest目录下，执行:

php-fpm -p ~/test/go/caddy/phptest

执行后，php-fpm就会转入后台执行了。

接下来我们来配置Caddyfile：

localhost:2015 {
    fastcgi / 127.0.0.1:9000 php
    log ./2015.log
}

这里配置的含义是：将全部请求转发到9000端口，这里的php是一个preset（预配置集合），相当于：

ext   .php
split .php
index index.php

我们在phptest目录下创建一个index.php文件，内容如下：

<?php echo "Hello World\n"; ?>

好了，现在启动caddy，并使用浏览器访问localhost:2015试试。你会看到"Hello World"呈现在浏览器中。

【git push发布】

对于一些静态站点，caddy支持git directive，实现在server启动以及运行时定期git pull你的项目库，将最新更新pull到server上。

caddy文档中给出两个例子：

第一个是一个php站点，定期pull项目库，实现server更新：

git git@github.com:user/myphpsite {
    key /home/user/.ssh/id_rsa
}
fastcgi / 127.0.0.1:9000 php

第二个是一个hugo支撑的静态站点，每次pull后，执行hugo命令生成新的静态页面：

git github.com/user/site {
    path  ../
    then  hugo –destination=/home/user/hugosite/public
}

注意：git directive并非middleware，而是一个单独的goroutine实现的。

四、小结

caddy的功能不局限于上面的几个例子，上面只是几个最为常见的场景而已。caddy目前还很年轻，应用不多，但知名golang网站 gopheracademy.com（GopherCon组织方）是由Caddy support的。caddy还在积极进化，有兴趣的Gopher可持续关注。