公共平台服务治理与鉴权

  • 问题
  • 解决问题
    • 鉴权
    • 注册
    • 管理
  • 总结

聊一聊最近了解的公司服务治理平台,主要是思想,理念,而不是一种技术或框架。整个平台设计,融入了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请求完成注册。这种方式,提供方本身又成了公共平台的调用方,需要走一遍上面的鉴权过程=。=

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

管理

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

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

总结

以上,仅仅是一个梗概,认识一个东西,我喜欢先看轮廓,在扣细节。

扣个细节,比如,授权单位如果是个接口的话,我们公司将近2w个openAPI接口,授权起来比较琐碎,此时可以用分组来进行管理。如某个小系统的所有接口放到一个组里面,调用方通过申请组资源的访问,来完成对组内接口的访问。

在比如,授权时可以设置用户token的时效,过期token失效,需要重新取token。时效设置多久合适,大家可以另行分析。我们系统是金融领域=。=

以上,感谢观看,点个赞,我觉得不过分。

原文地址:https://www.cnblogs.com/lknny/p/8831667.html

时间: 2024-11-08 13:16:47

公共平台服务治理与鉴权的相关文章

如何构建一个有效的服务治理平台

本文我们重点讨论如何构建一个有效的服务治理平台,话不多说,直接切入整体.构建服务治理平台基于“管理”,“度量”,“管控”三个层面统筹考虑安排.具体来讲,又可以分为六个层次来考虑问,分别是:服务管理流程体系,服务治理平台,服务治理核心架构,服务协议规范,服务支撑工具,服务运行环境.六个层面的具体关系如下图所示: 接下来我们分别来看一下每个层面的具体内容. 01 服务治理框架 当下无论对于什么样类型的服务治理核心框架,无论是开源还是自建,在功能层面相差不大,但技术实现却有所差别.但就落地实践而言,自

面试都在问的微服务、RPC、服务治理...一文帮你彻底搞懂!

单体式应用程序 与微服务相对的另一个概念是传统的「单体式应用程序」( Monolithic application ),单体式应用内部包含了所有需要的服务.而且各个服务功能模块有很强的耦合性,也就是相互依赖彼此,很难拆分和扩容. 说在做的各位都写过单体程序,大家都没意见吧?给大家举个栗子,刚开始写代码你写的helloworld程序就是单体程序,一个程序包含所有功能,虽然helloworld功能很简单. 单体应用程序的优点 开发简洁,功能都在单个程序内部,便于软件设计和开发规划. 容易部署,程序单

网关鉴权后下游统一filter获取用户信息

1. 场景描述 最近有点忙,在弄微服务nacos+springcloud gateway这块工作,以前只是简单应用,这次因为要对接10几个系统或者平台,还的鉴权,等后续稍微闲点了,把这块东西总结下. 刚好要写个文档,就一起发出来,场景是其他系统,gateway中鉴权成功后(过来的是加密token),会将个人信息信息会写到header中,比如手机号.姓名.部门等,为了方便下游系统获取信息,让写一个统一的filter,下游只需注入这个filter就能拿到用户信息,避免大家都的反复解析,还容易出错.

HTTP基本认证和JWT鉴权

一.HTTP基本认证 Basic Authentication--当浏览器访问使用基本认证的网站的时候, 浏览器会提示你输入用户名和密码. http auth的过程: · 客户端发送http请求 · 服务器发现配置了http auth,于是检查request里面有没有"Authorization"的http header · 如果有,则判断Authorization里面的内容是否在用户列表里面,Authorization header的典型数据为"Authorization:

使用ranger对kafka进行鉴权

使用ranger对kafka进行鉴权测试环境:ranger-kafka-plugin为0.6.3版本,kafka版本为kafka_2.10-0.10.1.1,且kafka broker为一个节点.一.Ranger对kafka进行权限控制,前提需要kafka开启kerberos认证(注意:若kafka不开启kerberos的话Ranger无法获取kafka相关操作的用户,进而无法完成鉴权操作)二.开启kerberos认证包括zookeeper开启kerberos认证,kafka开启zookeepe

物联网架构成长之路(56)-SpringCloudGateway+JWT实现网关鉴权

0. 前言 结合前面两篇博客,前面博客实现了Gateway网关的路由功能.此时,如果每个微服务都需要一套帐号认证体系就没有必要了.可以在网关处进行权限认证.然后转发请求到后端服务.这样后面的微服务就可以直接调用,而不需要每个都单独一套鉴权体系.参考了Oauth2和JWT,发现基于微服务,使用JWT会更方便一些,所以准备集成JWT作为微服务架构的认证方式. [https://www.cnblogs.com/wunaozai/p/12512753.html] 物联网架构成长之路(54)-基于Naco

apigw鉴权分析(1-4)新浪微博开放平台 - 鉴权分析

一.访问入口 http://open.weibo.com/wiki/%E6%8E%88%E6%9D%83%E6%9C%BA%E5%88%B6%E8%AF%B4%E6%98%8E 微博开放接口的调用,如发微博.关注等,都是需要获取用户身份认证的. 目前微博开放平台用户身份鉴权主要采用的是OAuth2.0. 另外,为了方便开发者开发.测试自己的应用,我们还提供了Basic Auth的身份鉴权方式,但Basic Auth仅适用于应用所属的开发者自己调用接口. OAuth2.0概述 OAuth2.0较1

微服务架构中的安全认证与鉴权

转载:http://www.bootdo.com/blog/open/post/125 从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验.为了适应架构的变化.需求的变化,身份认证与鉴权方案也在不断的变革.面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的鉴权方案?本文将会为大家阐述微服务架构下的安全认证与鉴权方案. 单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大

开放平台鉴权以及OAuth2.0介绍

OAuth 2.0 协议 OAuth是一个开发标准,允许用户授权第三方网站或应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方网站或分享他们数据的内容. OAuth 2.0不兼容1.0. 协议的参与者 RO (resource owner): 资源所有者,对资源具有授权能力的人. RS (resource server): 资源服务器,它存储资源,并处理对资源的访问请求. Client: 第三方应用,它获得RO的授权后便可以去访问RO的资源. AS (authoriz