标签 github 下的文章

通过实例理解Web应用授权的几种方式

本文永久链接 – https://tonybai.com/2023/11/04/understand-go-web-authz-by-example

在前面的系列文章中,我们了解了Go Web应用身份认证的几种方式,也知道了该如何相对安全地存储用户的密码信息,最大程度减小在系统数据库被攻破时用户密码信息的泄露程度。

一旦用户通过身份验证,他/她就可以以合法的身份进入到系统中,那么问题来了:用户进入系统后是否就可以“为所欲为”了呢?显然不是! 比如我们以普通用户身份登录github,身份验证成功后,我们只能增删改自己账号下的代码仓库数据或读取其他用户的公开仓库(public)数据,我们无法修改和删除其他用户下面的仓库数据,甚至看不到其他用户的私有仓库。Web应用系统(比如github)的这种对用户可以使用什么功能、可以访问和修改哪些数据的管理和控制,就是授权(Authorization),简称为AuthZ

在这篇文章中,我们就结合实例一起来了解一下Web应用都有哪些种授权方式。

1. 授权:基于访问控制策略的评估与决策

Go Web应用身份认证的几种方式一文中,我们简要说明了身份认证(AuthN)与授权(AuthZ)的关系与差异。授权是基于用户身份认证的基础之上的,按时间发生顺序,授权也是发生在身份认证之后的。

授权的目的是限制合法用户在系统中的操作,限制未经允许的访问。这让很多人将授权与访问控制(access control)直接划上了等号。其实授权与访问控制的确是密不可分的,但它们之间也不是可以简单划等号的。下面示意图展示了一个Web应用系统中授权与访问控制的关系:

从广义上看,授权和访问控制都属于对系统资源或信息的保护,它们的目的是限制未经授权的访问。从具体来看,访问控制关注的是如何控制主体访问对象,是一种机制或方法,它通常会定义访问模型以及相关访问策略;而授权则关注主体是否有权访问对象,是在已知用户身份以及访问控制策略下对访问请求的评估和决策过程,并得出主体是否具有访问权限的最终结果。

从上图我们也可以看到:授权是建立在访问控制之上的。访问控制定义了授权评估所需的模型、策略、机制和规则,授权则是在这套规则下,评估一个主体对一个对象的操作是否被允许,两者关系密不可分。在实现上,我们通常会联合使用“访问控制”和“授权”这两个概念,对外部更多用授权一词作为这个过程的统称。

到这里,我们理解了访问控制与授权的关系 – 访问控制提供了授权评估所需的模型和规则体系。针对不同的应用场景,IT界有几种典型的访问控制模型被提出和使用:

  • 访问控制列表(Access Control List,ACL)
  • 强制访问控制(Mandatory Access Control,MAC)
  • 自主访问控制(Discretionary Access Control,DAC)
  • 基于属性的访问控制(Attribute-Based Access Control, ABAC)
  • 基于角色的访问控制(Role-Based Access Control, RBAC)

这些模型为我们建立访问策略提供了框架和抽象工具。理解不同访问控制模型的思想和适用场景,可以帮助我们更好地制定系统的安全访问策略。在接下来的内容中,我们会简单介绍这几种访问控制模型,包括它们应用场景、优缺点等。这也将帮助大家建立访问控制和授权评估的整体视角,也可以为后续使用Go语言实现授权控制的实例提供理论基础。

2. 访问控制模型

和任何其它IT技术一样,访问控制模型也有着自己的演进历史过程。下面我们沿着模型演进的时间线,逐个认识一下各个模型。

2.1 访问控制列表(Access Control List,ACL)

ACL是最早的访问控制模型,基于ACL的访问控制会直接在被访问对象(也称为客体(O – Object))上设置允许/拒绝访问的主体(S – Subject)列表,最典型的就是Unix/Linux文件系统中文件的访问模型,如下图:

由此可见,这个模型并非专属于Web应用授权。早在上世纪60年代,它就广泛应用在操作系统中文件系统的访问权限管理。在1965年,Multics操作系统第一个实现了基于ACL模型的文件系统访问权限管理。POSIX曾推出ACL标准化草案,但后来放弃。但ACL并未因此受到打击,后来在NFSv4、Windows、Unix等系统中都有实现。之后,ACL被广泛地应用于网络领域,包括路由器、交换机以及防火墙都借助于访问控制列表来有效地控制用户对网络的访问,从而最大程度地保障网络安全。

ACL模型的优点是简单易用,但也存在灵活性差、难于扩展和满足复杂应用场景访问控制要求等不足。

ACL模型在现代Web应用中使用的越来越少,仅用于少数控制对特定资源访问权限的特定场景。例如,在静态文件服务器中,可以通过在文件系统中使用ACL来控制对文件或目录的访问权限。在复杂的现代Web应用领域,一些由ACL发展演化出的更灵活、更具扩展性的模型已经发展起来并走到了前台,比如后续即将要提到的RBAC和ABAC模型。

2.2 强制访问控制(Mandatory Access Control,MAC)

强制访问控制(Mandatory Access Control,MAC)起源于军用的多级安全系统,在MAC模型中,系统层强制执行访问控制策略,用户层无法更改。在操作系统领域,我们熟知的Linux的SELinuxAppArmor,Windows的Mandatory Integrity Control都属于MAC模型的实现。这种模型通常用于需要高度安全的环境,如军事或政府部门。

不过,MAC由于其中心化的强制控制方式,让其灵活性较差,并且实施起来相对复杂,在现代Web应用领域的使用场景有限。我理解这种MAC模型映射到Web应用领域的具体呈现就是“写死”到代码中的访问控制逻辑和授权决策逻辑,这些“系统层”逻辑是所有到达Web应用的请求必经的且无法进行配置和改变的。

一个典型的应用就是对资源根据安全等级进行的强制访问控制:用户只能访问其安全等级低于或等于自身安全等级的资源。下面是一个演示性质的代码例子:

// authz-examples/mac/main.go

// 定义安全等级
type SecurityLevel int

const (
    // 最低安全等级
    LevelLow SecurityLevel = iota
    // 中等安全等级
    LevelMedium
    // 最高安全等级
    LevelHigh
)

// 定义资源
type Resource struct {
    // 资源名称
    Name string
    // 安全等级
    Level SecurityLevel
}

// 定义用户
type User struct {
    // 用户名
    Name string
    // 安全等级
    Level SecurityLevel
}

// 定义访问控制策略
func CheckAccess(user User, resource Resource) bool {
    // 检查用户的安全等级是否高于或等于资源的安全等级
    return user.Level >= resource.Level
}

func main() {
    // 创建资源
    resource := Resource{
        Name:  "敏感数据",
        Level: LevelHigh,
    }

    // 创建用户
    user := User{
        Name:  "管理员",
        Level: LevelHigh,
    }

    // 检查访问权限
    if CheckAccess(user, resource) {
        fmt.Printf("用户[%s]有权访问资源\n", user.Name)
    } else {
        fmt.Printf("用户[%s]没有权限访问资源\n", user.Name)
    }

    // 创建用户
    user = User{
        Name:  "访客",
        Level: LevelLow,
    }

    // 检查访问权限
    if CheckAccess(user, resource) {
        fmt.Printf("用户[%s]有权访问资源\n", user.Name)
    } else {
        fmt.Printf("用户[%s]没有权限访问资源\n", user.Name)
    }
}

在这个例子中,我们定义了三个安全等级:LevelLow、LevelMedium和LevelHigh。资源和用户都被分配了安全等级。CheckAccess函数用于执行强制的访问控制策略:即用户只能访问其安全等级低于或等于自身安全等级的资源。

2.3 自主访问控制(Discretionary Access Control,DAC)

DAC模型基于资源所有者对其资源的访问权限进行授予和控制。在DAC模型中,资源的所有者可以自主决定哪些用户或实体可以访问他们的资源,以及对资源的访问权限级别。资源的所有者可以决定将资源设置为公开访问、私有访问或仅限于特定用户或用户组的访问。通过授权用户或实体访问资源,资源的所有者具有灵活性和自主权来管理他们的资源。

很显然,这样的DAC模型具有较为灵活的优点,允许资源所有者根据自己的需求和偏好授予和撤销访问权限。这使得资源的访问控制可以针对个体用户进行定制,满足不同用户的需求。同时,DAC模型具备分散控制的特征,它将访问控制的决策权下放给资源的所有者,而不是集中在中央管理机构。这样可以减轻管理负担,并且资源的所有者可以更直接地管理和控制自己的资源。

使用自主访问控制(DAC)模型进行访问控制的Web应用的典型例子是文件共享服务,即我们经常说的网盘服务,比如Google Drive、Dropbox或百度网盘等。在这样的应用中,用户可以上传、存储和共享文件。并使用DAC模型,设置文件或文件夹的访问权限,例如私有、只读或读写访问。用户还可以选择将文件或文件夹的访问权限限制为特定的用户或用户组。

另一种使用DAC模型进行访问控制的Web应用示例是社交媒体应用,这类应用允许用户发布和查看帖子,并给每个帖子分配权限以控制其他用户对其的访问权限,权限可以是“公开”、“好友”、“私人”等,

下面是一个DAC模型的演示性质的代码例子:

// authz-examples/dac/main.go

type Resource struct {
    Name      string
    Owner     string
    AccessMap map[string]bool
}

func (r *Resource) GrantAccess(user string) {
    r.AccessMap[user] = true
}

