go| beego 速览

2021-07-04 13:51:22

本来想做一期 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 应用其实相当成熟了, 需要哪些功能已经十分清楚. 这个时候, 也许更应该来关注代码.

从图中可以看到, 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 个问题:

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

生命周期

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

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

一次请求的生命周期: 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

配置管理

安全

日志

其他

码农公寓

架构

生命周期

app & context

围绕 web 请求

url 的解析

路由注解和自动参数匹配

restful

URL Building

其他 web 相关服务一览

Model

更多 more

配置管理

安全

日志

其他

相关文章