2015年六月月 发布的文章

也谈并发与并行

在一般人的眼中,“并行”就是并行,即你干你的,我干我的,两个“并行”的执行过程可能是两条毫无瓜葛的平行线,也可能是有交叉,但瞬即分开的两条线。不 过在程序员的世界里,有关“并行”的概念却有两个单词:Concurrency和Parallelism,对应的比较主流的中文翻译为并发 (Concurrency)和并行(Parallelism)。

之前一直使用C、Python进行Coding,对Concrrency和Parallelism的异同并不十分关心,也未求甚解。但switch to golang后,尤其是学习2012年Rob Pike的一个talk slide:“Concurrency is not Parallelism(译作:并发不是并行)"后,感觉之前对于“并行”的理解还未到火候。

golang的Author们对文档还是非常看重的。按照目前golang的age来说,其文档的充分性相对于其他语言已经是相对较好的了。golang 的 author们还时不时放出一些blog、talk和slide,以帮助大家编写出more idiomatic的golang程序。Rob Pike的“并发不是并行”就是golang官方站点上的一个talk slide(中文版在这里 )。

Rob Pike是Golang大神,这里先列出他在talk中对于并发与并行的学术阐释和理解:

【Concurrency并发】
Programming as the composition of independently executing processes. (Processes in the general sense, not Linux processes. Famously hard to define.)
将相互独立的执行过程综合到一起的编程技术。(这里是指通常意义上的执行过程,而不是Linux进程。很难定义。)

Concurrency is about dealing with lots of things at once.
并发是指同时处理很多事情。

Concurrency is about structure.
并发关乎结构。

Concurrency provides a way to structure a solution to solve a problem that may (but not necessarily) be parallelizable.
并发提供了一种方式让我们能够设计一种方案将问题(非必须的)并行的解决。

Concurrency is a way to structure a program by breaking it into pieces that can be executed independently.
并发是一种将一个程序分解成小片段独立执行的程序设计方法。

【Parallelism并行】
Programming as the simultaneous execution of (possibly related) computations.
同时执行(通常是相关的)计算任务的编程技术。

Parallelism is about doing lots of things at once.
并行是指同时能完成很多事情。

Parallelism is about execution.
并行关乎执行。

【小结】
They are Not the same, but related.
它们不相同,但相关。

怎么样?看上上面的论述是不是一头雾水啊。Rob Pike也觉得这些概念以及描述过于抽象,于是给了一个具体的“地鼠推车运书”的例子,不过当你看完这个例子后,可能会变得更加糊涂,至少我有这种感觉-地鼠凌乱综合症^_^。这是因为这个例子隐含的结合了Go语言goroutine调度的三个概念:P(虚拟processor上下文)、M(内核线程)和G(Goroutine对象)。如果仅仅从理解并行和并发的差异来说,我们可以抛开go语言,用生活中的例子感觉更适合些。

下面我们就来一个例子来说说明一下并发与并行,从一个程序的设计演进角度来阐述。

问题:说的是一个Gopher早起后的生活,Gopher早起后,有三个任务(或者称为三件事情)要完成:洗漱、早餐、着装。我们来设计一个程序,帮助Gopher高效正确的完成这三件事。

如果你是程序员,要完成这个场景,你可能会这么设计你的程序:

program1:

最简单的思路:这个gopher一件一件事情去完成:

main:
    call 洗漱
    call 早餐
    call 着装

这里我们把Gopher看做是一颗cpu,它按程序逻辑,顺序执行洗漱、早餐和着装三件事。即如下图那样:

现在我们玩个克隆游戏,我们clone出一个与这个Gopher一模一样的Gopher,且两个gopher之间存在着某种超宇宙联系,一个Gopher行为的结果都能反应到另外一个gopher上。我们让这两个Gopher一起来做这三件事情,看看是否能够提速。

遗憾的是,两个Gopher都要从洗漱做起。一个Gopher占用了卫生间开始洗漱,另外一个Gopher只能等着,而没法去做早餐或是着装。当那个 Gopher完成洗漱,后面的这个Gopher由于超联系也同步完成了洗漱,进入下一个环节:早餐。过程还是一样的,只能一个Gopher在餐厅准备早 餐。也就是说这两个Gopher没有一起做事,而是一个做,一个赋闲。因此我们看到两个Gopher并没有加快事情完成的步伐,从过程上来看,即便有更多 的Gopher,也依旧无法提速。我们需要对程序做些改造。

