Go语言(Golang)的web框架比较之:gin vs echo

原文发在:https://771dian.com/cb/topic/41em4_hug

Web框架类型


web框架的主流,是采用轻量级的中间件式框架,把网站变成只有api的一个个小服务,其他都扔到cdn之类的地方处理。

这种方式,开发快速、拼装能力强,要什么就加什么,不要的就不加,就像是乐高玩具,大受欢迎。

问题在于,这种框架有一堆,到底该选哪个。

Gin vs Echo


在golang中,这种杰出代表,有2个:gin 和 echo。

这两个框架,在同类中,路由性能最高,超出其他框架一大截。google了一大堆英文站,也没有找到这两个框架的比较。于是,在我们实际使用后,提供个比较。

先说结论:

  • 如果你代表企业,最好选择gin,无痛开发。
  • 如果是个人,开发个轻量服务,哪怕echo有点小问题,你也觉得没啥,那么,就用echo。

下面是比较:

框架成熟度


gin完胜。

  • gin拥有详尽的出错信息,极为方便调试。

  • 这非常关键。团队项目,这个更加重要。

  • echo在这方面,就略微逊色。使用框架的第一天,就遇到了明明路由语法写错了,却不报错、不给结果,也没有任何提示的情况。

路由性能


gin微弱小胜

  • gin的卖点,是所有web框架中,路由性能最好。

  • echo的卖点,是它的路由性能,比gin还好10%。

国外实际测试结果是:echo只在空路由时,性能比gin好10%。而常用的各种带参数路由,echo其实要输给gin约5-10%。

echo给出和其他框架的对比

最新详尽对比:https://github.com/gin-gonic/gin/issues/329

路由便利、灵活性


一回事,都有点小不便

  • 两个路由采用同一种算法,这种算法性能很高,但有个缺点: 不支持路由排序,会认为是路由冲突。

  • 比如: 路由Get("/name")Get("/:id") ,一般来说,只要把Get("/name")放在Get("/:id")前面,就是不冲突的。路由模块,会先尝试匹配前面那个,没匹配上,再去匹配后面的。

  • 而 gin和echo用的路由模块,会认为这两个路由是冲突的。gin会给出提醒,不让编译通过;echo完全不提醒,冲突就冲突了。。。

这给路由起名、设计,带来了一些麻烦。

框架的可持续发展


两个都不够好。

  • gin的主创是2个大学生。每年寒暑假就频繁更新,快到期末考试了,就完全不更新了。两人不在的时候,有网友在帮忙热情的维护,但主要是修bug、整理中间件。框架本身的发展,还是靠主创寒暑假爆发。就是这样的框架,连csico都在用。。。

  • 好在,gin的代码注释量大,易读性高,便于其他人参与。而且包装中间件,也超级容易。

  • 作者本人的态度是,对于一个在github上,start达到5000+的项目,他怎么可能会不去维护。请大家放心使用,到寒暑假了,他自然会去更新。。。

  • echo则是主创当前处于活跃状态,并且乐呵呵的想要开发2.0版。由于主创活跃,它自带了一些流行功能,比如websocket, http2, jwt授权。用gin的话,这些功能要自己包装个中间件,虽然也很容易就是了。

  • 但echo的问题在于,它的代码毫无注释。作者现在是在劲头上,等3-6个月,在路上看到个穿超短的妹子,热情转移了,很快就会忘记当时代码是怎么写的。没有注释,不但别人不方便接手,自己也懒得再去看,于是慢慢就永不再更新。

  • 缺少注释的开源包,大部分都有这个问题。echo最终会不会变成这个结局,我们无从得知。

总结


综上,

  • echo的状态是当下主创本人活跃,框架还不太成熟,适合最轻量级服务;

  • gin则是整体成熟、易于调试,但可以预期,框架本身发展不会太快,除非主创大学毕业,从事和golang相关的工作。

  • echo的使用方式、命名,都参考了gin,两者很接近,切换框架很容易,所以不用担心选错。

更新
由于echo的路由冲突频繁且没有调试信息,目前不是合理选择。等作者补上了路由冲突检测,那么就还不错。

如果想要回避这种框架的路由冲突,又想享受类似的优秀,neo框架目前最接近

共 6 个回复


TannhauserGate

我现在在试着用tango,感觉gin的话,中间件的使用还是有点不灵活,tango这种用接口和结构体组合的方式比较符合我的要求,也很好结合了Go的语言特性。不知道企业团队开发到底是怎么样的,我反正没经历过,不过就我个人来说,不追求性能,自己用tango用得还是蛮爽的。

# 0

shook

学习了,有空试试gin

# 1

butaixianran

revel是老派的三层框架风格。这种自带完整mvc的框架,适应性有限、学习成本高,在过去开源包少、开发不便的时候,是不错的选择。

如今,轻量的中间件框架才是最优选择。revel是我们的第一个golang的web框架,现在已经扔掉了

自己玩玩可以revel继续用,重新开始的,再去用传统框架,没必要了。

# 3

xiaolunwen

呵呵。推荐你们玩tango,路由性能没gin和echo高,但是灵活性高多了。而且也是中间件玩法。

# 4

dxvgef

都试过,感觉tango有echo和gin的灵活和beego那样的强大,主要是不习惯前两者不支持正则路由,beego又封装太厉害

# 5