DockOne微信分享（一七〇）：贝壳找房权限服务的探索和实践

【编者的话】认证授权，作为服务的重要组成部分之一，在微服务/平台化的背景下，迎来了新的挑战。庞杂的业务应用 vs 精深的中台服务，在权限模型上有何异同？又该如何分而治之，且自洽呢？在链家网向贝壳找房平台化的进程中，我们分别生产了”面向服务“和”面向用户“两套权限服务，试图打造一个立体的权限系统。

听了很多场Kubernetes的分享，深感大家贴近时代的潮流。今晚我抛砖引玉，来聊聊plain boring的权限系统，看看能不能唤醒大家那些good old days:)

贝壳找房是基于原有链家网的技术能力，新推出的房产平台服务。我们作为贝壳找房的基础技术团队，为业务系统提供了多个服务，比如用户中心，存储服务，图片服务，400号码服务等等。在对接各业务系统过程中，都面临着同样的问题：

1. 身份标识：明确身份，我们才有能更精确而且有效地实现限流，融断，配额等功能；
2. 权限分配：权限控制是大多数业务发展到一定阶段都需要面临的问题，如何确保不同业务的资源隔离，并实现细粒度的控制权限？
   在单个服务中，这些问题看似简单，在多个服务特别是微服务架构下被放大了。

我们期望有这么一套系统，它能提供了统一的身份标识，进而提供可靠的认证机制，进而提供自助的权限管理。我们可以把密钥管理，接口签名，权限分发等等一系列问题抛之脑后，专注于自身服务。

刚好，我们当时使用着AWS的基础服务，有一定的AWS IAM使用经验。IAM的模型，十分契合我们的想法（或者说，我们已经被先入为主了）。但遗憾的是，IAM作为云服务的基础设施，是不对外提供服务的。

上图是AWS IAM一个简单的系统分解。对于不熟悉IAM的同学，可前往 https://docs.aws.amazon.com/zh ... .html 自行了解。

一开始，我们是强烈避免重复造轮子的，我们将目光转向了OpenStack的keystone，尝试二次开发。但经过短暂的调研后发现，keystone是一个传统的RBAC权限模型；每个服务维护着自己的policy.json，配置无法产品化；维护Token，给无状态的服务带来了负担。我们考虑到适配和理解层面上的阻抗，加之一定无法合并到上游的命运，无奈下放弃了这个方案。在没有合适的候选方案下，我们做了心理建设，开始了自研的工作。

自研IAM比较好的情况是，在AWS IAM，阿里云RAM，腾讯云CAM等体系教育下，整个客户端的行为已经十分明确，服务端的业务行为基本能被倒推出来。唯一无从知晓的，是服务端的架构方式。

理想情况下，我认为性能最优的一个方案是：所有服务以一种语言实现，IAM的功能作为SDK的方式集成在服务之中，SDK依赖弹性伸缩的数据服务，辅以上层负载均衡依照AK将请求路由到不同的分区，以期保证性能的同时，达到更高的灵活度。

然而，我们根据我司的现实情况，做了一些不一样的决策：

由于我司开发语言以Java和PHP为首，我们需要以接口的形式提供多语言的支持。

由于我们无法把控服务实现的质量，我们决定：服务无法拿到使用方的Secrect Key。这会导致认证和授权的捆绑，势必不是最优解，但是我们能确保安全。

考虑到请求到服务，服务转到IAM做鉴权的场景，我们认为跨服务的鉴权也是不合理的，故对鉴权请求也做了AK/SK加密：只有服务对应的IAM主体才能操作对应服务资源，实现了自举。

最终的流程图：

我们选择了Golang来实现IAM。服务到IAM的请求使用的是gRPC，通过grpc-gateway添加了HTTP接口的支持，方便测试。

由于Policy天生的复杂度，我们在落地MySQL的同时，按用户和服务为最小粒度，以protobuf的形式全量保存在Redis，然后拉取到BigCache做内存缓存。最终在m3.2xlarge的机器上，QPS可达到 1W+，Latency控制在2ms之内。由于避免了额外IO，再加之每个请求2次加解密的需求，和Resource基于字符串的匹配，导致CPU成为瓶颈。

由于考虑到了后续可能会开源，我们对RMDB，集中缓存，事件通知等外部依赖都使用了interface，做成了可插拔的组件。（如果群里有专利方面的大拿，还请不吝赐教，能否开源）

提个用户体验的小case，大家知道，由于权限系统会大量使用缓存，时效性一般不做严格保证。我们服务的内存级缓存，最初设置成了5分钟。在用户使用时，这5分钟的缓存，也造成了很大的干扰。我们发现，用户改完后，都会亲自测试下；等5分钟后再试，使用体验是反人类的。所以，我们认为对于权限系统来说，时效性应该是秒级。我们加上基于Redis的事件通知机制后，基于控制台的使用体验一下子就好转了。