func (r *Resource) RevokeAccess(user string) {
    r.AccessMap[user] = false
}

func (r *Resource) CanAccess(user string) bool {
    access, exists := r.AccessMap[user]
    if !exists {
        return false
    }
    return access
}

func main() {
    // 创建一个资源
    resource := Resource{
        Name:      "example.txt",
        Owner:     "alice",
        AccessMap: make(map[string]bool),
    }

    // 授予访问权限给用户
    resource.GrantAccess("alice")
    resource.GrantAccess("bob")

    // 验证访问权限
    fmt.Println("alice can access:", resource.CanAccess("alice")) // 输出: true
    fmt.Println("bob can access:", resource.CanAccess("bob"))     // 输出: true
    fmt.Println("eve can access:", resource.CanAccess("eve"))     // 输出: false

    // 撤销访问权限
    resource.RevokeAccess("bob")

    // 验证访问权限
    fmt.Println("bob can access:", resource.CanAccess("bob")) // 输出: false
}

在这个示例中,我们定义了一个Resource结构,包含资源的名称、所有者和访问权限的map。用户可以调用GrantAccess方法授予其他用户对资源的访问权限,RevokeAccess方法则用于撤销用户的访问权限,CanAccess方法用于验证用户是否具有访问资源的权限。通过这个示例,我们也可以看到,MAC模型可以基于一个ACL(比如AccessMap)来实现。

DAC模型那些固有的特点带来的也并不都是好处,也可能给应用带来一定的安全性挑战。比如:由于访问权限由资源的所有者授予,因此可能存在资源所有者授予不当权限的情况。如果资源所有者错误地授予了高权限给不信任的用户或实体,可能会导致安全漏洞。

此外,由于每个资源的所有者可以独立决定访问权限,因此可能会导致系统中存在许多不一致的访问控制策略。这可能增加了管理和维护的复杂性,并且可能导致访问控制规则的碰撞或冲突。

2.4 基于角色的访问控制(Role-Based Access Control,RBAC)

按访问控制模型的出现时间看,ACL是一个60后,MAC是一个70后,DAC是一个80后。那90后的代表是哪个模型呢?没错,就是RBAC

RBAC是访问控制模型中的一种相对较新的模型,它基于角色和权限的概念来管理对资源的访问。在RBAC模型中,访问权限是根据用户的角色进行授权和控制的。

RBAC模型的核心概念包括:

  • 角色(Role)

角色代表一组具有相似职责或权限需求的用户,每个角色可以被分配不同的权限,或者说权限是以角色为最小单位分配的。

  • 权限(Permission)

权限代表对资源执行特定操作的授权。权限定义了以特定角色进入系统的用户在系统中可以对某些类资源执行的操作,例如读取、写入、删除等。

  • 用户(User)

用户是系统中的实体,通过分配角色来获得相应的权限。

下图是一个RBAC模型中用户、角色、权限与资源之间的直观的关系示意图(使用mermaid绘制):

这个图比较好理解!首先看权限,权限是一个规则,即允许哪个/哪些角色操作哪个/那些资源。以权限P1为例,它允许角色X操作资源R1和资源R2;权限P2则是允许角色Y和角色Z操作资源R2;权限P3则是允许角色Z操作资源R3。用户则会被赋予角色,并继承角色具有的所有权限。

通过上面图示和说明,我们看到:RBAC模型通过将权限分配给角色,而不是直接分配给用户,简化了权限管理,因为只需管理角色的权限,而无需单独管理每个用户的权限。

同时,这种方法也保持了一定的灵活性:通过分配和撤销角色,可以轻松地管理用户的访问权限。当用户的职责或权限需求发生变化时,只需调整其角色分配即可。

在安全性方面,RBAC模型可以减少人为错误和误操作的风险。通过严格控制角色的权限,可以确保用户只能执行他们所需的操作,从而减少潜在的安全漏洞。

基于上述特点,RBAC模型被广泛应用于企业环境中,并满足企业或组织内部的权限管理需求,是当今企业级Web应用的主流访问控制模型

此外,像Github的Personal Access Token(PAT)以及其他互联网Web应用的类似PAT的权限配置也是基于RBAC模型的。使用PAT时,用户可以创建令牌并为其分配特定的范围和权限,这时令牌既是user,也充当了角色(Role)。这些权限可以控制PAT可以访问和执行的操作,例如读取仓库、创建存储库、管理问题等。用户可以根据自己的需求创建多个PAT(Role),并根据需要撤销或更新它们。下面是github PAT创建和配置的示意图:

不过,RBAC模型虽然是主流模型,但也存在一些问题,比如:

  • 静态角色分配

RBAC模型中,角色和权限的分配是静态的,需要预先定义和分配角色。这种固定的角色分配方式难以适应动态变化的访问控制需求。例如,当用户的职责发生变化或需要临时获得额外权限时,RBAC模型需要进行角色重新分配或角色继承的操作,导致管理复杂性增加。

  • 角色爆炸问题

在大型组织或系统中,RBAC模型可能涉及大量的角色,以覆盖各种职责和权限。这可能导致角色爆炸问题,即角色数量过多,不易管理和维护。角色之间的关系和权限的粒度也可能变得复杂,增加了配置和管理的复杂性。

  • 缺乏细粒度访问控制

RBAC模型的主要限制之一是对访问控制的粒度较粗。RBAC模型通常基于角色来控制访问权限,而忽略了更细粒度的访问控制需求,如基于资源属性、环境上下文等进行访问控制。

  • 缺乏动态性和灵活性

RBAC模型的角色和权限分配是静态的,难以适应动态变化的访问控制需求。RBAC模型无法根据实时上下文信息或动态的用户属性来进行访问控制决策,导致难以满足复杂的访问控制策略。

这些问题也促成了00后的新模型ABAC的出现,下面我们就来看看ABAC模型。

2.5 基于属性的访问控制(Attribute-Based Access Control,ABAC)

ABAC,有时也被称为policy-based access control (PBAC)或claims-based access control (CBAC),是一种基于属性(Attribute)来决定对资源的访问权限的访问控制模型。与“90后”的RBAC模型相比,ABAC模型提供了更细粒度、动态和灵活的访问控制能力。

ABAC模型的核心概念包括如下几个:

  • 属性(Attribute)

属性是关于用户、资源、环境或其他上下文信息的特征。属性可以是任意对象,一般有这么几类。访问主体(用户)属性,可以是访问者自带的属性,比如年龄,性别,部门,角色等;动作类属性:比如读取,删除,查看等;被访问对象的属性,比如一条记录的修改时间,创建者等;环境类属性:比如时间信息,地理位置信息,访问平台信息等。属性还可以根据需要进行自定义和扩展。

  • 策略(Policy)

策略定义了访问控制规则和条件,用于评估访问请求的属性和上下文信息,并决定是否允许或拒绝访问。策略可以包括属性匹配、逻辑操作、时间条件等。

  • 属性策略引擎(Policy Decision Point, PDP)

属性策略引擎是ABAC模型的核心组件,负责评估访问请求的属性和条件,并根据属性和预定义的策略进行逻辑计算,以做出是否允许访问的控制决策。

下面是一个使用ABAC模型在组织内控制对某个文件资源的访问的例子的示意图:

在这个示例中,用户属性包括用户角色(Role)、用户部门(Department)、用户年龄(Age);资源属性有文件类型(FileType)、文件所属部门(FileDepartment)。

属性策略引擎(PDP)通过PIP(策略信息点)获取相关属性,并基于策略做出决策。下面是一些策略示例:

策略1:仅允许具有"管理员"角色的用户访问任意类型的文件。
策略2:仅允许具有"员工"角色的用户访问属于自己部门的任意类型的文件。
策略3:允许具有"访客"角色的用户访问公共类型的文件。
策略4:允许60岁以上用户访问特定类型的文件。
策略5:不允许访问属于其他部门的文件。

图中的PEP(策略执行点)负责接收用户发起的访问请求,并将请求传递给PDP进行决策,确保访问控制策略得到严格执行,以保护资源的安全性和完整性。用户可以是人员、应用程序或其他实体。之后,PEP负责根据访问控制策略的决策结果来执行实际的访问控制。当PDP(Policy Decision Point,属性策略引擎)确定用户是否被授权访问资源后,PEP将根据决策结果来允许或拒绝对资源的访问。PEP还可以记录和监控访问请求和决策结果,用于后续的审计和安全分析。通过记录访问活动,PEP可以提供有关谁、何时以及如何访问资源的详细信息。

ABAC是较新的访问控制模型,相较于它的前辈RBAC来说,它的能力更强大,控制粒度更精细,授权决策动态且灵活,但也更加复杂,需要定义和管理大量的属性和策略。这可能增加了实施和维护的困难。另外,ABAC模型的属性策略引擎需要对访问请求进行属性匹配和逻辑计算,这可能对系统性能产生一定的影响,在引入ABAC模型时,这也是一个需要考虑的因素。

尽管ABAC模型存在一些挑战和复杂性,但它提供了更高级、动态和灵活的访问控制能力让它可以更好地满足复杂的访问控制需求和安全策略,这使得ABAC模型在许多组织和行业中得到广泛应用,包括企业、政府、云计算、物联网等。同时,有许多标准化组织和机构致力于制定ABAC的标准和规范,例如NIST(美国国家标准与技术研究院)的NGACOASIS的XACML(eXtensible Access Control Markup Language),这些标准化努力有助于推动ABAC的统一实施和互操作性。

