先來上一張前端頁面的效果圖（Vue + Vux + Vuex + Vue-Router）。
* 第一次做gif 沒什麼經驗，太大了。加載慢 *
項目地址： http://m.jiasux.com ，大家可以自行手機打開查看效果。
好了，廢話少說，來聊聊後端
後端寫些什麼，什麼東西寫出來對我是更好的總結，也是對大家更好的幫助？在準備寫的時候，我思考了很久。
之前準備了 手摸手，嘴對嘴 教程。想一想這樣子沒什麼意思，如果是一步步做的教程還不如看視頻去，就想也許通過總結後端結構（注意是結構不是架構）設計、代碼組織、模塊劃分對大家更有幫助。
後端開發的疑惑
後端開發最常面對的一個問題：性能、高併發等等。但是這不在本文的討論範圍，我們只講基本的怎麼把代碼寫好，如何把業務模塊劃分好。
性能、高併發的解決方案， 大部分是在代碼之外的擴展。
那麼站在純粹的 寫代碼 角度，如何寫好後端的代碼呢？我以前的疑惑常常有：Controller 層到底放哪些代碼？Model 又可以做哪些事情？自己的一些擴展、工具類，該如何組織？
發現現在能夠想起的疑惑變少了，如果你有什麼疑惑，歡迎留言我們一起學習討論
雖然代碼主要是實現業務邏輯，但是選擇一款好的框架，非常有助於提升團隊作業能力，讓代碼層面的性能無憂。
框架的選擇
說實話，自感 php7 出來後，代碼層面的性能，已經到了一個非常高的層度。基本上在百萬級別左右的系統，在語言層面沒有什麼顧慮了。
框架方面，自己用過的php框架包括（時間先後）：ThinkPHP Laravel 非著名自造框架 Yii Phalcon
本文所有代碼結構設計與組織設計基於 Phalcon ，其它除了 自造框架 都是非常優秀的框架，不過框架層面的性能，就自身而言，是逐步升高。但是通過一些整合，也可以逐步提升其自身性能，如：Laravel Yii與Swoole結合，也可達到 Phalcon 的程度。
php的版本是：7.1（如果你是一個新項目，一定要用php7）
後端要做些什麼
當然肯定需要先把db設計好，不過這不在我們討論範圍，假設已經完成了這一步。
我們的代碼需要提供以下幾部分能力：命令行腳本、api版本、後臺管理這三部分。當然這三部分也可以拆分成三個項目，不過小公司、小項目沒有必要（放在一個項目，加強了代碼的複用性）
這三個是大的模塊，然後再一個個接下來分析。
命令行腳本
先說 命令行腳本 它是比較獨立的部分，不需要用戶調用，主要用來完成一些定時任務等。現代一點的框架，都提供這個模塊。
Phalcon提供了一個 CLI 模塊，可以方便的完成這部分能力。他的代碼寫起來還是 mvc 的結構，只不過訪問是通過命令行來進行。
比如一個最簡單的 cli
class MainTask extends Task
{
public function mainAction()
{
return fwrite(\STDOUT, 'hello task!')
}
}api模塊
我在最早接觸api概念的時候，很懵逼，覺得很高大上。現在我對它的理解就是：前後端純數據通信的一種方式。以前做web開發，我們不提供api，直接後段把數據渲染在頁面上，用戶直接在渲染的界面上操作，然後通過按鈕或者什麼觸發一個請求到後端。
而到了api時代，在web方面有了前後端分離概念；移動app後端更是無力渲染（天然前後端分離）。所以要後臺需要把數據發給前端，前端根據數據的描述把數據用用戶看得懂的方式展現出來。比如一個商品的api可能結構如下：
{
code: 1,
msg: 'query ok',
data: {
name: '最涼快的空調',
price: '9999.00',
img: 'xxx.webp',
stock: '10'
}
}這種方式讓前後端的開發彼此獨立，大家專注做自己的事情。但是這也帶來另外一個問題：前端有了所謂的版本，後端必須兼顧所有使用的版本。如果我們永遠只使用一個api地址。那麼代碼可能會相當難看。
比如現在有了一個新的需求，以前 空調 只有一張圖片。現在空調展示的時候有多張圖片。那麼有兩種辦法，一種是增加字段，一種是將原字段 img 變爲一個數組。
如果是增加字段不會帶來兼容性的問題。但是如果是粗暴的將img類型變更爲數組，之前的版本將無法解析這個類型，因此要想變爲數組，只能是api的整體升級（一般不會因爲這個問題就進行升級）。
那麼api做版本有哪些辦法呢？我採用了Phalcon的模塊來做api的版本控制。以前還嘗試過控制器版本。比如：
ApiV1Controller 表示這是v1版本。ApiV2Controller表示是v2版本。Phalcon的模塊爲版本提供了非常大的便利，直接新開一個模塊，取名 v1，如果之後要升級，新開一個模塊叫做 v2。對於不需要修改的功能，可以簡單的讓v2控制器繼承v1中的控制器。
api的版本方面，我們就可以簡單通過url的方式完成，比如：
- https://api.xxx.com/v1/user/123
- https://api.xxx.com/v2/user/123
版本信息就非常的一目瞭然。
後臺管理
絕大部分系統，都需要一個cms來上傳、修改相關資料。以加速俠爲例：需要上傳遊戲，需要編輯一些遊戲合輯等。你可以單獨成一個項目，也可以還是用模塊來進行開發（我推薦，極大程度的提供了代碼複用）。
我最不能接受的一句話是：後臺順便弄一下，反正給公司內部用的。
做爲一個有追求的程序員，我們必須要有底線，我們的目標是：讓大家工作起來更便捷，更輕鬆，最後讓大家沒有工作（哈哈哈）。所以後臺我也建議採用前後端分離，通過Vue來進行開發。
當前的後臺使用了 Vue + Element UI + Vuex + Vue-Roter來進行開發。參考了，網絡上的： 手摸手，帶你用vue擼後臺，寫的真不錯，爲我學習省了很多彎路，特別是前端在權限控制上這一部分，他的方式讓我眼前一亮。我的後臺現在纔剛剛搭建完基本的部分（路由規劃、一些自己擴展的vue插件）
前後端分離後，後段其實也可以歸結到api的開發部分。並且這樣帶來的一個好處是：如果以後後段要做移動版的一些功能，api都是現成的。
未完待續
寫代碼越久，越發現語言層面的東西，只要多動手，很快就能達到一個水平。但是業務代碼寫的再多，也不能讓你再技術領域走的更遠。因此如果你有幸在大公司，有機會接觸大型項目（百萬、千萬用戶級）的，一定好好觀察爲了這個項目這麼多人開發，還能夠很好的運作？他是如何解耦業務邏輯與系統架構？如果是在小的公司，那麼就儘可能自己嘗試去做一些系統的搭建，讓大家在這個基礎上進行業務開發，而不需要關心一些底層的東西，一個新手也能很快上手寫業務。
後面可能還會有兩篇到四篇講後端部分。主要包括，後端項目結構的劃分（這個結構我已經嘗試過在3、4個項目中使用，目前都運行的很好），後端登陸控制（會開源一個Phalcon的oauth2的代碼），後段api的自動化測試。
相關代碼我將會陸續放在github上面。所有的代碼就叫 x- 吧。x 從小學數學給我留下了深刻印象。
- x-api 是php的後端項目
- x-control 是vue寫的後端管理系統
- x-client 是vue系的客戶端界面
如果你對我的內容感興趣，請關注我的微信公衆號：
公衆號：icanfo