在服务端接入的时候，造成很大困扰的是，IAM对Body的加签设定。大家知道，基本上所有语言，HTTP Request Body都是流式设计，这意味着服务在做验签之前，要消费掉body，同时feed到sha256等hash算法内。这样的话，业务逻辑和验签逻辑交织在一起，造成了耦合。我们萌发了自己定义加签规范的念头，将这个需求拆解成两步：带body的请求带content-md5头，IAM验证头信息，服务可选验证content-md5. 这就演化成了我们统一API签名的项目，具体就不展开了。

当服务方接入IAM，常常需要一个思路上的转化：服务方自己其实不是资源的拥有者！在IAM体系中，资源的拥有者是首次申请资源的根帐号，根帐号再将权限切割出来分配给子用户。服务方仅提供服务能力，在控制台内不能对资源做任何管控，管控是由业务方自主完成的！

可以说，IAM很好的达到了我们对它的预期。但对服务来说，天生多租户/平台化的要求，导致了IAM推广落地的难度，我们急需一个落地媒介，这就是服务目录。

服务目录作为链家网基础服务部孵化的内部项目，类似云服务WebConsole的统一入口，旨在降低沟通成本，提高使用体验。

服务目录提供了一个基于React的前端框架，和一个基于NodeJS的大前端，内嵌了多个服务面板。

每个服务面板可自行打包，独立内嵌，互不干扰。

服务目录以IAM系统做身份认证，提供了统一的应用到服务间签名SDK，以及服务端到IAM间SDK。

由于服务目录有代理用户操作的需求，我们给服务目录的NodeJS大前端颁发了一个Super AK，由此AK发起的请求完全受信，做到了和IAM服务的打通。

我们期待服务目录能够盘活整个中台服务体系，乃至有需求的业务应用，使服务逐步平台化，产品化。

上图是我们预期的整体架构。业务层负责对接具体的业务，其他所有层为其赋能；服务层提供业务无关的通用能力，但不直接参与到具体的业务实现；基础设施层提供稳定可靠的存储/计算等能力。业务到服务间通过IAM授权，用户通过服务目录管理资源。所有层都具有监控报警等基础能力。

聊完业务和服务之间的权限管控，我们来聊聊用户和业务之间的权限管理。

大家可能认为，这不是集成个Shiro生成几张数据库表的事儿吗？诚然，这样的确能满足需求。

但是，当业务扩大到成百上千个，每个业务都去做权限系统的CRUD及其对应的后台页面时，这就产生了巨大的浪费。如果再加上审批审计，批量导入导出，业务层控件开发等等一系列功能呢？再加上PM/运营人员的学习使用成本呢？

所以，统一的业务层用户权限体系仍然是有很大价值的。但如何做到能够灵活地支持多个业务方？在业务方有需求的时候，能快速的响应，或者指导业务方自身完成，对我们来说，仍然是一个巨大的挑战。

很有趣的是，在刚刚做完IAM主体开发后，我们立马拿到了一个新的项目：重构用户中心权限服务。

我想每个互联网公司都有一套自己的用户中心，链家网的用户中心是由用户信息，单点登陆，及权限系统三部分组成。权限系统发源于B端业务，初期很好地满足了业务需求，但随着业务的发展，新功能的添加，慢慢凸显出一些矛盾：

1. 权限和用户中心的代码，同一仓库，耦合性高，缺乏独立上线的能力。
2. 用户中心支持内网外用户，而权限系统只支持内网用户。
3. 权限系统的多租户支持是以每个table添加appid column实现的；租户间容易相互干扰，容易造成数据的不一致。
4. 基于RMDB的API没有做上层封装，使用复杂；权限信息拉取，需要三个请求，导致性能低下。
5. 时效性低：人员变动引起的权限变化，得等到每晚凌晨跑批处理；角色的生效，也得手动跑批。
6. 传统页面应用，没有写入接口。
7. 数据安全问题，没有坚持最小安全原则

稍微铺垫一下，跟IAM系统截然相反，用户权限系统，是基于RBAC权限模型。

之前的同学在权限点的维度上，创造性地附加了“约束”的概念。“约束”是一个KV的结构，描述了权限点（功能权限）对应的数据范围。

使用方式为：业务接入方，在用户登陆后，向我们拉取权限信息，缓存在本地；之后所有的操作，即可通过角色信息，权限点列表，和权限对应的数据约束，解释出yes or no的结果。