随着技术的不断进步,ABAC模型也在不断演进和改进。例如,引入了机器学习和人工智能技术来提高决策过程的自动化和智能化。

到这里,我们已经学习了从ACL到ABAC的5种主要访问控制模型,包括它们的发展历史、应用场景、优缺点等,这给我们提供了对不同访问控制模型的全面了解和比较。如今RBAC和ABAC是大家广泛应用的主流模型,接下来,我们就以一个示例来进一步加深这两个模型的理解。我将构建一个简单的公司员工信息管理系统,并在此系统中分别实现基于RBAC和ABAC的访问控制机制,以便通过对比不同实现来直观感受两种模型的区别。

3. 一个Web应用的授权实例

下面我们用一个Web应用的授权实例来进一步理解RBAC和ABAC两个广泛使用的访问控制模型。这是一个公司员工信息管理系统授权访问控制的示例,我们先用casbin以RBAC模型实现该示例,之后使用Open Policy Agent以ABAC模型再实现一遍该示例。

3.1 示例简介

好的,现在给你描述一下这个示例对授权的具体要求。

这是一个公司的员工信息管理系统,系统中定义了几种角色(role):经理(manager)、员工(employee)、HR和财务(finance)。这些角色可以直接用于RBAC模型中的角色,在ABAC中,它也可以作为主体(subject)的角色属性使用。系统要保护的资源有两个表:员工信息表(employee_info)和员工工资表(employee_salary),并定义了如下访问控制要求:

  • 经理:可以查看和修改所有员工的信息
  • 员工:可以查看和修改自己的信息
  • HR:可以查看和修改所有员工的信息,可以查看和修改所有员工的工资信息
  • 财务:可以查看所有员工的工资信息

这个公司有如下几位不同角色的员工:

  • 经理:alice
  • 员工:bob
  • HR:cathy
  • 财务:dan

接下来我们就先来基于RBAC实现该系统的访问控制。

3.2 基于RBAC模型的访问控制

根据前面的介绍,RBAC模型是基于角色的访问控制,因此针对上面示例描述,我们需要先定义角色以及为角色分配权限。

casbin使用policy.csv定义角色的权限:

// authz-examples/rbac/casbin/policy.csv

p, manager, employee_info, read
p, manager, employee_info, write
p, employee, employee_info, write
p, employee, employee_info, read
p, hr, employee_info, read
p, hr, employee_info, write
p, hr, employee_salary, write
p, hr, employee_salary, read
p, finance, employee_salary, read

初看这个文件中的配置数据,很多人不知道是什么意思,这个csv文件中每行的字段含义都要与model.conf对照着看:

// authz-examples/rbac/casbin/model.conf

[request_definition]
r = role, obj, act

[policy_definition]
p = role, obj, act

[role_definition]
g = _, _

[policy_effect]
e = some(where (p.eft == allow)) 

[matchers]
m = g(r.role, p.role) && r.obj == p.obj && r.act == p.act

我们看下这个配置文件中的section: policy_definition,我们看到其定义为p = role, obj, act,这里的p就是规则定义,根据这一规则定义,我们可以确定csv中p开头的行中的各段数据的含义,比如:根据“p, manager, employee_info, read”,我们可以得到role=manager,obj=employee_info,act=read,我们用下图再直观总结一下这种对应关系:

request_definition这个section中定义了请求传入时参数的次序(“r = role, obj, act”),其要求Go代码中调用casbin.Enforcer.Enforce方法时各个参数的传入次序与之相同(比如: Enforce(“manager”, “employee_info”, “read”)),并指示了传入的参数对应的含义。

matchers这个section中定义了匹配规则,先不看g(r.role, p.role),“r.obj == p.obj && r.act == p.act”这个很好理解,即当请求(request)中的obj与策略规则(policy)中的obj匹配,且请求中的act与策略规则中的act(动作)匹配时,才认为通过访问控制的校验。

我们结合Go代码来看一下casbin对RABC的实现和使用方法:

// authz-examples/rbac/casbin/main.go

package main

import (
    "fmt"

    "github.com/casbin/casbin/v2"
)

func main() {
    users := map[string]string{
        "alice": "manager",
        "bob":   "employee",
        "cathy": "hr",
        "dan":   "finance",
    }

    e, err := casbin.NewEnforcer("model.conf", "policy.csv")
    if err != nil {
        panic(err)
    }

    // 经理alice访问员工信息
    ok, err := e.Enforce(users["alice"], "employee_info", "read") // role, obj, act
    if err != nil {
        panic(err)
    }
    fmt.Println("manager alice can read employee_info:", ok)

    ok, err = e.Enforce(users["alice"], "employee_info", "write")
    if err != nil {
        panic(err)
    }
    fmt.Println("manager alice can write employee_info:", ok)

    // 员工bob访问自己信息
    ok, err = e.Enforce(users["bob"], "employee_info", "write")
    fmt.Println("employee bob can write employee_info:", ok)

    // HR cathy 访问员工信息
    ok, err = e.Enforce(users["cathy"], "employee_info", "write")
    fmt.Println("hr cathy can write employee_info:", ok)
    ok, err = e.Enforce(users["cathy"], "employee_salary", "write")
    fmt.Println("hr cathy can write employee_salary:", ok)

    // 财务dan访问工资信息
    ok, err = e.Enforce(users["dan"], "employee_salary", "read")
    fmt.Println("finance dan can read employee_salary:", ok)

    // 员工bob串改薪水信息
    ok, err = e.Enforce(users["bob"], "employee_salary", "write")
    fmt.Println("employee bob can write employee_salary:", ok)
}

这里只是企业内部信息系统的简化实现,正常情况下,员工使用自己的账号登录到系统后,系统就会获知该用户的角色(role),这里我们用了一个map来存储用户名与角色的映射关系。

我们基于model.conf和policy.csv创建新的Enforcer,然后调用其Enforce方法并按“role, obj, act”次序传入我们要测试的信息。Enforce返回true表示通过了访问控制规则的验证,否则就是没有通过授权验证。

上述代码的输出结果如下:

$go run main.go
manager alice can read employee_info: true
manager alice can write employee_info: true
employee bob can write employee_info: true
hr cathy can write employee_info: true
hr cathy can write employee_salary: true
finance dan can read employee_salary: true
employee bob can write employee_salary: false

到这里,我们还有一个问题没有解决,那就是casbin的model.conf中role_definition的配置含义以及matchers中g(r.role, p.role)含义。

casbin关于RBAC的文档中明确提到了,如果不使用RBAC模型,那么role_definition就是一个可选的配置;如果要使用RBAC模型,那么role_definition下的每一行都是一个独立的RBAC系统,下面的配置拥有两个独立的RBAC系统:g和g2:

[role_definition]
g = _, _
g2 = _, _

“_, _”表示映射关系中有两方。通常我们只会使用到user和role的映射,因此只用一个RBAC系统即可,即只配置和使用g即可。下面是应用g这个RBAC系统的例子:

// policy.csv
p, manager, employee_info, write
g, alice, manager

这里的“g, alice, manager”的含义是alice是角色manager中的一员,或alice这个user的角色是manager。当然alice这个位置上不仅可以使用user,也可以使用resource,甚至是role,casbin只是将其看成一个字符串而已。

而matchers中的“g(r.role, p.role)”的含义就是请求(r)中的role在policy文件中能找到对应的role。如果Enforce函数传入的是”manager”,那么只有policy.csv中定义了”manager”这个角色,g(r.role, p.role)的结果才是true。

上述示例并未在policy.csv中使用到这种user到role的映射(基于g这个RBAC系统),下面我们改造一下示例,我们在policy.csv中保存这种user到role的映射,而不是在go代码中保存,新版policy.csv如下:

// authz-examples/rbac/casbin_with_user_in_policy/policy.csv 

p, manager, employee_info, read
p, manager, employee_info, write
p, employee, employee_info, write
p, employee, employee_info, read
p, hr, employee_info, read
p, hr, employee_info, write
p, hr, employee_salary, write
p, hr, employee_salary, read
p, finance, employee_salary, read
g, alice, manager
g, bob, employee
g, cathy, hr
g, dan, finance

对应的Go代码改造如下:

// authz-examples/rbac/casbin_with_user_in_policy/main.go

func main() {
    e, err := casbin.NewEnforcer("model.conf", "policy.csv")
    if err != nil {
        panic(err)
    }

    // 经理alice访问员工信息
    ok, err := e.Enforce("alice", "employee_info", "read") // role, obj, act
    if err != nil {
        panic(err)
    }
    fmt.Println("manager alice can read employee_info:", ok)

    ok, err = e.Enforce("alice", "employee_info", "write")
    if err != nil {
        panic(err)
    }
    fmt.Println("manager alice can write employee_info:", ok)

    // 员工bob访问自己信息
    ok, err = e.Enforce("bob", "employee_info", "write")
    fmt.Println("employee bob can write employee_info:", ok)

    // HR cathy 访问员工信息
    ok, err = e.Enforce("cathy", "employee_info", "write")
    fmt.Println("hr cathy can write employee_info:", ok)
    ok, err = e.Enforce("cathy", "employee_salary", "write")
    fmt.Println("hr cathy can write employee_salary:", ok)

    // 财务dan访问工资信息
    ok, err = e.Enforce("dan", "employee_salary", "read")
    fmt.Println("finance dan can read employee_salary:", ok)

    // 员工bob串改薪水信息
    ok, err = e.Enforce("bob", "employee_salary", "write")
    fmt.Println("employee bob can write employee_salary:", ok)
}

