六个人如何运维一万台服务器？(5)

这样 OPS 就不用参与太多，他们可以自动申请主机和账号。

最后我们做了一个界面，把这个界面暴露给开发人员，开发人员可以去申请主机、申请账号。

通过应用树、主机管理、主机申请、账号申请这四个平台做了闭环，核心是应用树节点，应用树节点把四个部分串联起来。

应用树节点有什么问题，我们会改变它，比如刚开始有个 portal 应用放在 OPS 开发下，有一天发现这个放的位置不太对，需要直接放在 OPS 下面就可以了，这样就需要把 portal 从运维开发移动到 OPS 下面。

还有一个， portal 随着业务增长，应用越来越大，需要拆分成几个部分，比如需要拆分成 portal-web 和 portal-api ，这种树节点改变会导致什么？

我们每个系统记录的都是应用树节点，每个应用树节点的改变各个系统都需要去同步，这就相当于在一个分布式系统里有一个有状态的模块，就是应用树节点这个模块。

它是有状态的，有状态就导致我们分布式比较困难，我们想把应用树节点推广到更多的系统中，那就会非常困难，就会不断面临同步的问题。

这个问题怎么解决，比如说对于一个普通的居民来说，怎么在各个系统之间共享数据，比如我一个人怎么在公安系统、在户籍系统、在银行系统等等各个系统之间，怎么样共享我的信息。

现实中就有一个非常好的实践，那就是使用身份证，身份证有唯一的 ID，通过这样一个唯一的 ID，就可以标识这个应用，并且这个 ID 永远不会改变。

我们怎样去找到这样一个 ID，第一个方案，用数据库里的自增 ID 或者 UUID 来标识应用。

这样可以保证应用 ID 唯一且不改变，但是因为自增 ID 和 UUID 在文字上没有明确意义，我们开发人员拿到这个 ID 不便于记忆，也不便于沟通。

假如要用自增 ID 或 UUID ，需要用另外一个系统去专门看我有多少这样的 ID，先找到这个 ID，再和其他系统进行交互、沟通，非常不方便。

第二个方案，借鉴身份证，用数字，比如 110 代表北京，后面代表县区，代表自己的出生日期。

借鉴身份证 ID，我们使用了这样一个叫 Appcode 的方案来标识应用。Appcode 基本上以下滑线分割的，第一个是应用所在的部门，第二个是应用的描述，这个层级也可以非常长。

用这样一个 Appcode 去代替应用数节点，既能保证唯一且不可改变，便于大家记忆，沟通也比较方便，我们最后选的是第二套方案。

（编辑：ASP站长网）