对于安装部署来说，涉及的流程较为繁杂，而且随着后续的维护管理，流程会产生变动，在以往的代码层维护中，会容易产生难以适配，流程不稳定的情况，导致安装部署的交付效率和预期存在较大的差距。
已有的流程如下：
如上流程存在以下的问题，相信在很多中小公司都会或多或少有所涉及。
整体表现
1) 在代码实现中，流程相对臃肿，偏硬编码实现，流程改动风险高
2) 资源申请的填写信息过多，信息不够简洁，对于业务侧不够友好
3) 目前的资源流程较为复杂，属于定制化开发，如果在其他流程中有类似的配置，代码实现复用度低
资源审批
4) 资源交付时间比预期要长，一方面体现在审批环节，另一方面体现在资源交付的试错成本高
5) 测试环境的数据库资源申请目前在工单中不支持，需要人工引导创建数据库的流程
主机资源池筛选
6) 在资源交付中，如果存在工单中不匹配的资源配置，则无法交付，需要重新修改工单单据
7) 主机资源池的环节目前是人为控制，需要手工录入主机信息，没有资源池的阈值管理和资源预申请流程
数据库资源交付
8) 如果流程执行失败，重试流程检测相对单薄，需要手工做一些额外的处理工作
9) 流程过长，某一环节出现错误的概率较高，导致整个部署的出错概率偏高
10) 数据库新版本的接入，使得原本的模式难以兼容，新环境部署目前多采用手工模式部署
11) 如果申请单实例，一主两从，集群环境，则无法支持和适配。
数据库权限交付
12) 资源交付后的权限交付处理，可能在业务资源申请的时候还没有明确，所以后期改动的概率较高，而如果手工申请，则需要提交自动化上线协作单(建库)，权限申请协作单(需要再一轮审批)，建表(自动化上线协作单或者对象操作协作单)，对于流程不够熟悉的开发人员，流程会显得复杂，不够清晰。
对此相应的改进策略和方向如下，简而言之是希望让资源的预申请和预配置这些占比超过90%的基础工作先做好，业务提交申请的时候DBA只需要额外处理那10%的一部分配置管理。
整体表现
1) 在代码实现中，流程相对臃肿，偏硬编码实现，流程改动风险高
改进策略：基于配置化的流程编排实现，在设计初期就考虑流程的变化，通过多流程配置和编排来实现不同业务场景的支持，如对于单实例，一主一从，一主两从的支持，流程相似但不同，通过配置不同的流程来实现多类需求
2) 资源申请的填写信息过多，信息不够简洁，对于业务侧不够友好
改进策略：优化目前的前端配置，去除不必要的信息和必填项，减少至少20%的填写项。
3) 目前的资源流程较为复杂，属于定制化开发，如果在其他流程中有类似的配置，代码实现复用度低
改进策略：对于流程编排和任务配置，可以通过通用化配置和通用服务来实现，提高代码复用和稳定性建设。
资源审批
4) 资源交付时间比预期要长，一方面体现在审批环节，另一方面体现在资源交付的试错成本高
改进策略：
对于测试环境的资源交付，其实就是数据库交付，可以简化流程实现
对于开发环境的资源交付，可以直接去除审批环节，后期通过虚拟化多租户的模式来实现
对于线上环境的资源交付，目前仍然保留已有的审批环节，在资源成本方面的体现有待商榷
5) 测试环境的数据库资源申请目前在工单单据中不支持，需要人工引导创建数据库的流程
改进策略：如上
主机资源池筛选
6) 在资源交付中，如果存在工单中不匹配的资源配置，则无法交付，需要重新修改工单的数据
改进策略：资源池的配置可以实现差异化，但是需要考虑适配性。资源配置按照优先可扩容的标准来实现，比如业务申请8C8G的数据库资源，目前资源池存在5个实例资源：
① 2个 4C4G, 2个8C8G,1个8C16G，则可以按照2个8C8G的规格来交付
② 2个 4C4G, 1个8C8G,1个8C16G，则可以按照1个8C8G,1个8C16G的规格来交付，其中8C16G优先绑定主库
③ 2个 4C4G, 1个8C8G,2个8C16G，则可以按照2个8C16G的规格来交付
7) 主机资源池的环节目前是人为控制，需要手工录入主机信息，没有资源池的阈值管理和资源预预申请流程
改进策略：在资源快速交付层面，可以把资源层拆分为主机资源池和数据库实例资源池，通过主机资源池和实例资源池来分层建设，其中实例资源池仅保留可用的资源，资源被使用后，需要归档到资源历史明细中，而主机资源池需要和系统部通过流程的方式来对接，对此主机资源池需要考虑实现阈值告警，并提供必要的接口供系统部回调。
数据库资源交付
8) 如果流程执行失败，重试流程检测相对单薄，需要手工做一些额外的处理工作
9) 流程过长，某一环节出现错误的概率较高，导致整个部署的出错概率偏高
10) 数据库新版本的接入，使得原本的模式难以兼容，新环境部署目前多采用手工模式部署
11) 如果申请单实例，一主两从，集群环境，则无法支持和适配
改进策略：目前通过通用流程来配置任务明细，对于任务对象，需要考虑流水编号的全局唯一性
数据库权限交付
12) 资源交付后的权限交付处理，可能在业务资源申请的时候还没有明确，所以后期改动的概率较高，而如果手工申请，则需要提交自动化上线协作单(建库)，权限申请协作单(需要再一轮审批)，建表(自动化上线协作单或者对象操作协作单)，对于流程不够熟悉的开发人员，流程会显得复杂，不够清晰。
改进策略：对于资源申请单据的处理，可以适度提供更灵活的支持模式，尽可能减少多工单的提交方式。
对于通用任务流程的整体设计，主要是按照如下的方式分层的。
图片
在更细节的部分涉及会少一些，比如任务依赖，超时处理等，主要还是以基本的流程执行模式为主。
其中编排层实现流程的编排，流程任务的配置，此处涉及基本信息，不涉及具体的实现细节
应用层为业务独立的数据模型，需要在业务层定义全局唯一的批次号(batch_no),也可以理解为全局唯一的对象ID.
任务执行层主要为通用任务的实现，其中流程任务的配置明细是基于应用层的数据配置和流程任务配置结合而成，形成任务明细的注册，如在提交部署请求的时候，就是任务明细的执行计划。
流程任务明细日志维护流程任务明细的执行日志和状态，如果任务执行成功，则会更新相应的任务明细记录状态，反之如果失败，则需要启动重试机制。
本文转载自微信公众号「杨建荣的学习笔记」，可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。
