去哪儿内部有一个应用中心的系统，其实即使在内部可能很多开发人员都不知道这个东西具体是干啥的，估计都以为是：哦，那个东西啊，就是你要部署一个应用得去那申请一下，获得一个token文件，然后放你应用里就行了；另外就是其他一些公共系统的权限你要去这里配置。

其实，应用中心在我们心目中占据很高的地位，寄托着我们对容器化的期盼。那么我就来谈谈当初是怎么定位应用中心的。

时间应该回到2013年，当时内部已经有几款中间件了，但是各个中间件基本上没有什么关联，各自管理自己的数据，权限，关系等等。但是这种方式很不方便，这其中最严重的的是调度任务管理。我们一个应用可能会跑很多任务，对任务的编辑，设置和运行都需要相应的权限，一个应用少数几个任务，多数上百的任务，我们总不能给每个任务都定义一遍权限。这个时候我们想，应该以应用的维度来定义这个权限关系，并且使用人员可能也期望一下子就能看到一个应用下有哪些任务。那么首先就得解决定义一个应用，其实就是给应用命个名。于是我们就让所有使用调度任务的应用要配置一个qunar-app.properties的文件，这个文件里有个应用的唯一标识。这就是应用中心的前身，此时我们还没有一个专门的系统来管理这些应用，应用名字也是开发随便写在qunar-app.properties这个文件中，只是启动后任务调度系统会做应用名唯一性检测。

在调度任务平台之后，我们紧接着启动了配置中心的开发工作。这个时候我们发现配置中心也需要一个应用管理的东西。而且其作用与在调度任务里的极其类似。这个时候，我们意识到应该有一个独立的系统专门来负责给应用命名这件事(当初我们真的只是想给应用命名和管理应用相关的权限)。

于是一个单独的叫应用中心的系统开发出来了，只有两个界面：

填一些信息申请一个应用，然后你可以下载一个加密的token文件

编辑谁是这个应用的负责人和相关开发。负责人和相关开发具备对应用的不同的权限。

其时，配置中心的开发也进入了尾声，但是我们突然想起一件事情：配置应该是非常关键的数据，有些甚至是非常保密的敏感信息，不应该任何应用都能拿到别的应用的配置。那么我们就需要一套机制来确认获取配置的应用是不是有权限获取这个配置。那么这实际上涉及两个问题：

你是谁

你有没有权限操作。

对于第2条，这是配置中心自己业务逻辑。但是对于第1条，我们不能相信你说你是谁你就是谁，这其实就是数字签名要干的事情。这个时候应用中心正式登上了历史的舞台。

应用启动的时候，基础组件会将应用中心下发的加密token，pid等信息送到应用中心，应用中心收到这些信息首先会验证token的合法性(其实就是用应用中心自己的密钥解密token)，验证合法性后会从token里拿到应用名，然后应用中心会验证当前请求的client ip是否属于这个应用(所以得有地方维护ip与app name的关系)，验证通过后应用中心会用自己的私钥将应用名，client ip, pid以及当前时间加密返回给基础组件，我们称之为server token(如果验证没通过应用中心不会下发server token，对应的应用会启动失败)。

当应用需要去配置中心拿配置的时候，会带上此server token。配置中心拿到此server token后会调用基础组件解密token。基础组件会从应用中心拿到公钥，然后使用公钥解密该server token。而server token里可以拿到ip，然后将此ip与当前请求的client ip对比，如果是相同则server token有效，server token里还可以拿到app name，这个就回答了你是谁的问题了。

我们通过应用中心对应用的身份验证方案解决了配置中心对配置保护的问题。但不仅如此，这个问题其实可以进一步抽象：应用对资源的访问(配置也是一种资源)。应用对资源的访问需要授权，而授权就需要身份鉴别。比如应用访问受保护的接口或服务，应用发送或消费消息，应用访问数据库等。

在没有应用中心之前，我们的实现方式都是使用ip进行限制。比如假设有个获取用户敏感信息的接口，我们只允许哪些应用可以访问，没有应用中心，我们只有设置ip白名单，而设置ip白名单是非常原始落后的方式：系统扩容，新增了ip，发现没有添加白名单导致故障的事情并不鲜见。究其原因其实就是ip是一个物理而原始的概念，特别是进入容器化时代后，这个概念会不断地的弱化。

于是基于应用中心对应用的身份鉴别，我们将对资源的访问从物理的ip限制转换为逻辑的app name对资源的访问。比如访问一个接口，我们会带上这个server token，然后验证server token取得app name，然后对app name进行验证。

以上就是应用中心最主要的作用了，另外我们还将一些应用的基本信息暴露也放到应用中心里：

应用使用了哪些包，包的版本。

应用的启动停止时间。

应用的部署路径，jdk版本等

应用的日志收集状况等

前面两条其实也是无奈的选择，在我们组内部有一句话：不要相信用户告诉你什么，只相信你看到了什么。因为在用户咨询问题时我们一遍遍确认他们使用了什么包，是不是这个时候有重启，但一次又一次发现用户给的信息并不正确，所以只好自己收集这些信息。

总结

那么最后总结起来，应用中心是这么样子的一个系统：对应用，人和资源三者关系的维护。

应用

我是谁，我的一些信息。谁是我的owner，我访问了哪些资源

人

我负责哪些应用

资源

哪些应用可以访问我