平臺應該怎麼設計，它和框架有何不同？很多時候大家常常將它們混為一個概念，其實不然，在我看來平臺是管理生態建設的，而框架是規範和引導編碼的，兩者相互成就彼此。使用框架開發出來程式後，應該交由平臺控制和管理，平臺不只是管理程式（產品/專案），最主要的是為人提供服務，這也是軟體存在的本質，為使用者提供優質的體驗和舒暢的服務，通過電子化辦公簡化業務複雜度和業務量。

站在程式設計師的角度，一旦說到框架和平臺，那麼首先想到的應該是選擇哪一門程式語言去實現？在選定程式語言後應當選擇那一套技術去實現，這應該是大多數國人的習慣，因為我們習慣了使用別人設計開發出來的框架。然而今天我要說：你可以自由選擇程式語言和程式語言所存在的框架，因為我說的平臺和架構與程式語言沒有直接關係，你可以選擇Java、也可以選擇C#、還可以選擇Golang\PHP\Python......，只要遵循雲平臺和程式架構設計規範即可。

如果你不相信我說的，請看下邊我羅列的一個基礎平臺下應該具備的十大系統：

1.控制系統設計
1.1.服務端
1.1.1.版本管理：釋出程式的各個版本
1.1.2.叢集管理：產品，版本（v1.0，v2.0等），程式，例項
1.1.3.配置管理：例項配置引數，與版本直接相關
1.1.4.編排管理：地域，語言，時區
1.1.5.升級管理：設定升級方案
1.1.6.更新管理：程式自我更新
1.1.7.狀態管理：例項報告自身狀態
1.1.8.註冊管理：服務註冊上線
1.1.9.負載均衡管理：服務發現與使用
1.1.10.問題管理：服務下線、服務異常，更新失敗，狀態異常等
1.1.11.自動管理：依據狀態報告自我調控
1.1.12.通知管理：配置異常時訊息通知事項
1.2.客戶端
1.2.1.版本管理（釋出程式的各個版本）
1.2.2.釋出管理（設定升級方案）
1.2.3.更新管理（完全更新，補丁式更新）

2.平臺系統設計
2.1.資源管理（產品/程式，模組/選單/命令等）
2.1.1.資源許可權管理（資源與角色，角色與使用者）
2.1.2.資源教程管理（以書籍形式供他人閱讀使用
2.1.3.資源版本管理（用於控制呼叫方與服務方版本的一致性）
2.2.安全管理
2.2.1.安全令牌管理（token）
2.2.2.安全名單管理（黑白名單，IP地址）
2.2.3.安全防禦管理（指令碼攻擊，xss/csrf等）
2.2.4.安全演算法管理（rsa、aes、shaXXX等）
2.2.5.安全位置檢驗（驗證當前IP地址的位置，以及常用IP地址等資訊）
2.2.6.安全狀態檢測（賬戶的安全狀態，如登入地，密碼狀態等）
2.3.分散式管理
2.3.1.主子庫管理（根據定義自動建立子庫表結構，同步基礎資料）
2.3.2.讀寫庫管理（實現讀寫分離提升效能）
2.4.使用者管理
2.5.機構管理
2.6.日誌管理
2.7.訊息管理
2.8.高階管理
2.8.1.快取管理
2.8.2.佇列管理

3.地理系統設計
3.1.地球/洲/地域/國家/區域/省級/市級/區縣/辦事處或鄉鎮/街道或行政村/小區或村莊
3.2.擴充套件：電信編碼，網址字尾，郵政編碼，語言編碼，時區劃分，名稱管理，簡介資訊等

4.語言系統設計
4.1.用於打造多語言生態環境

5..通用系統設計
5.1.提供公共資料服務，如天氣等

6..生態系統設計
6.1.用於打造生態圈，接入開發者和合作夥伴

7.外聯絡統設計
7.1.管理購買或接入他人系統服務的資訊

8..檔案系統設計
8.1.用於儲存非網格化的檔案，如圖片，音訊，視訊，文字文件等。

9..流程系統設計
9.1.用於表單稽核控制管理，獨立出來專業管理

10.反饋系統設計
10.1.適者生存，更好服務使用者和市場。

上述系統僅從平臺角度設計，並不包含具體的某個程式，如網關係統等。看過後是否還在懷疑我說話，一直以來都在堅持、並努力做到從零開始設計、編碼、測試、部署，去一探底層技術的究竟，儘可能的避免養成依賴他人技術的習慣，為此職業生涯更換過多次工作，雖然很坎坷，但終歸有所獲有所得，在此特別強調一點，不是建議大家都去造輪子，而是建議大家做到技術人應該具備的品質，去探索、去實驗、去發現。

想要設計出一套自主可控的技術平臺，非常不容易，也絕非一朝一夕間可以早就的，這需要持續的投入（人力、物力、財力）和長時間的研發，就像我一直將“研發”和“開發”這兩個詞著重劃分開解釋一樣，因為在我看來研發是創造，從無到有，而開發是製造，兩者不可同日而語，很多boss都希望自己的技術團隊可以弄出一套像淘寶、京東等一樣的平臺，只是忽略了這麼浩大的工程所需要的投入，說遠了，當然這也絕非不可能實現，只要是敢於投入、放得開、放得下、天道酬勤，有基於實際的設計規劃和可行的實施方案，志存高遠、勵精圖治，循序漸進、有條不紊的推進，最後是有可能實現最初的希望。