注:首尾相连的红线的总长度 = 完成时间。

program2:

main:
    pthread_create(洗漱)
    pthread_create(早餐)
    pthread_create(着装)

    waitAll

Gopher来执行一遍新程序。由于建立了三个逻辑执行体,因此Gopher在三个执行体间切换,从Gopher的角度去看,Gopher的执行路径如下图:


Program2-1

Gopher不再像上面Program1那样顺序执行了,而是在三个活动间切换,但总时长依旧没有下降。

为了验证该程序在多Gopher下是否有效率提升,我们再玩一次克隆游戏,这次clone出另外两个Gopher,三个Gopher一起来执行该程序,一个可能的执行路径见下图:


Program2-2

每个Gopher绑定一个逻辑执行体,整体完成的总时长下降为原来的三分之一。这次三个Gopher都没有赋闲,真正做到你干你的,我干我的,一起做。

program3:

虽然在program2中,多个Gopher一起工作提升了效率,但那是极限么,还能提高么?我们试想一下三个活动:洗漱、早餐和着装的难易不同,耗时不 同。一个可能的结果是Gopher1完成了洗漱,但Gopher2才准备了一半早餐,Gopher3刚选完上衣。这时Gopher1便开始空闲,无法帮助 Gopher2和Gopher3继续提高效率。我们再试试重新组合一下要完成的任务,让每个Gopher都能执行不同的活动环节。

main:
        c chan job
        for i = 0; i < 3; i++  {
            go gopherworker(c)
        }

        for j := range jobs {
            c <- j
        }
        … …

