admin管理系統開發的成長曆程

標籤：sha   方式   架構   關於   orm   日期   簡單的   區分   key   

所有系統的開發都受限於當時的技術積累、人力資源、設計方案，沒有完美的系統，我們只是在自己的技術能力內做到100分。 -- fuyuan

沒有完美的系統，只有適合的系統。我不是大神，本文結合我以前在一個國企的CRM管理系統和後來開發維護的一個系統來說介紹下我踩過的坑。
? 

業務背景

先說下業務背景吧，我當時接手重構改造任務的時候，面臨如下情況：

1. 老系統部署環境比較陳舊，還是apache+php, 比較老的環境了，經過若干年人員更替，部門分拆，已經不能說清楚上面啟動並執行各種服務了，營運部署起來也比較困難，哪天死了，基本上無法複製，單點情況比較嚴重。
2. 所用架構也比較老舊，自有架構，不僅包含後台服務代碼，還包含管理系統代碼，開發維護也比較困難。
3. 介面風格也比較舊，還是十幾年前的風格，操作起來比較怪異。
4. 領導授權說重構吧。這個是最關鍵的，領導授權，是一個項目啟動的旗幟。
   ?
   系統從開發到後來的最佳化都是遵循的原則PDCA。?
   ??
   ?
   好，匯總各方面需求總結的情況如下：
5. 新作一個管理後台系統，最好與主業務一樣的結構，這樣便於開發。即linux + nginx + php + yaf + memcache + yaconf + mysql等等。
6. 遷移舊系統功能，按時完成，實現新的需要的功能。
7. 找個流行的響應式模版。
8. 技術棧升級，這個是最近才加入的內容。
   
   ??
   ? 系統整體架構設計

   開始的時候因為對yaf不太熟，所以沒有注意到application.dispatcher.defaultRoute.controllerPrefer=true 這個配置。以至於 每次一個介面，都得重建一個檔案，寫一個controller。
   後來我想了一方法：對於a/b/c_d 這種路由，自己寫了個規則，映射到A_B_C controller的d action方法中。
   這樣 對於簡單的增刪改查方法，就可以放在一個檔案裡了。
   ? 

   model設計

   訪問資料庫的model，因為yaf架構比較簡單，所以我參照了thinkphp的訪問資料庫部分自己寫了一個簡單的模組。
   後來一個兄弟引入了laravel的ORM模組Eloquent，不過沒有遷移所有的業務，所以存在了兩套內容。
   ? 

   帳號

   這個比較簡單，跟常用的系統相同。
    

   角色

   角色管理是確定角色具備哪些許可權的一個過程，他是一個集合的概念，是眾多最小許可權顆粒的組成。我們通過把許可權給這個角色，再把角色給帳號，從而實現帳號的許可權，這是網上摘抄的，我在系統中並沒有實現這麼複雜。沒用用到 超級管理員，管理員，普通使用者角色區分，這個要看系統應用情境吧。
    ???

   許可權的定義

   網上有各種個樣的文章介紹管理系統的，我也介紹下我的這個系統裡面許可權的部分。

許可權可以分為三種：頁面許可權，操作許可權，資料許可權
??
頁面許可權：即入口，使用者可以看到哪個頁面，看不到哪個頁面。
操作許可權：進入同樣的頁面，有些人看到這個按鈕可點擊，有些人只能瀏覽這個頁面的資料。
資料許可權：則是控制你可以看到哪些資料，比如會員的人A只能看到或者修改A部建立的資料，他看不到或者不能修改B部的資料。

 
我這邊實現是限定一個一個常量列表和一個許可權菜單。可以是增刪改查的，我這邊考慮到這個變化有限，所以只在代碼中寫成了固定的內容，增加一項菜單就改回代碼就行了。

// 常量定義define(‘P_USER_MANAGE‘, 1); // 後台使用者管理define(‘P_USER‘, 2); // 使用者管理列表define(‘P_GROUP‘, 3); // 組管理列表... ...// 許可權樹P_USER_MANAGE => [            ‘title‘ => ‘後台管理‘,            ‘link‘ => ‘‘,            ‘class‘ => ‘fa fa-user‘,            ‘child‘ => [                P_USER => [                    ‘title‘ => ‘使用者列表‘,                    ‘link‘ => ‘/user/list‘,                    ‘class‘ => ‘‘,                    ‘child‘ => array()                ],                P_GROUP => [                    ‘title‘ => ‘組列表‘,                    ‘link‘ => ‘/group/list‘,                    ‘class‘ => ‘‘,                    ‘child‘ => array()                ]             ]]

這樣 每次使用者進入頁面 再根據一定的演算法獲得使用者 應該有的許可權，相關代碼可以參考：
https://github.com/netbird/permission

