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