你好！ 我們是“託管技術”，5 年前推出 — 第一個專門為開發人員創建的 vds 託管。 我們努力讓它像 DigitalOcean 一樣方便，但在俄羅斯有俄羅斯支持、支付方式和服務器。 但 DigitalOcean 不僅是可靠性和價格，它還是一種服務。
ISPsystem 的軟件原來是一根繩子，將我們的手綁在通往酷服務的路上。 三年前，我們使用了 Billmanager 計費和 VMmanager 服務器控制面板，並很快意識到如果沒有我們自己的控制面板幾乎不可能提供良好的服務。
ISP 系統如何扼殺便利性
蟲子
我們無法自己修復錯誤 - 每次我們不得不寫信給別人的支持並等待。 任何問題的解決都需要第三方公司的響應。
ISP 系統支持響應正常，但僅在幾次發布後才出現修復，而且並不總是，也不是全部。 有時，關鍵錯誤會在數週內得到糾正。 我們不得不向客戶保證，道歉並等待 ISPsystem 修復錯誤。
停機威脅
更新可能會產生不可預測的停機時間，從而引發新的錯誤。
每次更新都是一次抽獎：我不得不掩蓋賬單並向更新之神做出犧牲——有幾次更新導致停機 10-15 分鐘。 我們的管理員此時正坐視著他們——我們永遠不知道停機時間會持續多久，也無法預測 ISPsystem 何時決定發布新的更新。
在第五代，Billmanager 變得更好了，但為了獲得必要的功能，我不得不安裝一個 beta，它已經每週更新一次。 如果出現問題，我必須授予其他開發人員訪問權限，以便他們可以修復某些問題。
不方便的面板界面
一切都被分成不同的面板，並從不同的地方進行控制。 例如，客戶通過 Billmanager 付款，他們必須在 VMManager 中重新啟動或重新安裝 VDS。 我們的員工還必須在窗口之間切換以幫助客戶，檢查他的服務器上的負載，或者查看他使用的是什麼操作系統。
這樣的界面需要時間——我們和我們客戶的。 像DigitalOcean這樣的便利性，在這種情況下是毫無疑問的。
API 更新頻繁，生命週期短
我們編寫了自己的插件 - 例如，帶有 VMManager 中沒有的額外支付方式的插件。
近年來，VMManager 的生命週期相對較短，並且在新版本中，API 中的變量或函數的名稱可以任意更改 - 這破壞了我們的插件。 對舊版本的支持很快就被淘汰了，必須進行更新。
無法修改
更準確地說，這是可能的，但效率極低。 許可證限制不允許您更改源代碼，您只能編寫插件。 最大插件 - 一些菜單項，一步一步的嚮導。 ISPsystem 專為多功能性而設計，但我們需要專門的解決方案。
因此，編寫我自己的面板的決定已經成熟。 我們設定了目標：
- 快速響應錯誤、錯誤並能夠自行修復它們，而無需讓客戶等待。
- 根據工作流程和客戶需求自由修改界面。
- 通過簡潔易懂的設計提高可用性。
我們開始開發。
新面板架構
我們有一個自給自足的開發團隊，所以我們自己編寫了面板。
主要工作由三位工程師完成——技術總監 Sergey 提出架構並編寫服務器代理，Alexey 負責計費，前端由我們的前端工程師 Artysh 組裝。
第 1 步：服務器代理
服務器代理是一個管理庫的python web服務器 ，這反過來支配 .
agent通過libvirt庫管理服務器上的所有服務：創建、停止、刪除vds、安裝操作系統、更改參數等。 在本文發表時，這些功能有四十多種，我們會根據任務和客戶的需求對其進行補充。
理論上，libvirt 可以直接從計費中控制，但這需要太多額外的代碼，我們決定將這些功能在代理和計費之間分開——計費只是通過 JSON API 向代理髮出請求。
代理是我們做的第一件事，因為它不需要任何界面，並且可以直接從服務器控制台對其進行測試。
服務器代理給了我們什麼： 出現了一個簡化每個人生活的層——計費不需要發送一大堆命令，而只需要提出一個請求。 代理將執行所需的一切：例如，它將分配磁盤空間和 RAM。
步驟 2. 計費
對於我們的開發人員 Alex 來說，這不是第一個控制面板 - Alex 長期從事託管工作，因此他大致了解客戶需要什麼以及託管商需要什麼。
我們將我們之間的計費稱為“控制面板”：它不僅包含資金和服務，還包含它們的管理、客戶支持等等。
要從 ISPSystem 軟件切換，必須為客戶完全保留以前的功能，將用戶的所有財務行為從舊計費轉移到新計費，以及它們之間的所有服務和連接。 我們研究了當前產品中的內容，然後是競爭對手的解決方案，主要是 DO 和 Vultr。 我們研究了劣勢和優勢，收集了使用 ISPsystem 舊產品的人員的反饋。
新的計費使用了兩個棧：經典的 PHP、MySQL（未來計劃切換到 PostgreSQL），後端框架為 Yii2，前端為 VueJS。 堆棧彼此獨立工作，由不同的人開發，並使用 JSON API 進行通信。 為了發展，現在我們使用 и 來自 JetBrains，非常喜歡它們（嘿伙計們！）
該面板基於模塊化設計：支付系統模塊、域名註冊商模塊或 SSL 證書模塊等。 您可以輕鬆添加新功能或刪除舊功能。 擴展的基礎是在架構上奠定的，包括在相反的方向，“朝向硬件”。
我們得到了什麼：我們可以完全控制的控制面板。 現在，錯誤可以在數小時而不是數週內得到修復，並且新功能是根據客戶的要求而不是 ISPSystem 的要求來實現的。
第三步界面
該界面是我們團隊的創意。
首先，我們研究瞭如果我們在不從根本上改變界面中的任何內容的情況下通過 ISPsystem API 創建一個附加組件會發生什麼。 結果馬馬虎虎，我們決定一切從頭開始。
我們認為最主要的是讓界面符合邏輯，採用乾淨簡約的設計，然後我們會得到一個漂亮的面板。 Megaplan 中討論了元素的位置，用戶現在在控制面板中看到的界面將逐漸誕生。
計費頁面的設計是最先出現的，因為我們已經為ISPsystem做了支付插件。
前端
他們決定使該面板成為一個 SPA 應用程序——對資源要求不高且數據加載速度快。 我們的前端 Artysh 決定用 Vue 來寫——那時候 Vue 剛剛出現。 我們假設該框架會像 React 一樣動態發展，一段時間後 Vue 社區會發展壯大並且會出現大量的庫。 我們押注於 Vue 並且並不後悔 - 現在只需很少的時間就可以將已經在後端編程的新功能添加到前端。 我們將在另一篇文章中詳細介紹前端面板。
將前端連接到後端
前端通過推送通知連接到後端。 我不得不努力工作並編寫自己的處理程序，但現在頁面上的信息幾乎是即時更新的。
發生了什麼： 面板界面變得更加簡單。 我們讓它具有自適應性，快速加載讓您甚至可以在起飛前的最後幾分鐘通過手機使用它，而無需安裝單獨的應用程序來使用面板。
Step 4. 測試遷移方案
當一切啟動並通過第一個測試時，遷移問題就出現了。 首先，我們安裝了計費並開始使用服務器代理測試其操作。
然後我們編寫了一個簡單的腳本，將數據庫從舊賬單轉移到新賬單。
我不得不測試和重新檢查幾乎所有的東西，因為數據是從三個舊數據庫合併到一個新數據庫中的：Billmanager、VMmanager 和經理的 IPmanager。 也許測試遷移是我們在開發新面板的過程中遇到的最困難的事情。
重新檢查後，我們關閉了舊帳單。 最後的數據遷移是一個非常麻煩的時刻，但是，感謝上帝，它在幾分鐘內就完成了，而且沒有出現明顯的問題。 我們在一周內修復了一些小錯誤。 大部分時間都花在測試發生了什麼上。
然後我們將新面板的地址和賬單發送給客戶，並進行了重定向。
概括如下： 它還活著！
好結局
從我們軟件工作的最初幾個小時開始，我們就感受到了過渡帶來的所有樂趣。 代碼完全是我們的，具有方便的體系結構，界面簡潔且合乎邏輯。
新面板上線後的第一次審核
我們在 2017 年新年前夕的 XNUMX 月啟動了過渡流程，當時負載最輕，以使客戶更容易過渡 - 幾乎沒有人在假期前夕工作。
切換到我們的系統時，我們得到的主要好處（除了一般的可靠性和便利性之外）是能夠為關鍵客戶快速添加功能 - 成為他們的面孔，而不是他們的屁股。
接下來是什麼？
我們在增長，數據量、客戶、客戶數據也在增長。 我必須向後端添加一個 Memcached 服務器和兩個具有不同任務的隊列管理器。 前端有緩存和自己的隊列。
當然，隨著產品的發展和變得越來越複雜，我們仍然有冒險經歷，例如當我們添加 HighLoad 時。
在下一篇文章中，我們會告訴你 Hi-CPU 關稅是如何推出的：關於硬件，軟件，我們解決了什麼任務，我們做了什麼。
來源： www.habr.com