beego和php技巧_golang框架选型比较goframe beego iris和gin

文章目录 [+]

由于事情须要，这些年来也打仗了不少的开拓框架，Golang的开拓框架比较多，不过基本都是Web"框架"为主。
这里轻微打了个引号，由于大部分"框架"从设计和功能定位上来讲，充其量都只能算是一个组件，须要项目利用的话得自己四处再去找找其他的组件，或者自己造轮子。
如果用于Web开拓，这些"框架"的Web开拓能力均已完备，无太大差别，且均是自标准库net/http.Server的二次封装。
由于框架浩瀚，这里笔者只选择了几个曾做过技能选型评估、较为熟习，且目前比较盛行和范例的Golang"框架"，从适用于业务项目开拓框架的角度，做一个大略的横向比较，以便大家在项目框架选型时做个参考。

评估指标

指标

beego和php技巧_golang框架选型比较goframe beego iris和gin

解释

（图片来自网络侵删）

指标

解释

基本先容

来源各自官网。

模块化设计

是否支持模块化插拔设计、模块之间低耦合设计，是否可以独立利用个中某部分组件。

模块完善度

框架供应的功能模块是否丰富。
模块能否能覆盖日常普遍的开拓需求。

利用易用性

易用性不仅仅是值框架好不好用，更多是团队能否在低本钱下快速接入，长期来看能否低本钱掩护。

文档完善性

参考官网供应的先容资料，包括但不限于：文档、视频、示例、案例资料。
同时，本地中文文档支持也是参考项。

工程化完备

是否能够快速接入项目开拓，是否供应项目接入规范、设计模式、开拓工具链，文档是否完善、源码是否易读、是否便于长期掩护。

开拓模式

框架适用的开拓模式，或者官方推举的开拓模式。

工程规范

项目接入时的开拓规范，如目录规范、设计规范、编码规范、命名规范等。

社区生动

官方与社区沟通是否便捷，问题是否能够快速解答，BUG是否能够快速相应处理。

开拓工具链

项目开拓时利用到的CLI开拓工具，如初始化项目、交叉编译、代码天生、swagger、热编译能力等等。

Web: 性能测试

来源第三方评测 https://github.com/the-benchmarker/web-frameworks 。

Web: 路由冲突处理

存在路由注册冲突时有无良好的办理方案，在业务项目开拓中比较常见。

Web: 域名支持

Web路由是否支持域名绑定，乃至多域名的绑定。

Web: 文件做事

Web做事是否供应静态资源的访问能力。

Web: 优雅重启/关闭

Web做事在重启时不会影响要求实行，关闭时会等待正在实行的要求处理完，新要求不再接入。

ORM

框架是否自带ORM组件，ORM组件是业务项目的核心组件。
无论是自研还是通过第三方组件引入。

Session

框架是否供应会话管理组件，无论是通用型Session组件，还是仅针对付Web做事的Session组件。

I18N支持

国际化组件支持（常用但非核心组件）。

配置管理

配置管理也是框架须要完备的核心组件能力。

日志组件

日志组件也是框架须要完备的核心组件能力。

数据校验

数据校验也是框架须要完备的核心组件能力。

缓存管理

缓存管理也是框架须要完备的核心组件能力。
无论是内存还是Redis，无论是自研还是通过第三方组件引入。

资源打包

支持将依赖的文件资源例如静态资源、配置文件等固定文件编译到可实行文件中。
框架组件自动支持资源检索。

链路跟踪

框架是否具备分布式链路跟踪能力，分布式跟踪在微做事架构中是必不可少的能力。

测试框架

框架是否支持单元测试接入，供应单元测试接入规范。
无论是利用标准库还是第三方测试框架。

突出优点

比较明显的几点优点。

突出缺陷

比较明显的几点缺陷。

横向比较以下部分比拟参数涉及评分的部分，满分统共按照10分为标准。
如果标记为"-"的部分，表示不支持或者须要引入第三方插件支持。
以下特性如果官网供应文档则直接供应文档地址，找不到文档但是笔者知道有就会大略标注。
各个"框架"功能特性实现不同，在文档、功能、易用性上存在较大差异，各位朋友可自行查阅链接。

