平臺設計中腳本管理的示例分析

這篇文章將為大家詳細講解有關平臺設計中腳本管理的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

腳本管理是在元數據構建的基礎上的，比如對MySQL/Redis DBA來說，操作的基本粒度是數據庫實例，那么我們就可以完全按照IP+端口來構建匹配到一個對應的實例，至于硬件，是否虛擬化，配置的明細，這些我們可以通過信息下鉆得到更細維度的信息，但是對于我們的操作粒度來說，實例已經足夠。

所以有了基礎的元數據，要細化并且和管理工作結合起來，才有了充分條件。

我在構建基礎平臺的時候，隨著基礎功能的增加，越來約感覺到了復雜度和維度需要簡化，細化。元數據的信息可以分為多個菜單，不同的功能之間有關聯關系來指定，所以在MTV的Django框架中，我配置了不少的url來支持前期的工作，但是如果是MySQL細節的工作，這個事情要這么做起來，明顯會有一個瓶頸，主要的感覺就是要配置一連串的功能，然后通過url和view把彼此連接起來。

比如MySQL方向，我寫了30個腳本，那么在這種方式下我至少得配置30+的url信息，和一連串的邏輯實現。

其實對應用來說，就是腳本調用，這樣的方式就有些笨重了。所以在腳本管理中，我期望做幾件事情，能夠改進。

1. 為了能夠快速平滑的接入，腳本管理中的腳本語言其實不是瓶頸，都應該全面支持，比如使用perl,使用shell,SQL等，如果腳本本身很穩定，那么完全可以接入進來，總之就是這個環節要開放，不一定要完全是python腳本。平臺的開發功能是python,但是腳本管理不一定是python。

2. 在腳本管理中，腳本和菜單如何映射，這是個關鍵，我們可以把腳本屬性參數化，比如腳本名，腳本的類型等這些也是作為一種元數據來管理。這樣就會是一個統一的接口的方式，至于具體的連接方式，比如樹形結構或者其他可行的方式。

3. 平臺方向上可以提前規劃，但是對于開發和業務同學來說，無需配置大量的url，就可完成一些基礎或者復雜功能的擴展。

4. 現有的基礎架構和功能，腳本化對于它來說也是起到促進作用。需要提前規劃和已有的基礎功能是否有可銜接的地方。

5. 腳本管理支持文件的上傳和腳本內容編輯。這個就是偏具體技術的實現了，比如ACE編輯器。

6. 腳本的參數管理，有的腳本是1個參數，有的是2個，其實對于后臺來說，就是拿到腳本來處理，怎么做標識和匹配。

7. 腳本管理中，有些腳本是通用的，如果希望能夠持續使用，必須要提前規劃好范圍和類別。有些腳本是具體的一些業務場景需要的，需要明確需要的參數和權限。

8. 腳本不光用通用和私有的范圍，而且還需要細化到具體的作用域范圍。

如果來說下流程管理。下面是我之前規劃的餓一個數據庫方向鎖要做的事情和發力的方向，但是這樣是通過流程的方式把這些貫穿起來，這個事情就好辦多了。

比如備份恢復的工作，我們分為全量備份恢復，增量備份恢復，binlog備份恢復，這個工作如果和高可用方案連接起來就會更有意義了，就可以實現一個所謂的自動化流程。

關于“平臺設計中腳本管理的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。