Go web 教程

谢伟

发布于 2019-06-21 09:52:57

1.2K0

发布于 2019-06-21 09:52:57

文章被收录于专栏：GopherCoder

GOPHER_AVATARS.jpg

Go Web 新手教程

大家好，我叫谢伟，是一名程序员。

web 应用程序是一个各种编程语言一个非常流行的应用领域。

那么 web 后台开发涉及哪些知识呢？

模型设计：关系型数据库模型设计
SQL、ORM
Restful API 设计

模型设计

web 后台开发一般是面向的业务开发，也就说开发是存在一个应用实体：比如，面向的是电商领域，比如面向的是数据领域等，比如社交领域等。

不同的领域，抽象出的模型各不相同，电商针对的多是商品、商铺、订单、物流等模型，社交针对的多是人、消息、群组、帖子等模型。

尽管市面是的数据库非常繁多，不同的应用场景选择不同的数据库，但关系型数据库依然是中小型企业的主流选择，关系型数据库对数据的组织非常友好。

能够快速的适用业务场景，只有数据达到某个点，产生某种瓶颈，比如数据量过多，查询缓慢，这个时候，会选择分库、分表、主从模式等。

数据库模型设计依然是一个重要的话题。良好的数据模型，为后续需求的持续迭代、扩展等，非常有帮助。

如何设计个良好的数据库模型？

遵循一些范式：比如著名的数据库设计三范式
允许少量冗余

细讲下来，无外乎：1。数据库表设计 2。数据库字段设计、类型设计 3。数据表关系设计：1对1，1对多，多对多

1。数据库表设计

表名这个没什么讲的，符合见闻之意的命名即可，但我依然建议，使用 database+实体的形式。

比如：beeQuick_products 表示：数据库：beeQuick ，表：products

真实的场景是，设计的：生鲜平台：爱鲜蜂中商品的表

2。数据库字段设计

字段设计、类型设计

字段的个数：字段过多，后期需要进行拆表；字段过少，会涉及多表操作，所以拿捏尺度很重要，给个指标：少于12个字段吧。
如何设计字段？：根据抽象的实体，比如教育系统：学生信息、老师信息、角色等，很容易知道表中需要哪些字段、字段类型。
如果你知道真实场景，尽量约束字段所占的空间，比如：电话号码 11 位，比如：密码长度不多于12位

外键设计

外键原本用来维护数据一致性，但真实使用场景并不会这么用，而是依靠业务判断，比如，将某条记录的主键当作某表的某个字段

1对1，1对多，多对多关系

1对1：某表的字段是另一个表的主键

type Order struct{
    base
    AccountId  int64
}

1对多：某表的字段是另一个表的主键的集合

type Order struct {
    base       `xorm:"extends"`
    ProductIds []int `xorm:"blob"`
    Status     int
    AccountId  int64
    Account    Account `xorm:"-"`
    Total      float64
}

多对多：使用第三张表维护多对多的关系

type Shop2Tags struct {
    TagsId int64 `xorm:"index"`
    ShopId int64 `xorm:"index"`
}

ORM

ORM 的思想是对象映射成数据库表。

在具体的使用中：

1。根据 ORM 编程语言和数据库数据类型的映射，合理定义字段、字段类型 2。定义表名称 3。数据库表创建、删除等

在 Go 中比较流行的 ORM 库是： GORM 和 XORM ，数据库表的定义等规则，主要从结构体字段和 Tag 入手。

字段对应数据库表中的列名，Tag 内指定类型、约束类型、索引等。如果不定义 Tag, 则采用默认的形式。具体的编程语言类型和数据库内的对应关系，需要查看具体的 ORM 文档。

