聊一聊最近了解的公司服务治理平台，主要是思想，理念，而不是一种技术或框架。整个平台设计，融入了OAUTH2认证，融入了微服务思想，帮助公司各系统在复杂的IT架构下，实现一种便捷统一的调用方案，同时完成调用的管理（监控、注册、鉴权等）。
问题一种思想或理念的出现，是否有价值，我认为主要在于它实际解决了哪些问题。基于这个价值观，我们先看看，当一个公司有成百上千个系统时，会有哪些问题？
pi如：
接口访问有没有鉴权？如何鉴权？这个话题很大，归根揭底就是，要让提供方知道调用方是谁（身份），并且同意调用（授权）。
想看看系统间调用关系，得查代码或文档
某个系统异常，怎么评估影响范围？谁调了它，它调了谁？
某系统调用量如何？负载均衡之前需不需要流量控制？
解决问题服务治理平台，目标就是把所有系统的所有接口，管理起来，对调用方进行鉴权，对提供方开放接口注册，运营来统一管理授权。最终，解决权限问题，监控系统间调用关系，实现公司级的服务治理。
开放平台，很重要的一个点，就是对访问进行权限控制。比较老的Basic Auth认证方式，在请求中加入用户名和密码，由服务端来进行鉴权。目前较通用的OAuth认证，通过Access Token完成授权与认证，具体不在详述，目前我们使用OAUTH2。
其实，抽象来看，鉴权主要围绕两个问题，1，你是谁，2，同意不同意你调。
围绕这两个问题，我们来捋一捋怎么设计，来完成这两个事：
首先，得有个系统，让调用方注册用户，申请访问接口等，暂且命名为portal
其次，提供方可以在平台注册自己的接口
平台管理人员，一般是运营同事，得有个系统可以查看注册接口、访问申请、注册用户、发布到公共平台等等，并完成对各种访问的授权，暂且命名为admin
另，既然使用了oauth2，就得有个取token的系统，暂且命名为oauth
最后，得有个对外的统一入口吧（即公共平台），暂且名为open
整个调用鉴权流程，如下：
提供方系统注册接口到公共平台，有很多种方式，目前，我们主要使用两种方式：
系统内置平台注册SDK，在代码中实现接口注册
系统调用平台开放注册接口，通过HTTP请求完成注册。这种方式，提供方本身又成了公共平台的调用方，需要走一遍上面的鉴权过程=。=
整个注册流程比较简单，如下：
基于以上分析，有个提供方并在平台注册了接口，有了调用方并在平台获得了授权，那么整个管理平台的基本职能就可以推断出来：
服务注册、维护
消费维护、授权
应用申请授权、接口发布
系统运行态数据监控
总结以上，仅仅是一个梗概，认识一个东西，我喜欢先看轮廓，在扣细节。
扣个细节，比如，授权单位如果是个接口的话，我们公司将近2w个openAPI接口，授权起来比较琐碎，此时可以用分组来进行管理。如某个小系统的所有接口放到一个组里面，调用方通过申请组资源的访问，来完成对组内接口的访问。
在比如，授权时可以设置用户token的时效，过期token失效，需要重新取token。时效设置多久合适，大家可以另行分析。我们系统是金融领域=。=
以上，感谢观看，点个赞，我觉得不过分。