大家看到我们在调用Enforce时,第一个参数传入的不再是role,而是user名字,由于policy.csv中使用g保存了user到role的映射,因此Enforce会在内部将user先替换为映射的role,然后再在policy.csv中找到对应的p定义的role,查看是否满足matchers中“g(r.role, p.role)”规则。

运行上面新示例的结果将于第一个示例一样,这里就不赘述了。

接下来,我们再来看看如何基于ABAC模型实现该公司的员工信息系统的授权。

注:casbin号称也支持ABAC模型,有兴趣的童鞋可以自行基于casbin实现基于ABAC模型的员工信息系统的授权示例。

3.3 基于ABAC模型的访问控制

前面介绍ABAC模型时已经提到过,ABAC是基于属性的访问控制,由于我们这个示例比较简单,能用到的user主体属性只有user的角色(role),这里就基于user的角色来实现访问控制,而作为客体的那两张表,考虑简单起见,这里并未为之定义什么属性。

OPA(Open Policy Agent)是CNCF基金会下面的一个开源的通用策略引擎,它目前已经从CNCF毕业,也是CNCF目前毕业项目中唯一一个策略引擎。OPA可以用于实现统一的访问控制和策略管理。它提供了一个通用的框架,可用于编写和执行策略,以决定对资源的访问是否被允许。OPA使用一种名为Rego的声明性语言来定义策略。Rego语言简洁而强大,可以表达复杂的访问控制逻辑。它允许开发人员定义规则、条件和约束,以描述访问策略和决策过程。受益于CNCF的支持和资源,OPA获得了更广泛的知名度和认可度。它成为了云原生生态系统中重要的一部分,并与其他CNCF项目和工具进行紧密的集成,如Kubernetes、Envoy、Prometheus等。这种集成加强了整个生态系统的互操作性和一致性,为用户提供了更强大的功能和灵活性。

使用opa实现员工信息系统的ABAC授权,我们需要先使用Rego语言定义出访问控制策略,下面是用Rego定义的员工信息系统的访问控制策略:

// authz-examples/abac/opa/policy.rego

package opa.examples

import input as i

# 定义策略
allow {
  i.subject.role == "manager"
  i.object == "employee_info"
  i.action == "read"
}

allow {
  i.subject.role == "manager"
  i.object == "employee_info"
  i.action == "write"
}

allow {
  i.subject.role == "employee"
  i.object == "employee_info"
  i.action == "read"
}

allow {
  i.subject.role == "employee"
  i.object == "employee_info"
  i.action == "write"
}

allow {
  i.subject.role == "hr"
  i.object == "employee_info"
  i.action == "read"
}

allow {
  i.subject.role == "hr"
  i.object == "employee_info"
  i.action == "write"
}

allow {
  i.subject.role == "finance"
  i.object == "employee_salary"
  i.action == "read"
}

这个策略配置文件使用的语法借鉴了Go,不过即便你不了解Go语法,你很大概率也能读懂其逻辑,是不是感觉比前面的casbin的model.conf和policy.csv的组合配置更易理解一些呢!我们以一个allow代码块为例:

allow {
  i.subject.role == "finance"
  i.object == "employee_salary"
  i.action == "read"
}

这个配置块儿的含义就是当输出的请求中的主体的role为”finance”且客体(resouce)为”employee_salary”并且action为”read”时,允许请求访问。其他的section依此理解即可。

下面我们再来看看基于opa实现上述ABAC模型的Go代码:

// authz-examples/abac/opa/main.go

package main

import (
    "context"
    "fmt"
    "log"

    "github.com/open-policy-agent/opa/rego"
)

func main() {
    // Construct a Rego object that can be prepared or evaluated.
    r := rego.New(
        rego.Query("data.opa.examples.allow"),
        rego.Load([]string{"./policy.rego"}, nil),
    )

    // Create a prepared query that can be evaluated.
    query, err := r.PrepareForEval(context.Background())
    if err != nil {
        log.Fatal(err)
    }

    inputs := []map[string]interface{}{
        {
            "name": "alice",
            "subject": map[string]string{
                "role": "manager",
            },
            "object": "employee_info",
            "action": "read",
        },
        {
            "name": "alice",
            "subject": map[string]string{
                "role": "manager",
            },
            "object": "employee_info",
            "action": "write",
        },
        {
            "name": "bob",
            "subject": map[string]string{
                "role": "employee",
            },
            "object": "employee_info",
            "action": "write",
        },
        {
            "name": "cathy",
            "subject": map[string]string{
                "role": "hr",
            },
            "object": "employee_info",
            "action": "read",
        },
        {
            "name": "cathy",
            "subject": map[string]string{
                "role": "hr",
            },
            "object": "employee_info",
            "action": "write",
        },
        {
            "name": "dan",
            "subject": map[string]string{
                "role": "finance",
            },
            "object": "employee_salary",
            "action": "read",
        },
        {
            "name": "bob",
            "subject": map[string]string{
                "role": "employee",
            },
            "object": "employee_salary",
            "action": "write",
        },
    }

    for _, v := range inputs {
        // Execute the prepared query.
        rs, err := query.Eval(context.Background(), rego.EvalInput(v))
        if err != nil {
            log.Fatal(err)
        }

        if len(rs) > 0 {
            fmt.Printf("%s %s can %s %s: %v\n", (v["subject"].(map[string]string))["role"], v["name"],
                v["action"], v["object"], rs[0].Expressions[0].Value)
        } else {
            fmt.Printf("%s %s can %s %s: %v\n", (v["subject"].(map[string]string))["role"], v["name"],
                v["action"], v["object"], false)
        }

    }
}

这个例子参考了opa官方的示例,我们先基于policy.rego构建一个rego策略引擎,然后按我们的测试逻辑构建一组input,我将input放入了一个map切片中,然后遍历该切片,对每个input执行Eval,通过Eval返回的结果判断input是否通过了引擎的校验。执行上述示例代码,我们将得到:

$go run main.go
manager alice can read employee_info: true
manager alice can write employee_info: true
employee bob can write employee_info: true
hr cathy can read employee_info: true
hr cathy can write employee_info: true
finance dan can read employee_salary: true
employee bob can write employee_salary: false

这个和casbin实现的结果是一致的。

通过上面两种模型的实现,我们能达到相同的效果。不过,opa的rego语言的简洁清晰且不乏强大的表达能力还是让人印象深刻的,casbin的配置在理解上要下一番功夫,并且要用好casbin,还必须要深入理解其配置方法和配置项的含义。这两个工具大家可以根据自己的喜好选择最适合你自己的。

以上无论是RBAC,还是ABAC,都是仅由本地单系统参与的授权模型。随着系统规模的扩大,我们可能需要考虑引入第三方授权系统。第三方授权具有方便实现单点登录、用户友好的授权流程、减少密码传播风险、细粒度的授权管理以及第三方应用程序集成等好处。这些好处可以提供更方便、安全和灵活的用户体验,并促进了应用程序之间的互操作性和集成性。

接下来我们就来说说基于OAuth2的第三方授权。

4. OAuth2授权框架

4.1 什么是第三方授权

在开始理解OAuth2授权框架之前,我们先来简单说说什么是第三方授权。为了更好的说明,我先画了一张示意图:

结合这张图,我们理解以下第三方授权。第三方授权是指一个实体(第三方,比如图中的C应用),通过获得用户的授权,可以访问另一个实体(服务提供者,比如图中的S应用)的资源(比如用户A的一些个人信息)或执行特定操作。在这种授权模式下,用户授予第三方应用程序(C应用)或服务访问其受保护资源(位于S应用中的用户A的一些个人信息)的权限,而无需直接向第三方实体(比如C应用)共享其凭据(如用户名和密码)。

第三方授权的典型示例是用户使用自己的社交媒体账号(如微信、Facebook、Google、Twitter等)登录第三方应用程序或网站:

在这种情况下,用户不需要创建新的账号和密码,而是选择使用其社交媒体账号进行登录。当用户同意授权该应用程序访问其社交媒体账号时,第三方应用程序可以获取用户的基本信息(如姓名、电子邮件地址、头像等)或者在用户的名义下执行某些操作(如发布推文、分享内容等)。下面是使用github和微信对第三方应用进行授权的页面截图:

第三方授权的优势在于用户可以方便地使用现有的身份验证凭据,而无需为每个应用程序创建和记住不同的账号和密码。同时,用户还可以更好地控制其数据的访问权限,选择性地授权应用程序可以访问的资源和操作。需要注意的是,第三方授权的安全性和隐私保护至关重要。用户应该仔细审查并理解第三方应用程序请求的权限范围,并只授权其信任的应用程序访问其敏感信息或执行敏感操作。服务提供者也应该采取适当的安全措施,确保用户的数据得到妥善保护。

这样的第三方授权在移动互联网应用领域十分常见,如果没有一套标准的授权框架,这种授权方式将很难实现。OAuth正是为了解决这个问题而诞生的一个标准的授权框架。接下来,我们就进入OAuth协议框架。

4.2 OAuth协议框架

OAuth协议(全称Open Authorization)的产生是为了解决无须共享密码的情况下,从第三方应用程序(比如前面图中的S应用)安全地访问受保护数据、资源的问题。OAuth是一种行业标准的授权框架,它在第三方应用授权中发挥重要作用。OAuth协议的最新版本为OAuth2.0,并已经被广泛用于各厂家的互联网应用中。在原理上,OAuth2允许用户授权第三方应用,访问该用户在某服务平台存储的资源,而无需共享用户名和密码。它通过“访问令牌(access token)”实现授权。

