公共平台服务治理与鉴权

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

聊一聊最近了解的公司服务治理平台，主要是思想，理念，而不是一种技术或框架。整个平台设计，融入了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。时效设置多久合适，你们能够另行分析。咱们系统是金融领域=。=

---

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