关于中台鉴权服务架构设计

关于中台鉴权服务架构设计随着中台化概念的推出,这两年中台化概念如火如荼。互联网公司几乎人人都在谈论各种中台,什么用户、搜索、推荐、营销、支付等等。

大家好,欢迎来到IT知识分享网。

首先看下什么是中台

随着中台化概念的推出,这两年中台变得如火如荼。互联网公司几乎人人都在谈论各种中台,什么用户、搜索、推荐、营销、支付中台等等。似乎哪家公司不做中台都不好意思了。原来我们说前端(Client/Browser),后台(Backend),现在又蹦出一个中台来,而这个中台是为前端的后台服务的。

那么究竟什么才是中台呢?众说纷纭,莫衷一是。一般来讲就是指搭建一个面向众多个上层业务的公共服务模块,以达到提升开发效率和功能复用的目的。而相比之前的SOA服务化,中台做了一些整合与隔离,面向特定的领域提供各种独立的子服务,并增加了统一网关,再将各子服务加工为整套的解决方案。

关于中台鉴权服务架构设计

了解下中台的技术架构

中台技术架构一般都是基于微服务(Microservice)架构体系的。微服务相对单体(Monolithic)架构下的大型应用来讲,主要是将各种服务轻量化和微型化、独立化。微服务会把各种模块都独立为一个微型的子应用,各应用之间相互隔离,通过接口和消息来进行通信和驱动。

关于中台鉴权服务架构设计

这样做的好处就是,各子服务都是独立的,一个服务出问题不会影响到全部,而且因为服务都比较小,在开发、部署、升级都变得简单和灵活。这是一种典型的松耦合、去中心化架构。我们知道单个系统如果过于庞大,就会变得臃肿,渐渐失去活力,而微服务则不然,各自独立自治,把自己做好做强,整体就会有更强大的生命力。当然微服务也有缺点,就是带来了无数小系统的管理与运维问题,以及各服务之间因为独立而导致的开发冗余。微服务一般会遵循AKF 可扩展立方(Scalability Cube)原则,中台架构设计也一样,否则随着微服务的庞杂也会变得臃肿不堪。

中台与应用调用的关系

中台一般都是基于微服务技术架构,但是与一般的微服务不一样的是,中台并不会直接面向客户端,而是通过能力输出,赋能上层业务,即供前台来调用。这时候处理好各种调用方与中台服务之间的关系就变得非常重要,否则就会出现错乱和错用的情况。为了解决业务方与中台之间的调用关系,就需要设计一套完善的调用授权机制,让各应用方既能享受到公共服务的便利,又与其他各方互不干涉,做到安全可靠。

关于中台鉴权服务架构设计

业务方要想接入中台,需要以开发者身份来创建账户,申请权限后,再进行相关调用。

整个过程如下:

1、业务方先申请账户和角色

2、再分配开发者token以及配置相应接口和资源权限

3、再挂载某个服务流程套餐(服务流程来自服务与接口的编排),调用接口时可以传递套餐方案

4、再就是根据API文档进行调用

中台鉴权服务设计

在鉴权这块,我们设计了一个中台鉴权服务。一般的中台服务,并不太需要这个鉴权服务体系,一般只需要网关层面的token鉴权即可,但是对于复杂的中台架构体系,就有必要专门设计一套鉴权服务了,对于API以及资源进行统一的管理授权。

这里的鉴权服务之所以需要增加资源鉴权,是因为某个资源可能为多个业务方共享,我们需要根据授权配置来确定调用关系。

关于中台鉴权服务架构设计

授权与调用过程如下:

首先,给开发者token配置api访问权限,以及配置api的资源操作权限,比如依据资源的重要属性、业务属性进行授权。

其次,调用方在访问api接口时,网关根据权限配置确定是否具备某个api的访问权限。

最后,中台服务根据权限配置,实时计算资源属性与权限关系,确定这次调用是否合法。

经过以上的中台资源配置,再加上中台鉴权服务设计,我们基本上解决了中台接口鉴权和资源鉴权的问题,达到了按需操作数据资源的目的,有效保障了数据安全。

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/80864.html

(0)

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

关注微信