go| beego 速览-阿里云开发者社区

本来想做一期 beego源码解读的, 不过作为 go 初学者, 代码量还没提上来前, 正应当多看多写, 做源码解读实在火候不够. 这里综合自己学习 beego 的一些感受:

融入到自己对 Web 应用框架 开发知识的积累中, 以期可以应用到自己参与的开源项目 - Swoft 中.

web framework 知识图谱: http://naotu.baidu.com/file/a045802b858c57c56c73dd2e7bda50b5?token=fccd16c1458c78bd
Modern High performance AOP and Coroutine PHP Framework - Swoft: https://github.com/swoft-cloud/swoft

架构

说架构的时, 往往会 面向业务 进行抽象, 所以经常看到的架构, 大抵都是 分层/分子系统, 一个又一个 豆腐块. web 应用其实相当成熟了, 需要哪些功能已经十分清楚. 这个时候, 也许更应该来关注代码.

The architecture of Beego

从图中可以看到, beego 架构很简单, 一言以蔽之: 组件化(或者说模块化). 一个 web 应用, 其实就是 一组组件协同工作 的结果.

Swoft1.0 的一大重要重构, 就是实现组件化. 目前在 PHP 框架中, 组件化实现最好的要算 laravel 和 symfony 了.

PS: Swoft 的现状是一个组件一个 git 仓库. 更正规的方式是一个中央仓库(例如叫 framework), 所有的修改都是 fork/push 到这个仓库, 每次发版时, 中央仓库执行一个 build 脚本(使用 [https://github.com/dflydev/
git-subsplit](https://github.com/dflydev/git-subsplit)) , 将 framework 下的代码推到不同的子项目仓库, 并且给每个组件仓库打一个统一的 tag. 最终所有的修改都在 framework 仓库, 组件仓库只读状态, 不接受 pr/push, 只接受 build 脚本的 split. 可以参考的 laravel 的 build 脚本: https://github.com/laravel/framework/blob/5.1/build/illuminate-split-full.sh

组件化后, 可以明显减少重复造轮子, 更好的代码复用. 组件化其实很好的回答下面 2 个问题:

依赖如何管理
如何分享代码

生命周期

快速上手一个框架, 优先关注生命周期, 了解代码的执行逻辑.

The execution logic of Beego

beego 框架生命周期: 启动应用(app) -> 一次请求进来 -> 路由(route) -> 过滤器(filter, 有的框架使用 Middleware, 作用相同) -> 控制器(Controller) -> 和各模块交互 -> 返回(response)

Introduction to Beego’s MVC

一次请求的生命周期: context(请求上下文) -> 路由(Route, 静态文件/动态) -> 路由匹配(fixed/regex/auto) -> filter -> Controller(和各模块交互) -> filter -> 返回(response)

PS: beego 中 module 意为组件, 而在 yii 框架中, module 意为模块, 包含一个完整的 MVC 应用, 而组件用的单词为 component. yii 的项目中是可以存在多个 module 的, 即 一个项目多个应用. 可想而知, yii 这样的功能, 最终会导致一个 超大规模的项目.

app & context

app 通常作为整个应用的抽象. PHP框架中的常见划分是 web应用 和 console应用. 不过和传统 PHP 框架最大的不同是, 传统 fpm 多进程模式下, 每次请求都需要初始化一次应用. 而在 beego 和 Swoft 下, 应用是常驻内存的, 只需要启动时初始化一次 app 即可.

这也就造成了很多使用 fpm 的 PHPer 不知道 context 这个概念. context, 请求上下文, 包含一次请求的 request/response. 因为 fpm 是多进程的, 每次请求都是独立在每个进程中并且重新初始化一次应用. beego 或 Swoft 只初始化一次 app, 所以需要 context 来作为每次请求的抽象. 这也是为什么传统框架中, PHPer 依然可以使用 $_GET/$_POST 等超全局变量, 而在 Swoft 这样基于 Swoole 的框架中, 必须使用框架提供的方法. 其实质就是对 context 封装.

app 和 context 的分离, 其实可说是必然, 2 者有着不同的生命周期.

围绕 web 请求

Model-View-Controller 这样的架构可以说是 深入人心 了, 以至于不这样的 web应用, 还会不习惯. 现实中的 web应用, 当然不止 MVC 这三个模块.

url 的解析

url 的解析, 包含 2 个方向:

从 url 到业务代码 -> 路由模块(route)
反向生成 url -> URL build 模块

路由模块相对复杂, 功能会多一些:

在形式上, 支持 fixed/regex/auto 方式进行匹配, 匹配顺序 fixed -> regex -> auto
支持 http method, 比如某个请求只允许 GET 请求
支持 restful
namespace, 命名空间, 比如版本控制, 一部分 url 都使用 v1/ 前缀, 另一部分使用 v2/ 前缀
注解(annotation) 和自动参数匹配(auto parameter)

路由注解和自动参数匹配

先看代码:

// @router /tasks/:id [get]
func (c *TaskController) MyMethod(id int, field string) (map[string]interface{}, error) {
    if u, err := getObjectField(id, field); err == nil {
        return u, nil
    } else {
        return nil, context.NotFound
    }
}

// 省去的路由代码
beego.Router("/task/:id", &TaskController{}, "get:MyMethod")

// 省去的获取参数(路由参数/请求参数)的代码
id := c.GetInt("id")
field := c.GetString("field")

使用注解后, 就省去了在路由中的代码, 如果全局都使用注解, 就可以省去路由文件, Swoft 就是如此做的. 至此, 我们可以对比一下路由解析形式的 4 种方式:

fixed: 所见即所得, 缺点是 url 太多了就需要写很多
regex: 正则匹配, 不常用, 大部分也只用在路由参数的地方, 比如 /user/[\d]+/task/[\d]+
auto: 自动匹配, yii 中就是使用这种方式, 约定 url 优先匹配 Controller + Action, laravel 中的也支持 Controller 级别的自动路由
annotation: 注解, 既能保持代码的简洁, 又可以保留路由模块的灵活性

所以我理想中的路由形式: 大部分可以直接自动匹配, 少部分的特殊需求使用注解, 独立的路由文件可有可无.

路由中使用注解, 要遵守 约定大于配置 的思想. 比如上面的示例改成这样:

// @router /mission/:id [get]
func (c *TaskController) MyMethod(id int, field string) (map[string]interface{}, error) {
    if u, err := getObjectField(id, field); err == nil {
        return u, nil
    } else {
        return nil, context.NotFound
    }
}

原来我只需要使用 IDE 的文件查找功能, 查找类似 TaskController 的文件, 现在就得先全局搜索 /mission, 再根据搜索结果定位到代码.

自动参数匹配比较适合在参数比较少的时候使用, 这个就看个人编码习惯了, 加一个参数可以少写一行代码, 这个功能还是有必要支持的.

restful

restful 是现在比较流行的一种软件架构风格/设计风格. 以资源为核心, 配合 http method(GET/POST/PUT/DELETE) 进行资源的管理.

不过现实是大部分情况下, 大家只用 GET/POST. 面对业务进行设计的时, 也很少会 以资源为核心, 怎么简单怎么来或者说怎么快怎么来. 而且要发起 PUT 请求, 你需要这样的表单:

<form method="post" ...>
  <input type="hidden" name="_method" value="put" />
  ...
</form>

虽然现在 restful 很流行, 很多框架也都标榜轻松就可以实现. 是否需要用, 还是自己判断.

URL Building

beego 中使用 URL Building 来反向生成 url, 比如:

// route
beego.Router("/api/list", &TestController{}, "*:List")
beego.Router("/person/:last/:first", &TestController{})
beego.AutoRouter(&TestController{})

// URL Building
URLFor("TestController.List") // Output /api/list
URLFor("TestController.Get", ":last", "xie", ":first", "asta") // Output /person/xie/asta
URLFor("TestController.Myext") // Output /Test/Myext
URLFor("TestController.GetUrl") // Output /Test/GetUrl

其他框架可能会使用 url() route(), 一个表示 url, 一个表示 route(路由), 不过我倾向于 简单点, 只用 url. 虽然有些时候用 route 来表达(比如 restful) 会简单一些.

其他 web 相关服务一览

Form validation: 参数校验, 这个模块主要解决一些常用的参数校验, 比如 e-mail, 金额等
response format: 返回值格式, 常见的有 html(view) json xml jsonp. Swoft 中推荐 返回的格式类型, 不应该由服务端指定, 而是根据客户端请求时的 Header 里面的 Accept 决定, 控制器中只用返回数据, 框架自动进行格式转换
view: 视图, beego 中包含 2 个功能, 模板引擎(temple) 和分页(pagination). 模板引擎方便组织前端代码, 这样 Controller 中只要返回数据即可; 分页也是常见的功能, yii/laravel 在这方面做得很极致, 不仅有分页, 还有其他页面相关的组件
Filters: 过滤器, 其他框架中可能使用 Middleware(中间件), 功能类似, 其实就是将一部分功能从业务中隔离, 比如网站开启维护状态, user authentication, log visiting, compatibility switching.
Flash Messages: 一次性通知消息, 其实是一次性的 消息 - 订阅 功能, 比如页面上通知操作成功
Error Handling: 错误处理, 在 web 请求中, 通常配合 http code + redirect + error page
Session: session/cookie 其实很简单, 无论什么框架, 变来变去就那么几个方法, 更重要的是知道 -- 有什么用; 有哪些方法; 使用不同的驱动

Model

简单说: 如何和数据打交道. 其实上面的 session / cookie / flash message 等, 都在不同场合下和数据打交道, 这里讲讲数据更原始的地方:

和关系型数据库打交道, 如 mysql
和文档型数据库打交道, 如 MongoDB
和键值型数据库打交道, 如 redis, 通常用作缓存, 也可用作 session

主要说一下和关系型数据库打交道, 通常涉及一下几个方面:

对数据库连接进行抽象, 这样可以方便 切换数据库, 切换主从 等
对数据的抽象, 比如一个 Model 类对一个张数据表, 从而方便的实现 CRUD 功能
对 sql 语句的抽象: raw, 支持原生语句的执行; QuerySeter, 对 sql 原语的抽象, 比如 > = < like 等操作符; queryBuilder, 拼接 sql 语句
支持数据库事务(transaction), 要注意事务的写法, 如果发生嵌套如何写

// beego 中的 transaction
o := NewOrm()
err := o.Begin()
// transaction process
...
...
// All the query which are using o Ormer in this process are in the transaction
if SomeError {
    err = o.Rollback()
} else {
    err = o.Commit()
}

支持表的关联(relation), 比如在 yii 中, 只要定义一个方法, 就可以在查询当前表时, 将关联表的数据, 自动赋值给当前表对象的属性中

// beego 中的 relation
type Post struct {
    Id    int    `orm:"auto"`
    Title string `orm:"size(100)"`
    User  *User  `orm:"rel(fk)"`
}

var posts []*Post
qs := o.QueryTable("post")
num, err := qs.Filter("User__Name", "slene").All(&posts

go| beego 速览

架构

生命周期

app & context

围绕 web 请求

url 的解析

路由注解和自动参数匹配

restful

URL Building

其他 web 相关服务一览

Model

更多 more

配置管理

安全

日志

其他

热门文章

最新文章

相关课程

相关电子书

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

go| beego 速览

架构

生命周期

app & context

围绕 web 请求

url 的解析

路由注解和自动参数匹配

restful

URL Building

其他 web 相关服务一览

Model

更多 more

配置管理

安全

日志

其他

热门文章

最新文章

相关课程

相关电子书