// XORM
type Account struct {
    base     `xorm:"extends"`
    Phone    string    `xorm:"varchar(11) notnull unique 'phone'" json:"phone"`
    Password string    `xorm:"varchar(128)" json:"password"`
    Token    string    `xorm:"varchar(128) 'token'" json:"token"`
    Avatar   string    `xorm:"varchar(128) 'avatar'" json:"avatar"`
    Gender   string    `xorm:"varchar(1) 'gender'" json:"gender"`
    Birthday time.Time `json:"birthday"`

    Points      int       `json:"points"`
    VipMemberID uint      `xorm:"index"`
    VipMember   VipMember `xorm:"-"`
    VipTime     time.Time `json:"vip_time"`
}

// GORM
type Account struct {
    gorm.Model
    LevelID  uint
    Phone    string    `gorm:"type:varchar" json:"phone"`
    Avatar   string    `gorm:"type:varchar" json:"avatar"`
    Name     string    `gorm:"type:varchar" json:"name"`
    Gender   int       `gorm:"type:integer" json:"gender"` // 0 男 1 女
    Birthday time.Time `gorm:"type:timestamp with time zone" json:"birthday"`
    Points   sql.NullFloat64
}

另一个具体的操作是：完成数据库的增删改查，具体的思想，仍然是操作结构体对象，完成数据库 SQL 操作。

当然对应每个模型的设计，我一般都会定义一个序列化结构体，真实模型的序列化方法是返回这个定义的序列化结构体。

具体来说：

// 定义一个具体的序列化结构体，注意名称的命名，一致性
type AccountSerializer struct {
    ID        uint                `json:"id"`
    CreatedAt time.Time           `json:"created_at"`
    UpdatedAt time.Time           `json:"updated_at"`
    Phone     string              `json:"phone"`
    Password  string              `json:"-"`
    Token     string              `json:"token"`
    Avatar    string              `json:"avatar"`
    Gender    string              `json:"gender"`
    Age       int                 `json:"age"`
    Points    int                 `json:"points"`
    VipMember VipMemberSerializer `json:"vip_member"`
    VipTime   time.Time           `json:"vip_time"`
}

// 具体的模型的序列化方法返回定义的序列化结构体
func (a Account) Serializer() AccountSerializer {

    gender := func() string {
        if a.Gender == "0" {
            return "男"
        }
        if a.Gender == "1" {
            return "女"
        }
        return a.Gender
    }

    age := func() int {
        if a.Birthday.IsZero() {
            return 0
        }
        nowYear, _, _ := time.Now().Date()
        year, _, _ := a.Birthday.Date()
        if a.Birthday.After(time.Now()) {
            return 0
        }
        return nowYear - year
    }

    return AccountSerializer{
        ID:        a.ID,
        CreatedAt: a.CreatedAt.Truncate(time.Minute),
        UpdatedAt: a.UpdatedAt.Truncate(time.Minute),
        Phone:     a.Phone,
        Password:  a.Password,
        Token:     a.Token,
        Avatar:    a.Avatar,
        Points:    a.Points,
        Age:       age(),
        Gender:    gender(),
        VipTime:   a.VipTime.Truncate(time.Minute),
        VipMember: a.VipMember.Serializer(),
    }
}

项目结构设计

├── cmd
├── configs
├── deployments
├── model
│   ├── v1
│   └── v2
├── pkg
│   ├── database.v1
│   ├── error.v1
│   ├── log.v1
│   ├── middleware
│   └── router.v1
├── src
│   ├── account
│   ├── activity
│   ├── brand
│   ├── exchange_coupons
│   ├── make_param
│   ├── make_response
│   ├── order
│   ├── product
│   ├── province
│   ├── rule
│   ├── shop
│   ├── tags
│   ├── unit
│   └── vip_member
└── main.go
└── Makefile

为什么要进行项目结构的组织？就问你个问题：杂乱的屋里，找一件东西快，还是干净整齐的屋里，找一件东西快？

合理的项目组织，利于项目的扩展，满足多变的需求，这种模块化的思维，其实在编程中也常出现，比如将整个系统根据功能划分。