gopherworker(c chan job):
      for {
         select {
         case <-c:
         … …
      }

以下是一个可能的执行路径图:

到了这里,不知道你是否通过上面程序演进的过程悟道些什么,例子里我通篇没有提到并发或并行。

但从例子可以看出,并发和并行是两个阶段的事情。并发在程序的设计和实现阶段,并行在程序的执行阶段。

在Program1之前,我们只有问题,并无方案。

Program1方案让我们可以解决问题,但从Program1的执行结果来看,Program1并不能并行执行。原因是在设计和实现阶段程序就是按照顺序思路进行的,这就好比底子没打好,在平房的地基上永远不能盖50层的大楼。

Program2-1方案的执行结果与Program1相同,但Program2在设计和实现阶段采用的理念却与Program1完全不同,如果说 Program1打的是平房的地基,那么Program2打的就是大厦的地基,虽然Program2-1上依旧盖的是平房(单Gopher执行)。但 Program2-2显然就是在这样的地基上盖的摩天大楼了(多Gopher执行)。Program2的结构使得Program2在多Gopher下提升 了效率,实现了运行时并行。

Program3更进一步,在设计和实现阶段就本着充分高效的利用多个Gopher的理念,并最终实现了执行阶段的并行。

因此我们在编程语言层面更多谈并发,Golang对外宣传时永远用的是支持并发,而不是支持并行。设计实现阶段好比打地基,不同水准的地基决定了你在这个地基上面是只能盖平房,还是盖高层,还是能盖摩天大楼。

我们再回过头来重温Rob Pike大神关于两者的阐述:“并发关乎结构,并行关乎执行”,是不是感觉意味深长啊,大神就是大神,一句话就能抓住本质。

go 1.5之前默认情况下,Go程序都是不能并行的,因为Go将GOMAXPROCS默认设置为1,这样你仅仅能利用一个内核线程。Go 1.5及以后GOMAXPROCS被默认设置为所运行机器的CPU核数,如果你的机器是多核的,你的Go程序就有可能在运行期是并行的,前提是你在设计程 序时就充分运用了并发的设计理念,否则就会像Program1那样,即便有1w颗CPU,你也只能利用上一颗。

Appdash,用Go实现的分布式系统跟踪神器

在“云”盛行的今天,分布式系统已不是什么新鲜的玩意儿。用脚也能想得出来:Google、baidu、淘宝、亚马逊、twitter等IT巨头 背后的巨型计算平台都是分布式系统了,甚至就连一个简单的微信公众号应用的后端也都分布式了,即便仅有几台机器而已。分布式让系统富有弹性,面 对纷繁变化的需求,可以伸缩自如。但分布式系统也给开发以及运维人员带来了难题:如何监控和优化分布式系统的行为。

以google为例,想象一下,用户通过浏览器发起一个搜索请求,Google后端可能会有成百上千台机器、多种编程语言实现的几十个、上百个应 用服务开始忙碌起来,一起计算请求的返回结果。一旦这个过程中某一个环节出现问题/bug,那么查找和定位起来是相当困难的,于是乎分布式系统跟 踪系统出炉了。Google在2010年发表了著名论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》(中文版在这里)。Dapper是google内部使用的一个分布式系统跟踪基础设施,与之前的一些跟踪系统相比,Dapper以低消耗、对应用透明以及良好的扩展性著称。并且 Google Dapper更倾向于性能数据方面的收集和调查,可以辅助开发人员和运维人员发现分布式系统的性能瓶颈并着手优化。Dapper出现后,各大巨头开始跟 风,比如twitter的Zipkin(开源)、淘宝的“鹰眼”、eBay的Centralized Activity Logging (CAL)等,它们基本上都是参考google的dapper论文设计和实现的。

而本文将要介绍的Appdash则是sourcegraph开源的一款用Go实现的分布式系统跟踪工具套件,它同样是以google的 dapper为原型设计和实现的,目前用于sourcegraph平台的性能跟踪和监控。

一、原理

Appdash实现了Google dapper中的四个主要概念:

【Span】

Span指的是一个服务调用的跨度,在实现中用SpanId标识。根服务调用者的Span为根span(root span),在根级别进行的下一级服务调用Span的Parent Span为root span。以此类推,服务调用链构成了一棵tree,整个tree构成了一个Trace。

Appdash中SpanId由三部分组成:TraceID/SpanID/parentSpanID,例如: 34c31a18026f61df/aab2a63e86ac0166/592043d0a5871aaf。TraceID用于唯一标识一次Trace。traceid在申请RootSpanID时自动分配。

在上面原理图中,我们也可以看到一次Trace过程中SpanID的情况。图中调用链大致是:

frontservice:
        call  serviceA
        call  serviceB
                  call serviceB1
        … …
        call  serviceN

对应服务调用的Span的树形结构如下:

frontservice: SpanId = xxxxx/nnnn1,该span为root span:traceid=xxxxx, spanid=nnnn1,parent span id为空。
serviceA: SpanId = xxxxx/nnnn2/nnnn1,该span为child span:traceid=xxxxx, spanid=nnnn2,parent span id为root span id:nnnn1。
serviceB: SpanId = xxxxx/nnnn3/nnnn1,该span为child span:traceid=xxxxx, spanid=nnnn3,parent span id为root span id:nnnn1。
… …
serviceN: SpanId = xxxxx/nnnnm/nnnn1,该span为child span:traceid=xxxxx, spanid=nnnnm,parent span id为root span id:nnnn1。
serviceB1: SpanId = xxxxx/nnnn3-1/nnnn3,该span为serviceB的child span,traceid=xxxxx, spanid=nnnn3-1,parent span id为serviceB的spanid:nnnn3

【Event】

个人理解在Appdash中Event是服务调用跟踪信息的wrapper。最终我们在Appdash UI上看到的信息,都是由event承载的并且发给Appdash Server的信息。在Appdash中,你可以显式使用event埋点,吐出跟踪信息,也可以使用Appdash封装好的包接口,比如 httptrace.Transport等发送调用跟踪信息,这些包的底层实现也是基于event的。event在传输前会被encoding为 Annotation的形式。

【Recorder】

在Appdash中,Recorder是用来发送event给Appdash的Collector的,每个Recorder会与一个特定的span相关联。

【Collector】

从Recorder那接收Annotation(即encoded event)。通常一个appdash server会运行一个Collector,监听某个跟踪信息收集端口,将收到的信息存储在Store中。

二、安装

appdash是开源的,通过go get即可得到源码并安装example:

go get -u sourcegraph.com/sourcegraph/appdash/cmd/…

appdash自带一个example,在examples/cmd/webapp下面。执行webapp,你会看到如下结果:

$webapp
2015/06/17 13:14:55 Appdash web UI running on HTTP :8700
[negroni] listening on :8699

这是一个集appdash server, frontservice, fakebackendservice于一身的example,其大致结构如下图:

通过浏览器打开:localhost:8700页面,你会看到appdash server的UI,通过该UI你可以看到所有Trace的全貌。

访问http://localhost:8699/,你就触发了一次Trace。在appdash server ui下可以看到如下画面:

从页面上展示的信息可以看出,该webapp在处理用户request时共进行了三次服务调用,三次调用的耗时分别为:201ms,202ms, 218ms,共耗时632ms。

一个更复杂的例子在cmd/appdash下面,后面的应用实例也是根据这个改造出来的,这里就不细说了。

三、应用实例

这里根据cmd/appdash改造出一个应用appdash的例子,例子的结构如下图:

例子大致分为三部分:
appdash — 实现了一个appdash server, 该server带有一个collector,用于收集跟踪信息,收集后的信息存储在一个memstore中;appdash server提供ui,ui从memstore提取信息并展示在ui上供operator查看。
backendservices — 实现两个模拟的后端服务,供frontservice调用。
frontservice — 服务调用的起始端,当用户访问系统时触发一次跟踪。

先从backendservice这个简单的demo service说起,backendservice下有两个service: ServiceA和ServiceB,两个service几乎一模一样,我们看一个就ok了:

//appdash_examples/backendservices/serviceA.go
package main

import (
    "fmt"
    "net/http"
    "time"
)

func handleRequest(w http.ResponseWriter, r *http.Request) {
    var err error
    if err = r.ParseForm(); err != nil {
        fmt.Println("Http parse form err:", err)
        return
    }
    fmt.Println("SpanId =", r.Header.Get("Span-Id"))

    time.Sleep(time.Millisecond * 101)
    w.Write([]byte("service1 ok"))
}

func main() {
    http.HandleFunc("/", handleRequest)
    http.ListenAndServe(":6601", nil)
}

这是一个"hello world"级别的web server。值得注意的只有两点:
1、在handleRequest中我们故意Sleep 101ms,用来模拟服务的耗时。
2、打印出request头中的"Span-Id"选项值,用于跟踪Span-Id的分配情况。

接下来我们来看appdash server。appdash server = collector +store +ui。

//appdash.go
var c Server

func init() {
    c = Server{
        CollectorAddr: ":3001",
        HTTPAddr:      ":3000",
    }
}

type Server struct {
    CollectorAddr string
    HTTPAddr      string
}

func main() {
    var (
        memStore = appdash.NewMemoryStore()
        Store    = appdash.Store(memStore)
        Queryer  = memStore
    )

    app := traceapp.New(nil)
    app.Store = Store
    app.Queryer = Queryer

    var h http.Handler = app
    var l net.Listener
    var proto string
    var err error
    l, err = net.Listen("tcp", c.CollectorAddr)
    if err != nil {
        log.Fatal(err)
    }
    proto = "plaintext TCP (no security)"
    log.Printf("appdash collector listening on %s (%s)",
                c.CollectorAddr, proto)
    cs := appdash.NewServer(l, appdash.NewLocalCollector(Store))
    go cs.Start()

    log.Printf("appdash HTTP server listening on %s", c.HTTPAddr)
    err = http.ListenAndServe(c.HTTPAddr, h)
    if err != nil {
        fmt.Println("listenandserver listen err:", err)
    }
}

appdash中的Store是用来存储收集到的跟踪结果的,Store是Collector接口的超集,这个例子中,直接利用memstore(实现了 Collector接口)作为local collector,利用store的Collect方法收集trace数据。UI侧则从store中读取结果展示给用户。

最后我们说说:frontservice。frontservice是Trace的触发起点。当用户访问8080端口时,frontservice调用两个backend service:

//frontservice.go
func handleRequest(w http.ResponseWriter, r *http.Request) {
    var result string
    span := appdash.NewRootSpanID()
    fmt.Println("span is ", span)
    collector := appdash.NewRemoteCollector(":3001")

    httpClient := &http.Client{
        Transport: &httptrace.Transport{
            Recorder: appdash.NewRecorder(span, collector),
            SetName:  true,
        },
    }

    //Service A
    resp, err := httpClient.Get("http://localhost:6601")
    if err != nil {
        log.Println("access serviceA err:", err)
    } else {
        log.Println("access serviceA ok")
        resp.Body.Close()
        result += "access serviceA ok\n"
    }

    //Service B
    resp, err = httpClient.Get("http://localhost:6602")
    if err != nil {
        log.Println("access serviceB err:", err)
        return
    } else {
        log.Println("access serviceB ok")
        resp.Body.Close()
        result += "access serviceB ok\n"
    }
    w.Write([]byte(result))
}

func main() {
    http.HandleFunc("/", handleRequest)
    http.ListenAndServe(":8080", nil)
}

从代码看,处理每个请求时都会分配一个root span,同时traceid也随之分配出来。例子中没有直接使用Recorder埋点发送event,而是利用了appdash封装好的 httptrace.Transport,在初始化httpClient时,将transport实例与span和一个remoteCollector想 关联。后续每次调用httpClient进行Get/Post操作时,底层代码会自动调用httptrace.Transport的RoundTrip方 法,后者在Request header上添加"Span-Id"参数,并调用Recorder的Event方法将跟踪信息发给RemoteCollector:

//appdash/httptrace/client.go
func (t *Transport) RoundTrip(req *http.Request) (*http.Response, error) {
    var transport http.RoundTripper
    if t.Transport != nil {
        transport = t.Transport
    } else {
        transport = http.DefaultTransport
    }

    … …
    req = cloneRequest(req)

    child := t.Recorder.Child()
    if t.SetName {
        child.Name(req.URL.Host)
    }
    SetSpanIDHeader(req.Header, child.SpanID)

    e := NewClientEvent(req)
    e.ClientSend = time.Now()

    // Make the HTTP request.
    resp, err := transport.RoundTrip(req)

    e.ClientRecv = time.Now()
    if err == nil {
        e.Response = responseInfo(resp)
    } else {
        e.Response.StatusCode = -1
    }
    child.Event(e)

    return resp, err
}

这种方法在一定程度上实现了trace对应用的透明性。

你也可以显式的在代码中调用Recorder的Event的方法将trace信息发送给Collector,下面是一个fake SQLEvent的跟踪发送:

 // SQL event
    traceRec := appdash.NewRecorder(span, collector)
    traceRec.Name("sqlevent example")

    // A random length for the trace.
    length := time.Duration(rand.Intn(1000)) * time.Millisecond
    startTime := time.Now().Add(-time.Duration(rand.Intn(100)) * time.Minute)
    traceRec.Event(&sqltrace.SQLEvent{
        ClientSend: startTime,
        ClientRecv: startTime.Add(length),
        SQL:        "SELECT * FROM table_name;",
        Tag:        fmt.Sprintf("fakeTag%d", rand.Intn(10)),
    })

不过这种显式埋点需要程序配合做一些改造。

四、小结

目前Appdash的资料甚少,似乎只是其东家sourcegraph在production环境有应用。在github.com上受到的关注度也不算高。

appdash是参考google dapper实现的,但目前来看appdash只是实现了“形”,也许称为神器有些言过其实^_^。

首先,dapper强调对应用透明,并使用了Thread LocalStorage。appdash实现了底层的recorder+event机制,上层通过httptrace、sqltrace做了封装,以降 低对应用代码的侵入性。但从上面的应用来看,透明性还有很大提高空间。

其次,appdash的性能数据、扩展方案sourcegraph并没有给出明确说明。

不过作为用go实现的第一个分布式系统跟踪工具,appdash还是值得肯定的。在小规模分布式系统中应用对于系统行为的优化还是会有很大帮助的。   

BTW,上述例子的完整源码在这里可以下载到。

巴萨“三冠王”梅开二度,梅球王预定第五座金球奖杯

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

今天早上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前锋太多;中场稍弱,但与其他南美球队中场比起来,巴内加、帕斯托雷等也不逞多让。后防线有当红的瓦伦中卫奥塔门迪领衔,也是让人可以相对放心的。

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

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




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多