從零開始搭建一個PaaS平臺 - 咱們要作什麼

前言

從最開始的小公司作小網站，到如今進入如今的公司作項目，發現小公司裏不少不少工做都是重複的勞動（增刪改查），不過想一想也是，業務軟件最基礎的東西不就是增刪改查嗎。

可是不少時候，這種業務邏輯其實沒有必要挨個重寫。總不能說你的增刪改查比個人高級不少。很大程度上，複雜的問題只是數據太多了怎麼優化。

 

簡介

在真的開始作以前，先來簡單介紹幾個概念。簡單介紹一下PaaS是什麼，大概意思就是已經作好了一個大的平臺，你能夠在上邊快速的配置、擴展你的服務。

詳細的介紹推薦看一下阮一峯老師的博客 http://www.ruanyifeng.com/blog/2017/07/iaas-paas-saas.html

 

概念上

我想從零開始搭建一個可以配置定義業務，經過代碼擴展業務的平臺。在這個平臺上，簡單的需求，不寫代碼。複雜需求，只寫與標準不一樣的代碼。

 

有啥好處 

提升生產力

其實，作軟件的大部分時候，都是在寫增刪改查，實在是太簡單了。搬磚誰不會對吧，要想搬得快，不須要你有多麼好的腳力，更多的時候，你可能須要一個塔吊。

 

穩定的高負載

PaaS的設計之初，就是爲了比較大的數據量來考慮的。項目小的時候，怎麼着都行，可是，數據量一旦上來以後。小的項目可能根本無法用，若是是PaaS平臺的話，你可能只須要多幾臺機器就完了，仍是基礎組搞的事情。

 

分工明確

提到了高負載，其實很大程度上都是底層的事情。普通的開發，更多的好處只是性能的提高。那麼就須要兩撥能力不一樣的人來共同完成這件事情。搞底層的更專一性能、擴展，搞業務的就更關注本身的核心業務就完了。

 

更少的服務代價

這個指的是客戶花銷，也是PaaS對於傳統軟件的優點。PaaS平臺一旦作完，他確定已經有平臺了，若是要開發新的功能，可能並不須要佔用更多的資源，只是在原有的資源上增長點業務而已。何況PaaS服務商與客戶更多的是提供服務的續租模式，多一個客戶少一個客戶，其實對於服務器來講並無啥壓力，同一個團隊可以服務與更多的人。

 

開發更快

就算是往小裏作，若是你有這麼一個PaaS的框架，你想要在上邊直接搞一個業務的話。其實也就是搞點配置，而後做爲一個單機軟件部署，純定製開發也會變得更快。

 

具體點 咱們要作什麼

假設咱們如今要作一我的員管理系統，咱們通常須要如下內容。

- 增長數據

能夠配置一個或者多個新增數據的頁面，點擊保存就保存了數據

 

 

 

 

 

 

- 刪除數據

能夠配置個按鈕，點擊一下就把相關數據刪除掉

 

 

 

- 修改數據

能夠配置個按鈕，點擊一下出現一個編輯頁面，裏邊會出現對應的數據，你能夠修改，而後點擊一下更新，數據就更新了

 

 

 

- 查

-- 列表頁面

你能夠在列表頁面，配置幾個篩選項，而後你修改完數據以後，點擊搜索，就會根據你的數據來改變列表內容數據

 

 

 

-- 詳情頁面

你能夠在列表頁面點擊名稱（點擊哪一個能夠配置）而後，就會自動跳轉到詳情頁面

詳情頁面要展現哪些內容也能夠經過配置來進行修改

NoCode能力

這個是整個業務的核心，也是PaaS之因此能夠將幾個月的工做量濃縮爲數週的緣由所在。

其實就是一個簡單想法的轉變，本來咱們要實現我上邊畫的幾張圖，都是考改變代碼來實現，好比說列表頁面應該是戰士什麼Title、列表要不要出現選擇框、列表究竟展現那幾列、右上角究竟有什麼按鈕等等。

如今將這些本來須要寫到代碼裏邊的邏輯整理到配置裏邊，而後經過解釋這些配置，渲染出頁面，渲染出邏輯。

 

LowCode能力

固然了，上述的狀況太過於簡單了，基本上就是一個數據庫的內容簡單展現而已，若是咱們須要更復雜一點的內容呢？

 

好比說咱們須要輸出這我的的年齡分層（幼兒、少年、青年、中年、老年），咱們要怎麼作呢？

很顯然這個狀態不該該被存放在數據庫中的，由於這個其實是經過年齡動態計算出來的，過一年以後這個展現狀態可能就會過時了，這個時候咱們就須要可以動態插入邏輯根據年齡計算這幾個值，而後輸出結果。

 

固然這並非所有了，其餘還有不少須要解決的事情。好比

• 使用配置來實現渲染，配置數據，讀取起來是否是要比寫代碼慢不少？
• 搜索條件可能有不少，怎麼實現這些條件可用呢？
• 若是默認的頁面知足不了個人需求怎麼辦？
• 業務權限要怎麼處理？總不能進入系統的人都有權限吧？
• 開發完了這個玩意怎麼發佈到線上去？
• ... ...

 

這個玩意有點龐大，一口氣說不完。此次內容就這麼多，我也只能一邊整理一邊寫博客，這可能會是一個很長，也多是作不下去很短的系列。

寫的很差，能力有限多多見諒