cmd 用于命令行
configs 用于配置文件
deployments 部署脚本，Dockerfile
model 用于模型设计
pkg 用于辅助的库
src 核心逻辑层，这一层，我的一般组织方式为：按模型设计的实体划分不同的文件夹，比如上文账户、活动、品牌、优惠券等，另外具体的处理逻辑，我又这么划分：

├── assistance.go // 辅助函数，如果重复使用的辅助函数，会提取到 pkg 层，或者 utils 层
├── controller.go // 核心逻辑处理层
├── param.go // 请求参数层：包括参数校验
├── response.go // 响应信息
└── router.go // 路由

main.go 函数入口
Makefile 项目构建

当然你也可以参考：https://github.com/golang-standards/project-layout

框架选择

gin
iris
echo ...

主流的随便选，问题不大。使用原生的也行，但你可能需要多写很多代码，比如路由的设计、参数的校验：路径参数、请求参数、响应信息处理等

Restful 风格的API开发

路由设计
参数校验
响应信息

路由设计

尽管网上存在很多的 Restful 风格的 API 设计准则，但我依然推荐你看看下文的介绍。

域名（主机）

推荐使用专有的 API 域名下，比如：https://api.example.com

但实际上直接放在主机下：https://example.com/api

版本

需求会不断的变更，接口也会在不断的变更，所以，最好给 API 带上版本：比如：https://example.com/api/v1，表示第一个版本。

有些会在头部信息里带版本信息，不推荐，不直观。

方式这么些，但一定要统一。在头部信息里带版本信息，那么就一直这样。如果在路路径内，就一致在路径内，统一非常重要。

请求方法

POST: 在服务器上创建资源，对应数据库操作是：create
PATCH: 在服务器上更新资源，对应的数据库操作是：update
DELETE: 在服务器上删除资源，对应的数据库操作是：delete
GET: 在服务器上获取资源，对应的数据库操作是：select
其他：不常用

路由设计

整体推荐：版本 + 实体（名词） 的形式：

举个例子：上文的项目结构中的 order 表示的是订单实体。

那么路由如何设计？

POST /api/v1/order
PATCH /api/v1/order/{order_id:int}
DELETE /api/v1/order/{order_id:int}
GET /api/v1/orders

尽管还存在其他方式，但我依然推荐需要保持一致性。

比如活动接口：

POST /api/v1/activity
PATCH /api/v1/activity/{activity_id:int}
DELETE /api/v1/activity/{activity_id:int}
GET /api/v1/activities

保持一致性。

参数校验

路由设计中涉及的一个重要的知识点是：参数校验

比如参数类型校验
比如参数长度校验
比如指定选项校验

上文项目示例每个实体的接口具体的项目结构如下：

├── assistance.go
├── controller.go
├── param.go
├── response.go
└── router.go

param.go 核心的就是组织接口中参数的定义、参数的校验

参数校验有两种方式：1: 使用结构体方法实现校验逻辑；2: 使用结构体中的 Tag 定义校验。

type RegisterParam struct {
    Phone    string `json:"phone"`
    Password string `json:"password"`
}

func (param RegisterParam) suitable() (bool, error) {
    if param.Password == "" || len(param.Phone) != 11 {
        return false, fmt.Errorf("password should not be nil or the length of phone is not 11")
    }
    if unicode.IsNumber(rune(param.Password[0])) {
        return false, fmt.Errorf("password should start with number")
    }
    return true, nil
}

像这种方式，自定义参数结构体，结构体方法来进行参数的校验。

缺点是：需要写很多的代码，要考虑很多的场景。

另外一种方式是：使用结构体的 Tag 来实现。

type RegisterParam struct {
    Phone    string `form:"phone" json:"phone" validate:"required,len=11"`
    Password string `form:"password" json:"password"`
}

func (r RegisterParam) Valid() error {
    return validator.New().Struct(r)
}