GoFrame

Beego

Iris

Gin

比较版本

v1.15.2

v1.12.3

v12.0.2

v1.6.3

项目类型

开源（海内）

开源（外洋）

开源协议

MIT

Apache-2

BSD-3-Clause

MIT

框架类型

模块化框架

Web框架

Web"框架"

基本先容

工程完备、大略易用，模块化、高质量、高性能、企业级开拓框架。

最大略易用的企业级Go运用开拓框架。

目前发展最快的Go Web框架。
供应完全的MVC功能并且面向未来。

一个Go措辞写的HTTP Web框架。
它供应了Martini风格的API并有更好的性能。

项目地址

github.com/gogf/gf

github.com/beego/beego

github.com/kataras/iris

github.com/gin-gonic/gin

官网地址

goframe.org

beego.me

iris-go.com

gin-gonic.com

模块化设计

是

模块完善度

利用易用性

文档完善度

工程化完备

社区生动

开拓模式

模块引入、三层架构、MVC

MVC

工程规范

分层设计、工具设计

项目构造

开拓工具链

gf工具链

bee工具链

Web: 性能测试

Web: HTTPS

HTTPS & TLS

支持

CustomHttpConfiguration

支持

Web: HTTP2

支持

Web: WebSocket

WebSocket做事

有

Web: 分组路由

路由注册-分组路由

Namespace

GroupingRoutes

有

Web: 路由冲突处理

有

Web: 域名支持

域名绑定

Web: 文件做事

静态文件做事

静态文件处理

ServingStaticFiles

有

Web: 多端口/实例

多端口监听、多实例监听

RunMultipleServiceUsingIris

Web: 优雅重启/关闭

平滑重启特性

热升级

GracefulShutdownOrRestart

GracefulRestartOrStop

ORM

ORM文档

Session

有

I18N支持

I18N

Localization

模板引擎

View设计

TemplateRendering

HtmlRendering

配置管理

参数配置

CustomHttpConfig

日志组件

Logging

数据校验

表单数据验证

CustomValidators

缓存管理

Cache

资源打包

资源管理

bee工具bale命令

链路跟踪

测试框架

单元测试

Testing

突出优点

goframe紧张以工程化和企业级方向为主，特殊是模块化设计和工程化设计思想非常棒。
针对业务项目而言，供应了开拓规范、项目规范、命名规范、设计模式、开拓工具链、丰富的模块、高质量代码和文档，社区生动。
作者也是资深的PHP开拓者，PHP转Go的小伙伴会倍感亲切。

beego开源的比较早，最早的一款功能比较全面的Golang开拓框架，一贯在Golang领域有着比较大的影响力，作者谢大多年组织着海内影响力比较大GopherCN活动。
beego有着比较丰富的开拓模块、开箱即用，供应了基于MVC设计模式的项目构造、开拓工具链，紧张定位为Web开拓，当然也可以用于非Web项目开拓。

iris紧张侧重于Web开拓，供应了Web开拓的一系列功能组件，基于MVC开拓模式。
iris这一年景长比较快，从一个Web Server的组件，也逐步朝着beego的设计方向努力。

gin专注于轻量级的Web Server，比较大略，易于理解，路由和中间件设计不错，可以看做替代标准库net/http.Server的路由加强版web server。
献给爱造轮子的朋友们。

突出缺陷

开源韶光较晚，推广过于佛系，目前紧张面向海内用户，未推广外洋。

起步较早，自谢大创业后，近几年景长较慢。
非模块化设计，对第三方重量级模块依赖较多。

号称性能最强，结果平平。
非模块化设计。
最近两年开始朝beego方向发展，但整体框架能力还不完备，须要加油。

功能大略易用，既是优点，也是缺陷。

履历分享

不同的需求场景，存在不同的选择。
选择适宜的工具，办理适宜的问题。

开源不存在孰好孰坏之分，开源作者能够本着开源精神给大家分享技能成果用以学习和利用，这本身便是一件非常不易并且值得称道的事情。

