聊一聊最近了解的公司服务治理平台,主要是思想,理念,而不是一种技术或框架。整个平台设计,融入了OAUTH2认证,融入了微服务思想,帮助公司各系统在复杂的IT架构下,实现一种便捷统一的调用方案,同时完成调用的管理(监控、注册、鉴权等)。架构
一种思想或理念的出现,是否有价值,我认为主要在于它实际解决了哪些问题。基于这个价值观,咱们先看看,当一个公司有成百上千个系统时,会有哪些问题?
pi如:负载均衡
服务治理平台,目标就是把全部系统的全部接口,管理起来,对调用方进行鉴权,对提供方开放接口注册,运营来统一管理受权。最终,解决权限问题,监控系统间调用关系,实现公司级的服务治理。
框架
调用方注册用户,申请访问接口等
,暂且命名为portal查看注册接口、访问申请、注册用户、发布到公共平台等等
,并完成对各类访问的受权,暂且命名为admin整个调用鉴权流程,以下:微服务
1. 调用方注册用户 2. protal返回用户id和secret 3. 管理员,审核用户(你是谁?) 4. 用户id经过审核 5. 经过审核的用户id申请相关访问资源 6. 管理员,受权资源访问(同不一样意你调?) 7. 资源申请经过 8. 根据用户id和secret到oauth取token 9. 到公共平台(open)访问你申请的资源,须要带上token 10. open对token进行鉴权
提供方系统注册接口到公共平台,有不少种方式,目前,咱们主要使用两种方式:设计
整个注册流程比较简单,以下:code
基于以上分析,有个提供方并在平台注册了接口,有了调用方并在平台得到了受权,那么整个管理平台的基本职能就能够推断出来:blog
以上,仅仅是一个梗概,认识一个东西,我喜欢先看轮廓,在扣细节。
扣个细节,好比,受权单位若是是个接口的话,咱们公司将近2w个openAPI接口,受权起来比较琐碎,此时能够用分组来进行管理。如某个小系统的全部接口放到一个组里面,调用方经过申请组资源的访问,来完成对组内接口的访问。
在好比,受权时能够设置用户token的时效,过时token失效,须要从新取token。时效设置多久合适,你们能够另行分析。咱们系统是金融领域=。=token
以上来自天团运营总监:坤少
感谢观看,点个赞,我以为不过度。接口