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

这样 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 去取代应用数节点，既能担保独一且不行改变，便于各人影象，雷同也较量利便，我们最后选的是第二套方案。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!