
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务的授权模式是程序员在学习微服务架构技术的时候需要重点掌握的一个编程知识点,下面我们就通过案例分析来了解一下,微服务授权模式应用方法分析。
将所有授权数据和逻辑放在一个地方,与需要实施授权的所有服务分开。实现此模式的常见方法是构建专用的“授权服务”。然后,当其他服务需要执行权限检查时,它们会转向询问授权服务:
在这个模型中,文档服务根本不关心用户的角色:它只需要询问授权服务,用户是否可以编辑文档,或者用户是否可以查看文档。授权服务本身包含做出该决策所需的所有内容(包括角色数据)。
这可能非常有吸引力:你现在有一个负责授权的系统,这符合微服务的哲学。以这种方式进行责任分离有一些好处:团队中的其他开发人员不需要关心授权是如何工作的。因为它是独立的,所以你对授权服务所做的任何优化都有助于加速整个系统的其余部分。
当然,这种责任分离是有代价的。现在,所有授权数据都必须保存在一个地方。决策中可能使用的所有内容都必须保存在一个集中式服务中,这些内容包括用户在组织中的身份、文档与其组织的关系。要么授权服务成为该数据的真实来源,要么必须将数据从应用程序复制并同步到该中心(可能性更大)。授权系统必须理解作为所有权限基础的整个数据模型:组、共享、文件夹、来宾、项目。如果这些模型经常改变,授权系统可能成为新的开发任务的瓶颈。任意微服务中的任何更改都可能需要对授权服务进行更新,从而打破你在初转向微服务时可能寻求的关注点分离效果。
还有其他因素会使授权服务变得棘手:部署这一负责保护每个请求的服务意味着你要负责实现高可用和低延迟。如果系统出现故障,则所有请求都会被拒绝。如果授权系统系统的响应很慢,那么每个请求都很慢。
你必须将所有数据以“元组”的形式插入到Zanzibar中。由于它限制了可以存储的数据,有些规则实际上不能仅用Zanzibar来表示,例如一些必须与时间、请求上下文有关的规则,或者依赖于某种计算的规则。有人将这些称之为“基于属性”的规则。例如,用户每周只允许创建10个文档,或者管理员可以将某些文件夹设置为“只读”,以防止对其中文档的编辑。在这些情况下,开发人员必须在Zanzibar之外编写自己的策略逻辑。
集中式授权存在的挑战往往会阻止大多数团队采用这种模式。采用该模式的应用往往有很多服务和足够复杂的数据模型,接受授权服务本身增加的复杂性对它们来说是有意义的。例如,为了从单体应用向微服务转型,Airbnb建立了一个名为Himeji的授权服务以支持他们的授权模式。已经有一个专门的工程师团队为它工作了两年,而且可能会无限期地工作下去。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。