鉴权的三个参数（关于中台鉴权服务架构设计）

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

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

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

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

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

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

整个过程如下：

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

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

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

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

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

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

授权与调用过程如下：

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

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

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

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