公共平台服务治理与鉴权

聊一聊最近了解的公司服务治理平台,主要是思想,理念,而不是一种技术或框架。整个平台设计,融入了OAUTH2认证,融入了微服务思想,帮助公司各系统在复杂的IT架构下,实现一种便捷统一的调用方案,同时完成调用的管理(监控、注册、鉴权等)。架构

问题

一种思想或理念的出现,是否有价值,我认为主要在于它实际解决了哪些问题。基于这个价值观,咱们先看看,当一个公司有成百上千个系统时,会有哪些问题?
pi如:负载均衡

  1. 接口访问有没有鉴权?如何鉴权?这个话题很大,归根揭底就是,要让提供方知道调用方是谁(身份),而且赞成调用(受权)。
  2. 想看看系统间调用关系,得查代码或文档
  3. 某个系统异常,怎么评估影响范围?谁调了它,它调了谁?
  4. 某系统调用量如何?负载均衡以前需不须要流量控制?

解决问题

服务治理平台,目标就是把全部系统的全部接口,管理起来,对调用方进行鉴权,对提供方开放接口注册,运营来统一管理受权。最终,解决权限问题,监控系统间调用关系,实现公司级的服务治理。
框架

鉴权


开放平台,很重要的一个点,就是对访问进行权限控制。比较老的Basic Auth认证方式,在请求中加入用户名和密码,由服务端来进行鉴权。目前较通用的OAuth认证,经过Access Token完成受权与认证,具体不在详述,目前咱们使用OAUTH2。
其实,抽象来看,鉴权主要围绕两个问题,1,你是谁,2,赞成不一样意你调。
围绕这两个问题,咱们来捋一捋怎么设计,来完成这两个事:

  1. 首先,得有个系统,让调用方注册用户,申请访问接口等,暂且命名为portal
  2. 其次,提供方能够在平台注册本身的接口
  3. 平台管理人员,通常是运营同事,得有个系统能够查看注册接口、访问申请、注册用户、发布到公共平台等等,并完成对各类访问的受权,暂且命名为admin
  4. 另,既然使用了oauth2,就得有个取token的系统,暂且命名为oauth
  5. 最后,得有个对外的统一入口吧(即公共平台),暂且名为open

整个调用鉴权流程,以下:微服务

1. 调用方注册用户
2. protal返回用户id和secret
3. 管理员,审核用户(你是谁?)
4. 用户id经过审核
5. 经过审核的用户id申请相关访问资源
6. 管理员,受权资源访问(同不一样意你调?)
7. 资源申请经过
8. 根据用户id和secret到oauth取token
9. 到公共平台(open)访问你申请的资源,须要带上token
10. open对token进行鉴权

注册

提供方系统注册接口到公共平台,有不少种方式,目前,咱们主要使用两种方式:设计

  1. 系统内置平台注册SDK,在代码中实现接口注册
  2. 系统调用平台开放注册接口,经过HTTP请求完成注册。这种方式,提供方自己又成了公共平台的调用方,须要走一遍上面的鉴权过程=。=

整个注册流程比较简单,以下:code

管理

基于以上分析,有个提供方并在平台注册了接口,有了调用方并在平台得到了受权,那么整个管理平台的基本职能就能够推断出来:blog

  1. 服务注册、维护
  2. 消费维护、受权
  3. 应用申请受权、接口发布
  4. 系统运行态数据监控

总结

以上,仅仅是一个梗概,认识一个东西,我喜欢先看轮廓,在扣细节。
扣个细节,好比,受权单位若是是个接口的话,咱们公司将近2w个openAPI接口,受权起来比较琐碎,此时能够用分组来进行管理。如某个小系统的全部接口放到一个组里面,调用方经过申请组资源的访问,来完成对组内接口的访问。
在好比,受权时能够设置用户token的时效,过时token失效,须要从新取token。时效设置多久合适,你们能够另行分析。咱们系统是金融领域=。=token


以上来自天团运营总监:坤少
感谢观看,点个赞,我以为不过度。接口

相关文章
相关标签/搜索