后者使用的是：https://godoc.org/gopkg.in/go-playground/validator.v9 校验库，gin web框架的参数校验采用的也是这种方案。

覆盖的场景，特别的多，使用者只需要关注结构体内 Tag 标签的值即可。

对数值型参数：校验的方向有：1、是否为 0 ；2、最大值，最小值（比如翻页操作，每页的显示）3、区间、大于、小于、等
对字符串型参数：校验的方向有：1、是否为你来；2、枚举或者特定值：eq="a"|eq="b" 等
特定的场景：比如邮箱、颜色、Base64、十六进制等

最常用的还是数值型和字符串型

响应信息

前后端分离，最流行的数据交换格式是：json。尽管支持各种各种的响应信息，比如 html、xml、string、json 等。

构建 Restful 风格的API，我只推荐 json，方便前端或者客户端的开发人员调用。

确定好数据交换的格式为 json 之后，还需要哪些关注点？

状态码
具体的响应信息

{
    "code": 200,
    "data": {
        "id": 1,
        "created_at": "2019-06-19T23:14:11+08:00",
        "updated_at": "2019-06-20T10:40:09+08:00",
        "status": "已付款",
        "phone": "18717711717",
        "account_id": 1,
        "total": 9.6,
        "product_ids": [
            2,
            3
        ]
    }
}

推荐统一使用上文的格式： code 用来表示状态码，data 用来表示具体的响应信息。

如果是存在错误，则推荐使用下面这种格式：

{
    "code": 404,
    "detail": "/v1/ordeda",
    "error": "no route /v1/orderda"
}

状态码也区分很多种：

1XX: 接受到请求
2XX: 成功
3XX: 重定向
4XX: 客户端错误
5XX: 服务端错误

根据具体的场景选择状态码。

真实的应用是：在 pkg 包下定义一个 err 包，实现 Error 方法。

type ErrorV1 struct {
    Detail  string `json:"detail"`
    Message string `json:"message"`
    Code    int    `json:"code"`
}

type ErrorV1s []ErrorV1

func (e ErrorV1) Error() string {
    return fmt.Sprintf("Detail: %s, Message: %s, Code: %d", e.Detail, e.Message, e.Code)
}

定义一些常用的错误信息和错误码：

var (

    // database
    ErrorDatabase       = ErrorV1{Code: 400, Detail: "数据库错误", Message: "database error"}
    ErrorRecordNotFound = ErrorV1{Code: 400, Detail: "记录不存在", Message: "record not found"}

    // body
    ErrorBodyJson   = ErrorV1{Code: 400, Detail: "请求消息体失败", Message: "read json body fail"}
    ErrorBodyIsNull = ErrorV1{Code: 400, Detail: "参数为空", Message: "body is null"}
)

其他

API 文档：比较流行的是 swagger 文档，文档是其他开发人员了解接口的重要途径，考虑到沟通成本，API 文档必不可少。
日志：日志是方便开发人员查看问题的，也必不可少，业务量不复杂，日志写入文件中持久化即可；稍复杂的场景，可以选择 ELK
Dockerfile: web 应用，当然非常适合以容易的形式部署在主机上
Makefile: 项目构建命令，包括一些测试、构建、运行启动等

Go web 路线图

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2019.06.21 ，如有侵权请联系 cloudcommunity@tencent.com 删除

api

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

api

登录后参与评论

0 条评论

热度

Go web 教程

Go web 教程

Go Web 新手教程

模型设计

1。数据库表设计

2。数据库字段设计

ORM

项目结构设计

框架选择

Restful 风格的API开发

路由设计

参数校验

响应信息

其他

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

Go web 教程

Go web 教程

Go Web 新手教程

模型设计

1。 数据库表设计

2。 数据库字段设计

ORM

项目结构设计

框架选择

Restful 风格的API开发

路由设计

参数校验

响应信息

其他

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

1。数据库表设计

2。数据库字段设计