末了，笔者在这里跟大家分享一下自己所在团队的情形，以及在Golang技能栈转型过程中所走的弯路，希望能在框架选型这一环节，能给大家作一定参考。

团队最初痛点

团队转型Golang技能栈的一些背景。
紧张几点：

团队后端最初的紧张技能栈为PHP，由于业务发展须要，进行微做事改造。
初版微做事采取了PHP+JsonRpc的通信办法。
随着项目增多，公司也组件了自己的DevOps团队，底层支配转向了Docker+Kubernetes容器架构，并且引入了Golang技能栈。
由于一些痛点，通过一段韶光对PHP和Golang的比较，团队决定快速转型Golang技能栈，紧张痛点如下：PHP项目在业务繁芜后、项目中后期的开拓和掩护本钱整体偏高。
紧张缘故原由还是其过高的灵巧性，非构造化的变量设计，参差不齐的开拓职员本色。
上云容器化支配后，PHP的DevOps效率太低。
繁芜的Composer版本管理，超大的Docker镜像大小，都影响着DevOps的效率。
比较较而言，Golang效率极其高效。
JsonRpc通信协议设计下，接口的扩展性和灵巧性很高，但做事之间很难快速确定接口的输入与输出定义，只能根据文档和示例进行对接和掩护。
由于代码和文档分离，大部分场景下接口文档掩护每每滞后于接口变革。
随着做事的不断增加，非构造化的通信协议管理使得做事接口的开拓和掩护本钱进一步提高。
JsonRpc的通信协议实质基于HTTP1.x+Json，实行效率过低，算不上真正的微做事通信协议，很难对接上主流的做事管理框架。
比较较基于HTTP2.x的gRPC协议有着成熟微做事开拓框架和做事治理解决方案。
业务梳理的考量，PHP到Golang技能栈的迁移，实在也是一次技能重构的契机，在技能重构的过程中也重新梳理业务系统设计，偿还技能债务。
进一步的痛点

Golang确实足够大略，比较较其他的阐明类开拓措辞，没有过多的语法糖和措辞特性，因此团队上手很快，并快速完成了一部分业务系统的技能重构。
但随之而来的是更加严重的痛点。
紧张几点：

轮子过多：Golang实在太大略了，以至于我们的团队成员爆发了压抑许久的闷骚劲，充分发挥"造后不管"的造轮精神，开拓/封装了许多大大小小的轮子。
这些轮子均能知足最基本的功能，例如：日志、配置、缓存等等。
但轮子并不是实现一个根本功能的半成品就了事，须要担保功能性、稳定性、扩展性和可掩护性，要能结合更多生产实践验证，更须要能够长期掩护、持续进行迭代改进。
否则，便是一堆大小不一的成人玩具。
造轮一时爽，掩护火葬场。
直到现在，我们还在为分散在100多个Golang项目中的数十个成人玩具做大统一的事情痛楚不已。
当然，这个问题也跟组织架构和团队管理也有很大关系。
不成体系：我们坚信一个package只做一件事情，并且特地利用单仓库包的形式进行包管理，相称于每个package都是独立掩护的git仓库。
实在单仓库包和package设计并不存在必要性，反而独立的单仓库包提高了组件和框架的掩护本钱。
这种单仓库包设计难以形成技能体系，在团队技能管理上，难以形成统一的技能框架。
单仓包显得很伶仃，而一个技能体系的建立除了须要制订规范和标准，更须要技能框架来准确落地。
一个成体系的、统一的技能框架，至少涉及到数十个根本技能组件，不可能完备伶仃设计。
每一个package的根本功能实现都很大略，但是如何能够统一组织在一起却不是一件大略的事情，这须要团队的技能管理者须要有一定的技能秘闻、格局和前瞻性，而不是和普通开拓者那样眼界只能局限于package本身。
这种伶仃的单仓库包设计，对付业务项目的规范化约束不强，每一个组件都可以独立更换，也至于痛点1的问题加倍严重（连日志组件都好几套，虽然都知足基本的日志规范设计）。
终极，我们最初引以为傲的单仓库包设计，终极变成了一堆散沙。
例如，就连须要增加标准化的链路跟踪功能，由于单仓库包过于散乱和分歧一，使得推进改进本钱极其高昂。
除了使得技能体系难以建立，技能规范难以准确落地之外，每个组件的易用性也设计得较差。
举个大略例子，我们的日志组件、缓存组件、数据库组件、HTTP/gRPC Server组件都须要对接配置管理功能，单仓包须要担保低耦合设计，因此开拓者在利用的时候须要先手动读取配置、并转换为目标配置工具、并注入到对应的组件初始化方法中，随后才能将该工具利用到业务逻辑中，多少个业务项目均是重复此步骤。
实在goframe在这块的易用性设计就挺不错，每个包当然是独立设计的，在统一的技能框架体系下，再独立供应一个耦合的单例模块将常用的工具进行单例化封装，自动实现配置读取、配置工具转换、配置工具注入及组件工具初始化，开拓者仅须要调用一个单例方法即可。
而这个常用单例模块，成为了我们技能框架体系的一部分，极大地提高了业务项目的开拓和掩护效率。
版本不一致：在业务项目不断增多之后，轮子版本不一致性也越来越明显。
什么是版本不一致？举个例子。
我们有个轮子叫做httpClient，统共发布了10来个版本；我们统共有100多个Golang项目，险些每个版本都在利用。
我们提交了一个bug fix，却难以让所有项目都能更新。
对其他的轮子也是类似的情形，况且我们也有数十个各种轮子，被各个项目独立利用中。

