- 问题
- 解决问题
- 鉴权
- 注册
- 管理
- 总结
聊一聊最近了解的公司服务治理平台,主要是思想,理念,而不是一种技术或框架。整个平台设计,融入了OAUTH2认证,融入了微服务思想,帮助公司各系统在复杂的IT架构下,实现一种便捷统一的调用方案,同时完成调用的管理(监控、注册、鉴权等)。
问题
一种思想或理念的出现,是否有价值,我认为主要在于它实际解决了哪些问题。基于这个价值观,我们先看看,当一个公司有成百上千个系统时,会有哪些问题?
pi如:
- 接口访问有没有鉴权?如何鉴权?这个话题很大,归根揭底就是,要让提供方知道调用方是谁(身份),并且同意调用(授权)。
- 想看看系统间调用关系,得查代码或文档
- 某个系统异常,怎么评估影响范围?谁调了它,它调了谁?
- 某系统调用量如何?负载均衡之前需不需要流量控制?
解决问题
服务治理平台,目标就是把所有系统的所有接口,管理起来,对调用方进行鉴权,对提供方开放接口注册,运营来统一管理授权。最终,解决权限问题,监控系统间调用关系,实现公司级的服务治理。
鉴权
开放平台,很重要的一个点,就是对访问进行权限控制。比较老的Basic Auth认证方式,在请求中加入用户名和密码,由服务端来进行鉴权。目前较通用的OAuth认证,通过Access Token完成授权与认证,具体不在详述,目前我们使用OAUTH2。
其实,抽象来看,鉴权主要围绕两个问题,1,你是谁,2,同意不同意你调。
围绕这两个问题,我们来捋一捋怎么设计,来完成这两个事:
- 首先,得有个系统,让
调用方注册用户,申请访问接口等
,暂且命名为portal - 其次,提供方可以在平台注册自己的接口
- 平台管理人员,一般是运营同事,得有个系统可以
查看注册接口、访问申请、注册用户、发布到公共平台等等
,并完成对各种访问的授权,暂且命名为admin - 另,既然使用了oauth2,就得有个取token的系统,暂且命名为oauth
- 最后,得有个对外的统一入口吧(即公共平台),暂且名为open
整个调用鉴权流程,如下:
1. 调用方注册用户
2. protal返回用户id和secret
3. 管理员,审核用户(你是谁?)
4. 用户id通过审核
5. 通过审核的用户id申请相关访问资源
6. 管理员,授权资源访问(同不同意你调?)
7. 资源申请通过
8. 根据用户id和secret到oauth取token
9. 到公共平台(open)访问你申请的资源,需要带上token
10. open对token进行鉴权
注册
提供方系统注册接口到公共平台,有很多种方式,目前,我们主要使用两种方式:
- 系统内置平台注册SDK,在代码中实现接口注册
- 系统调用平台开放注册接口,通过HTTP请求完成注册。这种方式,提供方本身又成了公共平台的调用方,需要走一遍上面的鉴权过程=。=
整个注册流程比较简单,如下:
管理
基于以上分析,有个提供方并在平台注册了接口,有了调用方并在平台获得了授权,那么整个管理平台的基本职能就可以推断出来:
- 服务注册、维护
- 消费维护、授权
- 应用申请授权、接口发布
- 系统运行态数据监控
总结
以上,仅仅是一个梗概,认识一个东西,我喜欢先看轮廓,在扣细节。
扣个细节,比如,授权单位如果是个接口的话,我们公司将近2w个openAPI接口,授权起来比较琐碎,此时可以用分组来进行管理。如某个小系统的所有接口放到一个组里面,调用方通过申请组资源的访问,来完成对组内接口的访问。
在比如,授权时可以设置用户token的时效,过期token失效,需要重新取token。时效设置多久合适,大家可以另行分析。我们系统是金融领域=。=
以上,感谢观看,点个赞,我觉得不过分。
原文地址:https://www.cnblogs.com/lknny/p/8831667.html