公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2019-01-16 23:56:28 · 原文链接

这是学习笔记的第 1861篇文章

关于建设PaaS平台，不可避免要谈到一个场景是资源申请，这是一个太常规的业务场景了。看起来需求简单，实际上是一个较为复杂的业务流程。

首先对于使用方而言，我要申请一个数据库，那么必然不希望先申请一台服务器，然后我们继续申请数据库实例，而是一个完整的需求：申请数据库，至于是哪台服务器，这个使用方其实是不关心的。

从系统建设和云平台的设计来看，资源的申请是有一些门道的，我们需要把数据库层面的一些思路糅合进去，比如我们申请的环境是一套，灾备是默认包含的，也就意味着申请服务器，至少是两台。如果要考虑跨机房容灾，再加一台，如果考虑读写分离，还可以再加，考虑分库分表，这个数量会更大一些。

下面是一个现在使用中的一个资源申请模板。

可以额外关注下标红的部分，其实对于业务方使用来说，他们需要关注申请的服务器数量，有了数量的考量，加入了成本考量，整个审批就是有理有据了。

这样一个前端页面的单子到了运维系统之后，会把有的单子拆分为多个，大的角度会分为系统资源单据和数据库单据。如果申请了3台服务器，那么至少会生成6个子工单，3个子工单给系统运维平台，3个工单留给DBA侧。

当我们提交资源申请时，会把资源配置信息推送到系统运维平台，然后他们就可以负责资源初始化了。

初始化完成之后，通过接口的方式来完成系统的内部交互，对于使用方来说是一个统一的接口。

完成了资源的初始化，我们就会收到回调的接口，得到初始化之后的IP地址等信息，就可以完成后续DBA侧的部署任务了，整体会分为实例部署和高可用部署两类任务。

整个资源申请的流程图如下，为了提高资源使用率，会在各个环节设置一个提醒模块，比如开始资源申请，会告知业务方进入了这个阶段，告知系统组知晓这个单据的信息。在他们完成平台化操作之后，就可以实现持续交付，我们通过提醒告知的方式来继续后续的流程操作。

整个一个流程下来，对于业务同学来说，是一个相对统一，但是流程和公有云的方式又略有差异。