买单侠任浩军：微服务API级权限的技术架构

背景：权限是根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源。在实际的生产系统中，用户数量十分庞大，权限的划分需要结合具体的业务场景，一旦把控不住力度，工作十分繁重，如何解决这个问题？

例如，对于一个文件系统的权限来说，用户A和B只具有查看和拷贝该文件系统下某些文件的权限，而用户C和D不仅有查看和拷贝文件的权限，也具有修改和删除文件的权限，这些权限的划分和授权需要事先通过专门管理员进行操作。

业界专门提出了一套权限模型和方法，RBAC（Role-Based Access Control），即基于角色（Role）的访问控制方法。它的核心概念如下:

角色（Role）与权限（Permission）相关联，一个角色对应多个权限

用户（User）与角色（Role）相关联，一个用户对应多个角色

权限（Permission）包含资源，或者与操作组合方式相结合

这样，我们就实现了让用户通过成为适当角色的成员而得到这些角色的权限，最终实现权限控制的目的。

结合上述的文件系统例子，我们可以去用RBAC去刻画和描述：

文件系统中的文件是权限概念中的“资源”，对文件的删除是“操作”，那么我们可以定义出一个“文件删除”的权限来。

访问文件系统的用户A、B、C和D即上述模型中的用户，当然如果用户很多，我们可以划分出“用户组”概念。

对于角色，我们可以划分出两个角色，第一个是“文件普通用户”角色，它包含“文件查看”和“文件拷贝”两个权限；第二个是“文件管理员用户”角色，它包含“文件修改”和“文件删除”两个权限。

一言以蔽之，基于角色的访问控制方法的访问逻辑表达式为“Who对What(Which)进行How的操作”，它的由内到外的逻辑结构为权限->角色->用户，即一个角色对应绑定多个权限，一个用户对应绑定多个角色。

从图中可以看到，用户A和B赋予了“文件普通用户”角色，即他们拥有了“文件查看”和“文件拷贝”的权限；

用户C和D同时赋予了“文件普通用户”和“文件管理员用户”的两个角色，即他们拥有了“文件查看”、“文件拷贝”、“文件修改”和“文件删除”。

如果后面，我们觉得“文件拷贝”有文件泄密的安全问题，那么只需要从它从“文件普通用户”角色移除就可以了，上述4个用户自然无法实行对文件拷贝的这个操作了，所以RBAC模型对于权限扩展和收缩非常方便。

 

阐述完权限系统的基本概念后，我们来讲讲，权限系统在互联网时代的分布式系统中，尤其是微服务架构的体系下,有什么样的挑战？它又必须解决哪些问题，最适合采用什么框架和技术去解决这些问题？

服务实例数量庞大

目前，组成买单侠业务线系统，有将近400多个微服务，我们知道微服务的优点是可以清晰的划分出业务逻辑来，让每个微服务承担职责单一的功能，毕竟越简单的东西越稳定。

但是，微服务也带来了很多的问题，完成一个业务操作，需要跨很多个微服务的调用，那么如何用权限系统去控制用户对不同微服务的调用，对我们来说，是个挑战。

用户系统数量多类型复杂

目前，接入买单侠业务线的用户系统数量多类型复杂，且数据分散，比如有公司的员工系统（LDAP系统），公司的销售人员系统，公司的外包人员系统，外部互联网用户系统（使用APP的客户）。

不同类型的用户系统都有可能接入某些微服务，那么如何用权限系统去控制不通用户对同一个微服务的调用，对我们来说，又是一个挑战。

微服务吞吐量大 可用性要求高

当业务微服务的调用接入权限系统后，不能拖累它们的吞吐量，当权限系统出现问题后，不能阻塞它们的业务调用进度，当然更不能改变业务逻辑。

已有业务系统快速接入权限