[[396671]]

對于安裝部署來說，涉及的流程較為繁雜，而且隨著后續的維護管理，流程會產生變動，在以往的代碼層維護中，會容易產生難以適配，流程不穩定的情況，導致安裝部署的交付效率和預期存在較大的差距。

已有的流程如下：

如上流程存在以下的問題，相信在很多中小公司都會或多或少有所涉及。

整體表現

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.

任務執行層主要為通用任務的實現，其中流程任務的配置明細是基于應用層的數據配置和流程任務配置結合而成，形成任務明細的注冊，如在提交部署請求的時候，就是任務明細的執行計劃。

流程任務明細日志維護流程任務明細的執行日志和狀態，如果任務執行成功，則會更新相應的任務明細記錄狀態，反之如果失敗，則需要啟動重試機制。

本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。