這個是以前實現的一個類，是將許可權由低到高排列，儲存的時候每4位轉變成1個十六進位的字元，然後合并。
例如： 使用者權限是 ‘‘, 把許可權 12加上，就是1000 0000 0000, 儲存就是，800。
主要實現了以下方法：

Permission::setuserPermission($permission_index, $user_perm)    // 這個是設定許可權，比如使用者的現在許可權是‘‘, 如果把12這個許可權號碼加上則執行：    // $user_permission = Permission::setuserPermission(12, $user_permission)Permission::deleteUserPermission($permission_index, $user_perm)    // 刪除許可權Permission::isAllowUserPermission($permission_index, $user_perm)     // 判斷使用者是否有許可權

至於按鈕許可權，這個也可以參照這個進行，定義一個按鈕的設定常量，判斷有那個許可權，則展示按鈕。
資料訪問，這個具體情境 具體分析了，不過每個介面入口的地方 至少需要判定存取權限。
 

響應式模版

技術講究厚積薄發，只有平時多積累多實踐，關鍵的時候才能發揮用途。因為以前做了類似的系統，所以利用了以下一個模版架構。然後進行改造。
 
我不願意每次都寫表格頁面，所以使用jquery table這個第三方的外掛程式，採用非同步載入資料的方式。在這個外掛程式上面進行了簡單的二次開發。後來的大多數功能都是採用的這個外掛程式。
 
bootstrap是個好東西，以前用的少，這次大規模使用，每天就是調頁面，調前端。在筆記本上看著不錯，到了顯示器上就走樣，很苦惱。不過我經手的頁面普遍沒啥問題。
 

功能改進

之前每次建立功能都得建立個表，然後寫編輯頁面，好煩啊。能不能搞個公用的機制，簡單的引用就產生個簡單的編輯頁面。於是，我對編輯部分進行了封裝改進。
先說下資料庫：建造個公用表：主要包含 main_key, second_key, config_value,等內容，config_value是參照key-value格式資料庫的value欄位使用，當然 text類型最高65535個位元組把，如果太大，會造成bug。

 
就是將關係型資料庫作為key-value用了，一些加單的配置資訊，經過json轉成字串然後儲存下來。
 

自訂通用配置

有沒有一種方案，能夠不編寫代碼，僅靠後台點點就能滿足配置？ 於是先出設計方案，後加工。
一般的項目配置分成單頁和列表的配置。可參照如下需求：

1. 進入設定頁面，建立1個item，類型分成單頁和列表。
2. 選擇 編輯頁面是否包含日期，發布許可權的人員，可修改欄位的人員，發布的檔案名稱等等吧。
3. 單頁面或者列表的單頁面編輯頁支援自訂欄位編輯(可添加或減少欄位)。
   於是這個項目就產生了。雖然體驗差了一點，但是基本滿足需求，節約開發時間還是沒有問題的。
    模版

   關於模版是在列表頁面提出的，在自訂欄表頁，每次建立單頁面的時候都需要重建資料很麻煩。於是改進了下，在配置頁面有個模版設定頁面，模版頁面可以添加刪除定義欄位。這樣在建立新頁面的時候就可以繼承模版了。
    

   ini設定檔

   關於產生的配置資訊，我們還是採用了yaconf的php擴充外掛程式，所以大部分配置以ini檔案的形式推到線上。yaconf的使用者可以輔助線上說明。下面部落格也總結了一些yaconf使用的坑。
   一些使用Yaconf的經驗分享

日誌及備份

一開始記錄mysql，每條都記錄，後來發現不太好，需要的時候什麼也查不出來。還是應該從產品的角度看這個日誌吧。
這個模組一直在開發改進中。大致的方向是給使用者一個友好的查詢介面，去查詢相關的內容。
因為一些隱患，後來我加入了配置資訊備份功能，每次配置更新的時候儲存已有的線上這個檔案配置，並且記錄到資料庫。然後做個後台，可以查看，比對配置並且上線。
這個地方引用了一個公用類庫：https://github.com/chrisboulton/php-diff
 

vue

一次偶然的機會接觸到vue基礎知識，在系統的某些頁面決定嘗試以下，沒有深入使用，只是引入了 vue.js。進行了一些頁面處理，感覺確實方便了很多。當時只是看了vue的一些基礎知識，有很多問題沒時間想，所以沒有深入應用。

Vue.js 組件與路由

http://element-cn.eleme.io/
https://ant.design/index-cn
 

ant design

年初，想對系統升級改造。增加幾個模組，朋友推薦ant design。感覺挺好，使用各種入坑。

下面是一些問題的總結。
ant design form表單的時間處理
碰到一個ant design跨域問題

全新的開發模式，我很喜歡。

 
技術棧：react，ant-design，dva，Mock
關於dva，有個圖，我想大家應該學習下：

最後學以致用，技術永遠為商務服務。這個是曆史以來的道理。多運用，多思考。

admin管理系統開發的成長曆程