注:从上述描述我们也能看出:所谓第三方授权其实是将身份认证与授权合为一体的一种机制,以授权为主要目的。因此OAuth被称为授权协议,而不是身份认证协议。

在OAuth协议的核心规范中,对于OAuth的授权流程定义了不同的角色,通过不同角色之间不同概念的信息传递对象的交互,完成整个授权流程。这些角色包括:

  • 资源所有者(Resource Owner)

资源所有者是指受保护资源的所有者,当受保护资源被访问时,需要此所有者授予访问者访问权限。如果资源所有者是一个自然人时,即表示为最终用户(比如前面图中的用户A)。

  • 资源服务器(Resource Server)

资源服务器是指托管接受保护资源的服务器(比如前面图中的S应用),接收访问请求并使用访问令牌保护受保护的资源。

  • 客户端(Client)

这里客户端通常是指代理用户发起受保护资源请求的客户端应用程序,比如前面图中的C应用。

  • 授权服务器(Authorization Server)

客户端通过认证后,授权服务器(比如前面图中的S应用)会向客户端发布访问令牌并获得授权。

访问令牌是客户端应用程序访问受保护资源的凭据,没有访问令牌则无法访问受保护的资源。此令牌通常是授权服务器颁发的具有一定含义的字符串,包含此次授权的基本信息、授权范围、授权有效时间等信息。

授权过程与我们前面的示意图十分相似,结合OAuth协议定义的不同角色,我们借鉴下面示意图再来描述一下基于OAuth2的整个授权流程:


图来自《API安全技术与实战》一书

  • 步骤1:客户端应用程序向资源所有者发送授权请求,这里的客户端是指普通的WebAPI、原生移动App、基于浏览器的Web应用以及无浏览器的嵌入式后端应用,在流程中充当用户行为代理(比如前图中的C应用)。
  • 步骤2:资源所有者(比如前图中的用户A)同意授权客户端访问资源,即获得资源所有者的授权凭据,包含授权范围和授权类型。
  • 步骤3:客户端使用上一步获得的授权凭据,向授权服务器进行身份认证并申请访问令牌Access Token。
  • 步骤4:授权服务器对客户端进行身份认证,确认身份无误后,下发访问令牌AccessToken。
  • 步骤5:客户端使用上一步获得的访问令牌Access Token,向资源服务器申请获取受保护的资源。
  • 步骤6:资源服务器确认访问令牌Access Token正确无误后,向客户端开放所访问的资源。

OAuth协议核心文档定义了资源所有者给予客户端授权的4种方式:

  • 授权码(authorization code)

这种方式下,第三方应用先申请一个授权码,然后再用该码获取令牌。

  • 隐藏式(implicit)

适用于没有后端的纯前端应用,客户端直接获得访问令牌Access Token,而无须客户端授权码这个中间步骤。

  • 密码式(password)

资源所有者的认证凭据(即用户名和密码)直接告诉第三方应用,该应用随即使用密码申请令牌。

  • 凭证式(client credentials)

适用于没有前端的命令行应用,即在命令行下请求令牌。采用客户端自己的凭据,而不是用户的凭据来作为授权依据,获取资源的访问权限。

在这四种授权方式中,授权码是OAuth协议中主要的授权流程,相比其他的授权模式,其流程最为完备,适用于互联网应用的第三方授权场景。

由于OAuth授权相对较为复杂,涉及角色和环节很多,很难用一个例子将其全貌展现出来,这里就不举代码示例了。如果你的系统并不涉及到第三方,既不为第三方提供服务,也不使用第三方的服务,那引入OAuth 2.0其实就没必要。

5. 小结

本文首先介绍了授权的相关概念,着重说明了授权与访问控制的紧密联系和些许差别。之后,我们对5种常见的访问控制模型逐一做了说明,包括它们的使用场景与优缺点。为了帮助大家更好地理解当今主流使用的RBAC和ABAC模型,我还将一个示例分别用casbin和opa作了实现。

在文章的最后,我们简单介绍了用于第三方授权的OAuth授权框架,包括它的协议中涉及的主要角色以及资源所有者给予客户端授权的4种方式,大家可以根据自己的理解,自行基于像微信或github这样的支持三方授权的应用编写一些简单示例。

本文示例所涉及的Go源码可以在这里下载。

6. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Service Weaver:以单体形式编码,以微服务形式部署

本文永久链接 – https://tonybai.com/2023/10/09/service-weaver-coding-in-monolithic-deploy-in-microservices

分布式应用的主流架构模式演化为微服务架构已经有些年头了。微服务、DevOps、持续交付和容器技术(k8s)是构成最初云原生概念的核心要素。它们相生相拌,共同演进,并推动了云计算全面进入云原生时代

云原生应用普遍采用微服务架构,遗留的单体应用程序会逐步演进并拆分为多个微服务,新应用则会直接采用微服务架构进行设计与实现。微服务的好处是显而易见的:

  • 每个微服务都编译为一个二进制文件并独立部署和扩展,可以提高资源利用率;
  • 一个微服务的崩溃不会影响到其他微服务,限制了错误的传播半径,从而提高了容错能力;
  • 改善了抽象的边界。微服务需要清晰明确的API,降低了代码纠缠不清的可能性;
  • 灵活部署,不同微服务的二进制文件可以以不同频率发布,从而实现更敏捷的代码升级。
  • … …

不过做过微服务的朋友都知道,微服务架构带来的不仅仅是好处,还有很多挑战:

  • 单体应用内的模块间可通过内存直接交互,而在微服务架构的应用中,多个微服务需要进行跨进程跨机器的通信,对数据的序列化和反序列化操作必不可少,其开销很难避免,对应用性能是有较大损耗的;
  • 研究表明,三分之二的故障是由于不同版本的微服务之间的交互引发的,这会损害应用的正确性;
  • 每个微服务开发人员都有自己的发布和管理计划,而无法像单体应用那样使用单个二进制文件来统一构建、测试和部署,这给微服务开发管理带来了很高的复杂性;
  • API管理变得复杂。一旦某个微服务发布了,它的API很难在不影响其他使用该API的服务的情况下进行变更,新老API同时存在是常态;
  • 减慢了应用程序开发的速度。在进行会影响多个微服务的更改时,开发人员无法原子地实现和部署这些更改。他们必须仔细计划如何根据自己的发布时间表在n个微服务中引入变更;
    … …

由此可见,微服务并非“银弹”,人们在消除微服务的缺点方面做了很多工作,不可谓不努力,但收效甚微,甚至出现了回归monolith(大单体)的现象

今年年初Google发布了一个在这方面的探索成果:Service Weaver。Service Weaver不仅仅是一个分布式应用的开发框架,更是一个旨在减少或消除微服务弊端的探索实验的结论。

Service Weaver到底有何与众不同?它的核心抽象是什么?它的最大优点又是什么呢?在这一篇文章中,我就和大家一起来学习和了解一下Service Weaver这个开发框架。

1. Service Weaver简介

Service Weaver是Google开源的一个编程框架(programming framework) ,用于编写、部署和管理用Go开发的分布式应用程序。

注:随着Service Weaver的演进,后续可能会有其他语言的版本。

使用Service Weaver,你可以像编写在本地机器上运行的传统单进程Go可执行文件一样编写应用程序。然后,将其部署到云中,该框架会将其分解为一组微服务,并将其与云提供商(主要是k8s)集成(如监控、跟踪、日志等)。简单来说,就是“以单体形式编码,以微服务形式部署”

开篇提过,Google开源的Service Weaver本就是为解决微服务架构在实践中出现的诸多问题而提出的创新思路与实验,为此它提出并实现了三个核心原则

  • 在构建阶段,开发人员只需编写模块化的单体程序;
  • 在首次部署和运行阶段,Service Weaver会将逻辑组件分配给物理进程,可以是本地的一个进程,也可以是多个进程,当然最主流的还是分配给运行在公有云提供商k8s的不同pod;
  • 以原子方式升级变更应用,彻底杜绝应用的不同版本间的交互。

这么说依然很抽象,闻名不如见面,接下来我们就用一些例子来看一下Service Weaver是如何践行这三个原则的。

我们先来看看用Service Weaver开发的“Hello, World”程序长什么样子。

2. Hello, World

安装Service Weaver很简单,只需执行下面命令:

$go install github.com/ServiceWeaver/weaver/cmd/weaver@latest

$weaver
USAGE

  weaver generate                 // weaver code generator
  weaver version                  // show weaver version
  weaver single    <command> ...  // for single process deployments
  weaver multi     <command> ...  // for multiprocess deployments
  weaver ssh       <command> ...  // for multimachine deployments
  weaver gke       <command> ...  // for GKE deployments
  weaver gke-local <command> ...  // for simulated GKE deployments
  weaver kube      <command> ...  // for vanilla Kubernetes deployments

DESCRIPTION

  Use the "weaver" command to deploy and manage Weaver applications.

  The "weaver generate", "weaver version", "weaver single", "weaver multi", and
  "weaver ssh" subcommands are baked in, but all other subcommands of the form
  "weaver <deployer>" dispatch to a binary called "weaver-<deployer>".
  "weaver gke status", for example, dispatches to "weaver-gke status".