所以，分析下来，“用户权限系统”实际上是一个垂直领域的，支持多租户的CMS系统。

在用户权限系统中，约束是权限点的扩展，那角色的扩展呢？用户的扩展呢？

于是，我们新加入了几个扩展点，方便业务各个维度的自定义需求：

1. Property属性 作为角色的扩展，属性有预定义的相关类型：如单选枚举，多选枚举，组织树，自定义等等。租户内角色属性是一致的，租户间角色属性是多Schema的。
2. Extension约束 作为权限点的扩展，约束也支持类型。约束需预先挂接到权限点；角色添加权限点时，约束以对应的控件渲染，同时可附加“不约束”和“为空”两种状态。
3. 用户有统一的UCID，但每个业务有不同的用户属性。我们支持多数据源用户的同步，同步来的用户属性归属在数据源名字空间下，其他所有业务均可使用。用户的属性有一个很重要的作用，用来实现基于规则的自动绑定，比如这样的表达式：(user.sex == “M” && user.age > 30) || (user.orgCode contains “1111”) 。

在这里，我想着重提一下”类型“，我认为这是一个很好的设计：它保证了底层数据的独立性，稳定性；在上层以控件形态，指导自然人使用；对应用提供了meta信息，指导SDK解释含义。它将一个个无含义的KV，填充了血肉，贴近了业务。

上图是我们用户权限系统的简单架构图。

我们把它实现成了一个DB级别隔离的多租户系统，一个CQRS（读写模型分离）的系统，一个业务端 Multi-Schema的系统。

如上图，后台Luke使用的技术栈是NodeJS (TypeScript) / GraphQL (Apollo + Dataloader) / MongoDB (Mongoose)；服务目录的控制台LukePanel的技术栈是ES6 / React / Apollo Client / AntDesign； Luke和LukePanel通过项目Chawbacca公用前后台验证逻辑；前台Leia因为要支持Dubbo，选择了Spring，提供了WebFlux API 和 Dubbo Facade，通过SpEL做权限的实时计算。

从技术选型上可以看出，我们推崇合适的工具做合适的事情。TypeScript和GraphQL都给了我们很大的惊喜，通过Schema Stitch和JSON scalar，我们透明处理了DB隔离和MultiSchema，在保证工程质量的同时，确保了工程进度。

谈到权限的实时生效，我们可以改进之前的定时跑批，做到基于事件流的实时处理。然而，考虑到“潜在用户刷新量大”和“刷新需加锁串行执行”的问题，为保证时效性，我们并没有选择这种方案，而是选择了“首次访问时做实时计算“的实现方式，这样可以筛选出真实用户，事件处理只需要”无脑“清缓存即可，而代价仅是计算支持一定的并发，且延迟不能太大。

比较好玩的是，所有权限系统，第一件客户始终是自己，通过自举，给自己赋能，是一件很有乐趣的事儿。

今晚讲了两个权限体系，希望能给大家一些启发。在实现的过程中，我们收获很多乐趣，我们也希望能把这两个系统真正落地下来，产生应有的价值。希望大家多多指教！

Q&A

Q：请问链家这个业务和服务之间的权限管控，和Kubernetes中的RBAC实现有什么区别呢？

A：Sorry，对Kubernetes的RBAC模式不熟悉，但是我想都是基于同一个权限模型，不会有太大差距。RBAC有RBAC1,2,3,4多个粒度，都是基于最基本的角色/权限的扩充。我刚刚看了下文档，看到了支持用户组Group，resourceNames支持到了Row Based粒度，从功能上应该算完备了吧。

Q：为什么选择Golang作为后端的实现呢？有遇到什么印象深刻的“坑”吗？

A：因为我们team主推的语言是Go：）由于Golang，gRPC，Protobuf都是Google主推的项目，集成的体验还是相当愉悦的。

我们实现的时候，遵循了社区的建议，Library over Framework（比如orm选择了sqlx），没有遇到太多的坑。

有几个小坑可以分享下：

HTTP Content-Length / Host等Header实际上不在Headers对象里，而是作为了request的基础属性，在我们实现签名的时候被坑了一把。

HMac的Hashlib不支持Reset，我们无法放到sync.Pool中。因为加解密重度依赖此模块，我们不得以用type alias + internal包路径hack了一把。

最后还有说好的dep要进官方，结果被Russ的vgo横插了一把，感觉很怨念，又要切工具了。

以上内容根据2018年5月3日晚微信群分享内容整理。 分享人 尹吉峰，链家网基础架构部研发工程师，开源爱好者/参与者，酷爱原型搭建，现负责基础权限服务 。DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesa，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。