经由反思总结，总结了以下几点：

团队须要一个统一的技能框架，而不是东拼西凑的一堆单仓库包。
我们只须要掩护一个框架的版本，而不是掩护数十个单仓库包的版本。
框架的组件必须模块化、低耦合设计，担保内部组件也可以独立引用。
核心组件严格禁止单仓库包设计，并且必须由框架统一掩护。
终极的决议

走过这么多弯路之后，我们决心建立一套成体系的Golang开拓框架。
除了哀求团队能够快速学习，掩护本钱低，并且我们最紧张的诉求，是核心组件不能是半成品，框架必须是上过大规模生产验证的，稳定和成熟的。
随着，我们重新对行业中盛行的技能框架做了技能评估，包括上面说的那些框架。
原来的初衷是想将内部的各个轮子统一做一个成体系的框架，在开源项目中找一些有代价的参考。

后来找到了goframe，仔细评估和学习了框架设计，创造框架设计思想和我们的履历总结如出一则！

这里不得不提一件尴尬的事情。
实在最开始转Golang之前（2019年中旬）也做过一些调研，那时goframe版本还不高，并且我们卖力评估的团队成员有一种先入为主的思想，看到模块和文档这么多，觉得该当挺繁芜，性能该当不高，于是没怎么看就PASS。
后来选择一些看起来大略的开源轮子自己做了些二次封装。

这次经由一段韶光的仔细调研和源码学习，得出一个结论，goframe框架的框架架构、模块化和工程化设计思想非常棒，实行效率很高，模块不仅丰富，而且质量之高，令人惊叹至极！
比较较我们之前写的那些半成品轮子，切实其实便是小巫见大巫。
团队踩了一年多的坑，才创造团队确实须要一个统一的技能框架而不是一堆不成体系的轮子，实在人家早已给了一条明光大道，并且一贯在前面默默努力。

经由团队内部的调研和谈论，我们决定利用goframe逐步重构我们的业务项目。
由于goframe是模块化设计的，因此我们也可以对一些模块做必要的更换。
重构过程比较顺利，根本技能框架的重构并不会对业务逻辑造成什么影响，反而通过goframe的工程化思想和很棒的开拓工具链，在统一技能框架后，极大地提高了项目的开拓和掩护效率，使得团队可以专心于业务开拓，部门也陆续有了更多的产出。
目前我们已经有大部门业务项目专向了goframe。
平台逐日流量千万级别。

感谢原作者

https://goframe.org/pages/viewpage.action?pageId=3673375