注:Weaver要求Go版本高于1.21。另外在MacOS上安装使用时,官方文档提到要开启export CGO_ENABLED=1; export CC=gcc; 不过CGO_ENABLED=1通常是默认的。另外我使用CC=clang也可以正常安装和使用weaver。

安装完Weaver后,我们就来看一个基于Weaver的Hello, World示例,了解一下基于Weaver框架开发的应用的基本结构。

我们创建一个hello目录,然后在hello下面使用go mod init hello来初始化一个go module。这个例子非常简单,hello目录下只有一个main.go:

// serviceweaver-examples/hello/main.go

package main

import (
    "context"
    "fmt"
    "log"

    "github.com/ServiceWeaver/weaver"
)

func main() {
    if err := weaver.Run(context.Background(), serve); err != nil {
        log.Fatal(err)
    }
}

// app is the main component of the application. weaver.Run creates
// it and passes it to serve.
type app struct {
    weaver.Implements[weaver.Main]
}

// serve is called by weaver.Run and contains the body of the application.
func serve(context.Context, *app) error {
    fmt.Println("Hello, World")
    return nil
}

我们看到:示例导入了weaver包,然后在main函数中调用weaver.Run函数。Run函数的原型如下:

// github.com/ServiceWeaver/weaver/weaver.go
func Run[T any, P PointerToMain[T]](ctx context.Context, app func(context.Context, *T) error) error

weaver充分利用了Go 1.18引入的泛型,Run就是一个泛型函数,它的第二个参数为app,这是一个函数类型的参数。顾名思义,app这个函数封装了整个应用的主运行逻辑。在hello这个示例中,我们为Run的第二个参数传入的是serve。而serve的逻辑非常简单,就是输出“Hello, World”,然后就返回nil了,返回nil表示正常退出。weaver.Run会处理应用的生命周期,比如优雅关闭等,serve函数就只需要关心业务逻辑即可,通过这种方式,通用的服务框架代码和业务代码便分离开来,降低了耦合,提高可维护性。

到这里,很多读者可能注意到了:由于示例过于简单,serve函数并没有使用传入的第二个参数(类型为*app),但在用Weaver开发的实用程序中,Run的第二个参数是整个应用的核心,并且app这个类型恰好就是weaver.Run泛型函数中T的类型实参(type argument)。

Run函数的注释中明确说明:T类型(app)必须是一个struct类型且包含一个weaver.Implements[weaver.Main]的嵌入字段,在该示例中app类型的定义恰是如此:

// serviceweaver-examples/hello/main.go
type app struct {
    weaver.Implements[weaver.Main]
}

说到这里,就不得不提到Service Weaver的核心抽象:组件(component)了!基于Service Weaver框架开发的应用是由一个组件的集合。实际上,Weaver中的组件就是一个普通Go接口的实现,编写代码时,组件间的交互也是通过接口的方法调用完成的。

那么,上面示例中的组件在哪里呢?上面的示例仅包含一个Weaver应用必须的组件:main组件。app类型就理解为一个main组件,它通过嵌入weaver.Implements[weaver.Main]这个类型实现了weaver.Main接口:

// Main is the interface implemented by an application's main component.
type Main interface{}

对于Weaver应用而言,main组件是不可获取的,如果注释掉app结构体类型中weaver.Implements[weaver.Main]这一行,那么无论执行weaver generate命令还是go run命令,你得到的都会是错误:

$weaver generate .
-: # hello
./main.go:12:22: *app does not satisfy "github.com/ServiceWeaver/weaver".PointerToMain[app] (missing method implements)
/Users/tonybai/Test/Go/service-weaver/hello/main.go:12:12: *app does not satisfy "github.com/ServiceWeaver/weaver".PointerToMain[app] (missing method implements)

$go run .
# hello
./weaver_gen.go:34:40: cannot use (*app)(nil) (value of type *app) as "github.com/ServiceWeaver/weaver".InstanceOf["github.com/ServiceWeaver/weaver".Main] value in variable declaration: *app does not implement "github.com/ServiceWeaver/weaver".InstanceOf["github.com/ServiceWeaver/weaver".Main] (missing method implements)
./weaver_gen.go:37:25: cannot use (*app)(nil) (value of type *app) as "github.com/ServiceWeaver/weaver".Unrouted value in variable declaration: *app does not implement "github.com/ServiceWeaver/weaver".Unrouted (missing method routedBy)
./main.go:12:22: *app does not satisfy "github.com/ServiceWeaver/weaver".PointerToMain[app] (missing method implements)

好了,大致了解Weaver应用的结构后,我们来运行一下这个示例:

$go mod tidy
go: finding module for package github.com/ServiceWeaver/weaver
go: found github.com/ServiceWeaver/weaver in github.com/ServiceWeaver/weaver v0.21.2
go: downloading modernc.org/ccgo/v3 v3.16.13
go: downloading modernc.org/cc/v3 v3.40.0
go: downloading lukechampine.com/uint128 v1.2.0
go: downloading modernc.org/token v1.0.1

$weaver generate .
$go run .
╭───────────────────────────────────────────────────╮
│ app        : hello                                │
│ deployment : ca0fcdf2-d9bc-456b-a668-159688e3cca5 │
╰───────────────────────────────────────────────────╯
Hello, World

我们看到,在go run执行之前,我们通过weaver generate命令生成一些代码,这些生成的代码放在了weaver_gen.go中,有100多行,是weaver应用运行所必须的stub代码。

hello, world虽然简单易懂,但对Weaver的核心抽象:逻辑组件(component)的体现并不明显,我们再来看一个复杂一些的例子。

3. 一个http服务器例子

我们来实现一个http服务器的例子,下面是这个例子的组件逻辑拓扑结构:

从图中可以看到,这个实例程序一共有三个weaver component:main组件(listener)、reverser组件(用于将输入的字符串反转)和converter组件(用于将输入的字符串变成大写字符串)。

reverser组件和converter组件都比较简单,每个组件对应的接口仅有一个方法,它们的代码如下:

// serviceweaver-examples/httpserver/reverser.go

package main

import (
    "context"

    "github.com/ServiceWeaver/weaver"
)

// Reverser component.
type Reverser interface {
    Reverse(context.Context, string) (string, error)
}

// Implementation of the Reverser component.
type reverser struct {
    weaver.Implements[Reverser]
}

func (r *reverser) Reverse(_ context.Context, s string) (string, error) {
    runes := []rune(s)
    n := len(runes)
    for i := 0; i < n/2; i++ {
        runes[i], runes[n-i-1] = runes[n-i-1], runes[i]
    }
    return string(runes), nil
}

// serviceweaver-examples/httpserver/converter.go

package main

import (
    "context"
    "strings"

    "github.com/ServiceWeaver/weaver"
)

// Converter component.
type Converter interface {
    ToUpper(context.Context, string) (string, error)
}

// Implementation of the Converter component.
type converter struct {
    weaver.Implements[Converter]
}

func (r *converter) ToUpper(_ context.Context, s string) (string, error) {
    return strings.ToUpper(s), nil
}

接下来,我们实现这个示例的实现weaver.Main接口的app类型:

// serviceweaver-examples/httpserver/main.go

type app struct {
    weaver.Implements[weaver.Main]
    reverser  weaver.Ref[Reverser]
    converter weaver.Ref[Converter]
    lis       weaver.Listener
}

这里app结构体类型通过weaver.Ref嵌入了实现了另外两个组件接口的组件实例,Ref函数的定义如下:

// Ref[T] is a field that can be placed inside a component implementation
// struct. T must be a component type. Service Weaver will automatically
// fill such a field with a handle to the corresponding component.
type Ref[T any] struct {
    value T
}

// Get returns a handle to the component of type T.
func (r Ref[T]) Get() T { return r.value }

此外,通过泛型类型Ref的Get方法,可以获得对相应组件的访问权。

app结构体类型中还包含了一个weaver.Listener类型的实例,Listener理论上并非组件,而是Weaver框架提供了网络服务端口监听的实现,可以放置在任何提供网络服务的组件实现内部,比如本示例的app这个main组件。app将reverser、converter和listener聚合在一起,为后续的serve函数实现提供支持。

接下来,我们看看serve函数的实现:

// serviceweaver-examples/httpserver/main.go

func serve(ctx context.Context, app *app) error {
    // The lis listener will listen on a random port chosen by the operating
    // system. This behavior can be changed in the config file.
    fmt.Printf("http listener available on %v\n", app.lis)

    // Serve the /reverse endpoint.
    http.HandleFunc("/reverse", func(w http.ResponseWriter, r *http.Request) {
        name := r.URL.Query().Get("name")
        if name == "" {
            name = "World"
        }
        reversed, err := app.reverser.Get().Reverse(ctx, name)
        if err != nil {
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }
        fmt.Fprintf(w, "after reversing, name is %s\n", reversed)
    })
    // Serve the /convert endpoint.
    http.HandleFunc("/convert", func(w http.ResponseWriter, r *http.Request) {
        name := r.URL.Query().Get("name")
        if name == "" {
            name = "World"
        }
        converted, err := app.converter.Get().ToUpper(ctx, name)
        if err != nil {
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }
        fmt.Fprintf(w, "after converting, name is %s\n", converted)
    })
    return http.Serve(app.lis, nil)
}

我们看到serve函数定义了两个端点/reverse和/convert的Handler函数,并通过http.Serve启动了一个http服务器,http服务器返回,应用退出,否则http服务将一直运行。

我们来运行一下这个程序:

$cd serviceweaver-examples/httpserver
$go mod tidy
$weaver generate .
$go run .
╭───────────────────────────────────────────────────╮
│ app        : httpserver                           │
│ deployment : 55827837-896f-4060-88c2-f1f1d953d142 │
╰───────────────────────────────────────────────────╯
http listener available on [::]:59493

我们看到,示例中的httpserver启动后在59493这个端口监听客户端的连接,我们用curl工具来测试一下:

$curl "http://localhost:59493/convert?name=abcdefg"
after converting, name is ABCDEFG
$curl  "http://localhost:59493/reverse?name=abcdefg"
after reversing, name is gfedcba

我们看到,无论是reverser组件还是converter组件工作都正常。

由于我们没有指定端口,59493是一个随机端口。如果要指定监听的地址和端口,我们可以借助weaver提供的toml格式的配置文件来实现:

// weaver.toml
[single]
listeners.lis = {address = "localhost:8080"}

基于weaver.toml配置文件启动httpserver的命令如下:

$SERVICEWEAVER_CONFIG=weaver.toml go run .
╭───────────────────────────────────────────────────╮
│ app        : httpserver                           │
│ deployment : ee49694c-4935-4f44-96f3-cc7d1d0167ae │
╰───────────────────────────────────────────────────╯
http listener available on 127.0.0.1:8080

在这种模式下启动的httpserver,所有组件都会在一个单一的进程中,组件间的通信通过方法调用进行。这种单体程序在单个进程中部署运行的方式称为single process部署模式,十分适合开发者对程序的开发与调试。weaver为这种方式提供了专门的子命令single,我们可以通过single命令在单进程启动httpserver,不过我们要修改一下weaver.toml:

// weaver.toml

[single]
listeners.lis = {address = "localhost:8080"}

[serviceweaver]
binary = "./httpserver"

无论是single子命令,还是后面即将讲到的multi,都是基于一个可执行文件进行的,因此我们要将httpserver这个示例编译为一个可执行文件”httpserver”,我已经将编译命令放入Makefile,大家输入make命令执行即可。

有了可执行的二进制文件httpserver后,我们就可以使用single子命令启动单进程版的httpserver了:

$weaver single deploy weaver.toml
╭───────────────────────────────────────────────────╮
│ app        : httpserver                           │
│ deployment : ad7c0341-d5d2-4182-8944-306d7682e708 │
╰───────────────────────────────────────────────────╯
http listener available on 127.0.0.1:8080

在开篇讲Service Weaver的三个核心原则时提到,基于Weaver的应用既可以跑在一个进程中,也可以部署在多个进程,以及云提供商的k8s环境中,下面我们就来看看weaver应用的部署,先来将单进程部署模式改为本地多进程部署模式。

4. 部署

基于Weaver应用的部署方式与编码完全解耦,我们无需修改源码便可以实现多进程部署。唯一要做的就是改改weaver.toml,新增多进程部署模式下应用的监听地址信息:

// weaver.toml
[single]
listeners.lis = {address = "localhost:8080"}

[serviceweaver]
binary = "./httpserver"

[multi]
listeners.lis = {address = "localhost:8080"} // 新增

接下来使用下面命令,我们就可以将httpserver以多进程的形式启动起来:

$weaver multi deploy weaver.toml
╭───────────────────────────────────────────────────╮
│ app        : httpserver                           │
│ deployment : bd689290-4929-47f1-a0f0-774d5e1a9307 │
╰───────────────────────────────────────────────────╯
S1003 18:51:02.042859 stdout               ac04576d                      │ http listener available on 127.0.0.1:8080
S1003 18:51:02.043210 stdout               c03c4eed                      │ http listener available on 127.0.0.1:8080

weaver multi子命令提供了查看httpserver多进程启动后状态的方法:

$weaver multi status
╭──────────────────────────────────────────────────────────╮
│ DEPLOYMENTS                                              │
├────────────┬──────────────────────────────────────┬──────┤
│ APP        │ DEPLOYMENT                           │ AGE  │
├────────────┼──────────────────────────────────────┼──────┤
│ httpserver │ bd689290-4929-47f1-a0f0-774d5e1a9307 │ 1m3s │
╰────────────┴──────────────────────────────────────┴──────╯
╭───────────────────────────────────────────────────────────────╮
│ COMPONENTS                                                    │
├────────────┬────────────┬──────────────────────┬──────────────┤
│ APP        │ DEPLOYMENT │ COMPONENT            │ REPLICA PIDS │
├────────────┼────────────┼──────────────────────┼──────────────┤
│ httpserver │ bd689290   │ weaver.Main          │ 30194, 30195 │
│ httpserver │ bd689290   │ httpserver.Converter │ 30198, 30199 │
│ httpserver │ bd689290   │ httpserver.Reverser  │ 30196, 30197 │
╰────────────┴────────────┴──────────────────────┴──────────────╯
╭─────────────────────────────────────────────────────╮
│ LISTENERS                                           │
├────────────┬────────────┬──────────┬────────────────┤
│ APP        │ DEPLOYMENT │ LISTENER │ ADDRESS        │
├────────────┼────────────┼──────────┼────────────────┤
│ httpserver │ bd689290   │ lis      │ 127.0.0.1:8080 │
╰────────────┴────────────┴──────────┴────────────────╯

在status输出的信息中,我们能看到deployment(部署)信息、组件(components)信息以及listener信息。从组件信息来看,weaver multi子命令将每个component放入了一个单独进程,包括main component,并且每个component的副本数(replica)为2,即一共启动了6个进程。从下面ps命令的输出结果也能印证这点:

$ps -ef|grep httpserver
  501 30194 30193   0  6:51下午 ttys006    0:00.05 /Users/tonybai/test/go/service-weaver/httpserver/httpserver
  501 30195 30193   0  6:51下午 ttys006    0:00.05 /Users/tonybai/test/go/service-weaver/httpserver/httpserver
  501 30196 30193   0  6:51下午 ttys006    0:00.07 /Users/tonybai/test/go/service-weaver/httpserver/httpserver
  501 30197 30193   0  6:51下午 ttys006    0:00.04 /Users/tonybai/test/go/service-weaver/httpserver/httpserver
  501 30198 30193   0  6:51下午 ttys006    0:00.05 /Users/tonybai/test/go/service-weaver/httpserver/httpserver
  501 30199 30193   0  6:51下午 ttys006    0:00.04 /Users/tonybai/test/go/service-weaver/httpserver/httpserver

在multi process这种模式下,应用的各个组件由于不在同一进程内,它们之间的通信由基于方法调用改为了基于RPC调用的方式。

weaver multi还提供了以web形式查看应用运行状态的命令:dashboard

$weaver multi dashboard
Dashboard available at: http://127.0.0.1:62183

weaver multi dashboard命令会自动打开浏览器并展示httpserver的各种运行信息和状态信息:

点击页面上的Deployment超链接,我们将进入到下面的页面中:

除此之外,页面最下方还有一个展示组件拓扑以及组件间traffic的图:

通过上图我们知道,reverse端点和convert端点分别接到过2次和1次请求。

注:web状态页面上的traces由于没有开启trace,会暂无数据。

和weaver multi一样,weaver ssh可以实现多机器部署,weaver kube实现基于k8s的部署,weaver gke实现在Google Kubernetes Engine上的部署,这里的multi、ssh、kube等都可以称为deployer。single、multi、ssh是weaver内置支持的,而其他weaver 则是调用weaver-完成的,比如:weaver gke status将调用weaver-gke status命令。

注:由于手里没有现成的kubernetes环境,weaver kube命令无法展示了。

到这里,我们已经践行了Service Weaver的两大核心原则:开发阶段以单体程序形式编码开发,以及运行时通过不同deployer(multi、ssh、k8s等)来实现部署环境与代码的解耦。到这里,你是否体会到了本文题目“以单体形式编码,以微服务形式部署”的深意了呢!

下面我们再来看看Weaver核心原则的第3条:原子升级。

5. 升级

对于使用go run或weaver multi deployment部署的应用程序来说,避免升级过程中的跨版本通信是轻而易举的事,因为每个部署都是独立运行的。

我本地没有Kubernetes环境,也没有GKE的账号,那么如何验证weaver的原子升级过程呢?好在weaver提供了gke-local,即在本地建立一个模拟gke环境,我们可以使用这种方式来看看通过weaver如何实现app的原子升级。

首先我们要执行下面命令单独安装weaver-gke-local:

$go install github.com/ServiceWeaver/weaver-gke/cmd/weaver-gke-local@latest

在我的机器和网络环境下,这个安装过程略显“漫长”,因为要拉取很多依赖的go module,还包括像k8s、k8s client这样的go module。

安装好weaver-gke-local后,我们基于httpserver建立一个新module:httpserver-upgrade。然后修改其weaver.toml,增加gke和rollout相关配置:

// serviceweaver-examples/httpserver-upgrade/weaver.toml

[single]
listeners.lis = {address = "localhost:8080"}

[serviceweaver]
binary = "./httpserver"
rollout = "5m" # Perform five minutes slow rollout.

[multi]
listeners.lis = {address = "localhost:8080"}

[gke]
regions = ["us-west1"]
listeners.lis = {public_hostname = "hello.com"}

然后,为了区分不同版本,我在main.go中为各个端点的处理handler加上了一些带有版本信息的日志,并重新执行make构建新的可执行文件。

下面我们就在gke-local环境下首次部署httpserver:

$weaver gke-local deploy weaver.toml
Deploying the application... Done
Version "b343b4de-bb84-4bd7-8bc0-09eb0054b07d" of app "httpserver" started successfully.
Note that stopping this binary will not affect the app in any way.
Tailing the logs...
S1004 06:33:14.621470 stdout               ea68b26c                      │ http v1 listener available on http://localhost:8000
S1004 06:33:14.627226 stdout               be97798d                      │ http v1 listener available on http://localhost:8000

我们可以ctrl+c结束weaver gke-local deploy这个命令的执行,但一旦部署成功,即便这个命令退出,已经部署的程序依然会运行。

^CTo continue watching the logs, run the following command:

    weaver gke-local logs --follow 'version == "b343b4de"'

并且按照上述提示,我们可以继续执行下面命令来tail整个应用的输出日志:

$weaver gke-local logs --follow 'version == "b343b4de"'
S1004 06:33:14.621470 stdout               ea68b26c                      │ http v1 listener available on http://localhost:8000
S1004 06:33:14.627226 stdout               be97798d                      │ http v1 listener available on http://localhost:8000

和multi子命令在本地多进程部署一样,在gke-local下部署后,我们也可以使用status查看应用部署信息和状态:

$weaver gke-local status
╭────────────────────────────────────────────────────────────────────╮
│ Deployments                                                        │
├────────────┬──────────────────────────────────────┬───────┬────────┤
│ APP        │ DEPLOYMENT                           │ AGE   │ STATUS │
├────────────┼──────────────────────────────────────┼───────┼────────┤
│ httpserver │ b343b4de-bb84-4bd7-8bc0-09eb0054b07d │ 4m55s │ ACTIVE │
╰────────────┴──────────────────────────────────────┴───────┴────────╯
╭─────────────────────────────────────────────────────────────────────╮
│ COMPONENTS                                                          │
├────────────┬────────────┬──────────┬──────────────────────┬─────────┤
│ APP        │ DEPLOYMENT │ LOCATION │ COMPONENT            │ HEALTHY │
├────────────┼────────────┼──────────┼──────────────────────┼─────────┤
│ httpserver │ b343b4de   │ us-west1 │ weaver.Main          │ 2/2     │
│ httpserver │ b343b4de   │ us-west1 │ httpserver.Converter │ 2/2     │
│ httpserver │ b343b4de   │ us-west1 │ httpserver.Reverser  │ 2/2     │
╰────────────┴────────────┴──────────┴──────────────────────┴─────────╯
╭─────────────────────────────────────────────────────────────────────────────────────────────╮
│ TRAFFIC                                                                                     │
├───────────┬────────────┬────────────┬────────────┬──────────┬────────────┬──────────────────┤
│ HOST      │ VISIBILITY │ APP        │ DEPLOYMENT │ LOCATION │ ADDRESS    │ TRAFFIC FRACTION │
├───────────┼────────────┼────────────┼────────────┼──────────┼────────────┼──────────────────┤
│ hello.com │ public     │ httpserver │ b343b4de   │ us-west1 │ [::]:62559 │ 0.5              │
│ hello.com │ public     │ httpserver │ b343b4de   │ us-west1 │ [::]:62564 │ 0.5              │
╰───────────┴────────────┴────────────┴────────────┴──────────┴────────────┴──────────────────╯
╭────────────────────────────╮
│ ROLLOUT OF httpserver      │
├─────────────────┬──────────┤
│                 │ us-west1 │
├─────────────────┼──────────┤
│ TIME            │ b343b4de │
│ Oct  3 22:37:59 │ 1.00     │
╰─────────────────┴──────────╯

我们看到整个应用被模拟部署到us-west1 region,每个组件有两个副本,用ps命令查看,我们也能看到6个进程:

$ps -ef|grep httpserver
  501 38480 35224   0  6:33上午 ttys006    0:00.13 /Users/tonybai/test/go/service-weaver/httpserver-upgrade/httpserver
  501 38481 35224   0  6:33上午 ttys006    0:00.11 /Users/tonybai/test/go/service-weaver/httpserver-upgrade/httpserver
  501 38482 35224   0  6:33上午 ttys006    0:00.10 /Users/tonybai/test/go/service-weaver/httpserver-upgrade/httpserver
  501 38483 35224   0  6:33上午 ttys006    0:00.10 /Users/tonybai/test/go/service-weaver/httpserver-upgrade/httpserver
  501 38484 35224   0  6:33上午 ttys006    0:00.10 /Users/tonybai/test/go/service-weaver/httpserver-upgrade/httpserver
  501 38485 35224   0  6:33上午 ttys006    0:00.10 /Users/tonybai/test/go/service-weaver/httpserver-upgrade/httpserver

现在我们可以使用curl命令来验证一下应用的可用性:

$curl  --header 'Host: hello.com' "http://localhost:8000/reverse?name=abcdefg"
after reversing-v1, name is gfedcba
$curl  --header 'Host: hello.com' "http://localhost:8000/reverse?name=abcdefg"
after reversing-v1, name is gfedcba
$curl  --header 'Host: hello.com' "http://localhost:8000/reverse?name=abcdefg"
after reversing-v1, name is gfedcba
$curl  --header 'Host: hello.com' "http://localhost:8000/convert?name=abcdefg"
after converting-v1, name is ABCDEFG
$curl  --header 'Host: hello.com' "http://localhost:8000/convert?name=abcdefg"
after converting-v1, name is ABCDEFG

可以看到,app工作正常!

此外,我们还可以通过dashboard可以以图形化的方式观测app状态(weaver gke-local dashboard),在后续升级过程中,通过dashboard可以清楚地看到整个升级过程:

注:gke-local会在本地建立一个模拟load balancer,并将发到hello.com主机的请求按Traffic Fraction分发给不同副本。

接下来,我们就来开发httpserver的v2版本,将main.go中的version改为v2,然后重新编译httpserver,执行下面命令部署新版httpserver:

$weaver gke-local deploy weaver.toml
Deploying the application... Done
Version "2ee38e73-323f-4b42-b115-ee5bc40a8c09" of app "httpserver" started successfully.
Note that stopping this binary will not affect the app in any way.
Tailing the logs...
S1004 06:50:12.575585 stdout               702058ba                      │ http v2 listener available on http://localhost:8000
S1004 06:50:12.586352 stdout               ef3d7c3f                      │ http v2 listener available on http://localhost:8000

^CTo continue watching the logs, run the following command:

    weaver gke-local logs --follow 'version == "2ee38e73"'

由于我们配置的rollout为5分钟,所以新版httpserver替换掉旧版httpserver的过程会持续5分钟。而这个过程中load balancer针对新旧两个版本的Traffic Fraction也会动态调整:旧版本会逐渐降低,新版本会逐渐升高:



这时向app发送的请求,既可能由v1版本处理,也可能由v2版本处理:

$curl  --header 'Host: hello.com' "http://localhost:8000/convert?name=abcdefg"
after converting-v1, name is ABCDEFG
$curl  --header 'Host: hello.com' "http://localhost:8000/reverse?name=abcdefg"
after reversing-v1, name is gfedcba
$curl  --header 'Host: hello.com' "http://localhost:8000/convert?name=abcdefg"
after converting-v1, name is ABCDEFG
$curl  --header 'Host: hello.com' "http://localhost:8000/reverse?name=abcdefg"
after reversing-v2, name is gfedcba

最后新版app将全面接手对请求的处理:

之后,旧版的app将被delete掉:

这样新版app的升级部署(rollout)就结束了!rollout后,所有请求将被v2版本处理,应答中将带有v2字样。

在新版本升级的过程中,你如果使用ps查看httpserver进程数量,你会发现数量多出一倍,那是因为整个rollout过程采用的是蓝绿部署方式,即完全部署一套新app,然后通过调整load balancer的分发比例,让新版app逐渐承担全部流量,而在这个过程中,不会存在新老版本组件交互的情况出现。下图展示了这一过程:

注:如果要杀掉app,可以用weaver gke-local kill httpserver命令。

6. 小结

Service Weaver是一个优秀的框架,可以帮助开发人员以单体形式快速构建、以微服务形式快速部署分布式应用,其三个核心原则的创新思路值得我们学习借鉴。

但Service Weaver也不是万能的,Service Weaver主要针对在线的分布式服务系统,即需要在用户请求到达时处理它们的系统,例如网络应用程序或API Server正是此类分布式服务系统。基于Weaver开发这类系统,应用可以轻松获取网络Listener并建立HTTP 服务器,应用可以支持原子升级,且应用组件的副本数量可以根据请求压力的大小自动扩缩(本文并未演示这个特性)。

不过要注意的是:Service Weaver仅仅开源了几个月,其API尚未Stable,本文中的示例基于v0.21.2版本实现,也许在未来的某个时间点,这些示例可能会因API的变化而无法Run起来, status命令和dashboard命令所展现给用户的样式也会发生变化。另外学习weaver本身也是有学习成本的,weaver自身的代码由于采用了泛型和反射,读起来也是很晦涩。

综上,Service Weaver所践行的理念的优秀的,但考虑其成熟度以及Go社区崇尚的“The Best Go framework is no framework”的信条,选择引入Service Weaver框架之前务必要仔细斟酌。

本文涉及的Go源码,可以在这里下载。

7. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

微博(暂不可用):https://weibo.com/bigwhite20xx
微博2:https://weibo.com/u/6484441286
博客:tonybai.com
github: https://github.com/bigwhite
Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats