- 问题
- 解决问题
- 鉴权
- 注册
- 管理
- 总结
聊一聊最近了解的公司服务治理平台，主要是思想，理念，而不是一种技术或框架。整个平台设计，融入了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。时效设置多久合适，大家可以另行分析。我们系统是金融领域=。=
以上，感谢观看，点个赞，我觉得不过分。
