資訊專欄INFORMATION COLUMN
摘要：后端開發(fā)的疑惑后端開發(fā)最常面對的一個問題性能高并發(fā)等等。而到了時代，在方面有了前后端分離概念移動后端更是無力渲染天然前后端分離。
先來上一張前端頁面的效果圖（Vue + Vux + Vuex + Vue-Router）。
第一次做gif 沒什么經驗，太大了。加載慢
項目地址： http://m.jiasux.com ，大家可以自行手機打開查看效果。
好了，廢話少說，來聊聊后端
后端寫些什么，什么東西寫出來對我是更好的總結，也是對大家更好的幫助？在準備寫的時候，我思考了很久。
之前準備了 手摸手，嘴對嘴 教程。想一想這樣子沒什么意思，如果是一步步做的教程還不如看視頻去，就想也許通過總結后端結構（注意是結構不是架構）設計、代碼組織、模塊劃分對大家更有幫助。
后端開發(fā)的疑惑后端開發(fā)最常面對的一個問題：性能、高并發(fā)等等。但是這不在本文的討論范圍，我們只講基本的怎么把代碼寫好，如何把業(yè)務模塊劃分好。
性能、高并發(fā)的解決方案， 大部分是在代碼之外的擴展。
那么站在純粹的 寫代碼 角度，如何寫好后端的代碼呢？我以前的疑惑常常有：Controller 層到底放哪些代碼？Model 又可以做哪些事情？自己的一些擴展、工具類，該如何組織？
發(fā)現(xiàn)現(xiàn)在能夠想起的疑惑變少了，如果你有什么疑惑，歡迎留言我們一起學習討論
雖然代碼主要是實現(xiàn)業(yè)務邏輯，但是選擇一款好的框架，非常有助于提升團隊作業(yè)能力，讓代碼層面的性能無憂。
框架的選擇說實話，自感 php7 出來后，代碼層面的性能，已經到了一個非常高的層度。基本上在百萬級別左右的系統(tǒng)，在語言層面沒有什么顧慮了。
框架方面，自己用過的php框架包括（時間先后）：ThinkPHP Laravel 非著名自造框架 Yii Phalcon
本文所有代碼結構設計與組織設計基于 Phalcon ，其它除了 自造框架 都是非常優(yōu)秀的框架，不過框架層面的性能，就自身而言，是逐步升高。但是通過一些整合，也可以逐步提升其自身性能，如：Laravel Yii與Swoole結合，也可達到 Phalcon 的程度。
php的版本是：7.1（如果你是一個新項目，一定要用php7）
后端要做些什么當然肯定需要先把db設計好，不過這不在我們討論范圍，假設已經完成了這一步。
我們的代碼需要提供以下幾部分能力：命令行腳本、api版本、后臺管理這三部分。當然這三部分也可以拆分成三個項目，不過小公司、小項目沒有必要（放在一個項目，加強了代碼的復用性）
這三個是大的模塊，然后再一個個接下來分析。
命令行腳本先說 命令行腳本 它是比較獨立的部分，不需要用戶調用，主要用來完成一些定時任務等。現(xiàn)代一點的框架，都提供這個模塊。
Phalcon提供了一個 CLI 模塊，可以方便的完成這部分能力。他的代碼寫起來還是 mvc 的結構，只不過訪問是通過命令行來進行。
比如一個最簡單的 cli
class MainTask extends Task
{
public function mainAction()
{
return fwrite(STDOUT, "hello task!")
}
}
api模塊
我在最早接觸api概念的時候，很懵逼，覺得很高大上。現(xiàn)在我對它的理解就是：前后端純數(shù)據(jù)通信的一種方式。以前做web開發(fā)，我們不提供api，直接后段把數(shù)據(jù)渲染在頁面上，用戶直接在渲染的界面上操作，然后通過按鈕或者什么觸發(fā)一個請求到后端。
而到了api時代，在web方面有了前后端分離概念；移動app后端更是無力渲染（天然前后端分離）。所以要后臺需要把數(shù)據(jù)發(fā)給前端，前端根據(jù)數(shù)據(jù)的描述把數(shù)據(jù)用用戶看得懂的方式展現(xiàn)出來。比如一個商品的api可能結構如下：
{
code: 1,
msg: "query ok",
data: {
name: "最涼快的空調",
price: "9999.00",
img: "xxx.webp",
stock: "10"
}
}
這種方式讓前后端的開發(fā)彼此獨立，大家專注做自己的事情。但是這也帶來另外一個問題：前端有了所謂的版本，后端必須兼顧所有使用的版本。如果我們永遠只使用一個api地址。那么代碼可能會相當難看。
比如現(xiàn)在有了一個新的需求，以前 空調 只有一張圖片。現(xiàn)在空調展示的時候有多張圖片。那么有兩種辦法，一種是增加字段，一種是將原字段 img 變?yōu)橐粋€數(shù)組。
如果是增加字段不會帶來兼容性的問題。但是如果是粗暴的將img類型變更為數(shù)組，之前的版本將無法解析這個類型，因此要想變?yōu)閿?shù)組，只能是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
版本信息就非常的一目了然。
絕大部分系統(tǒng)，都需要一個cms來上傳、修改相關資料。以加速俠為例：需要上傳游戲，需要編輯一些游戲合輯等。你可以多帶帶成一個項目，也可以還是用模塊來進行開發(fā)（我推薦，極大程度的提供了代碼復用）。
我最不能接受的一句話是：后臺順便弄一下，反正給公司內部用的。
做為一個有追求的程序員，我們必須要有底線，我們的目標是：讓大家工作起來更便捷，更輕松，最后讓大家沒有工作（哈哈哈）。所以后臺我也建議采用前后端分離，通過Vue來進行開發(fā)。
當前的后臺使用了 Vue + Element UI + Vuex + Vue-Roter來進行開發(fā)。參考了，網絡上的： 手摸手，帶你用vue擼后臺，寫的真不錯，為我學習省了很多彎路，特別是前端在權限控制上這一部分，他的方式讓我眼前一亮。我的后臺現(xiàn)在才剛剛搭建完基本的部分（路由規(guī)劃、一些自己擴展的vue插件）
前后端分離后，后段其實也可以歸結到api的開發(fā)部分。并且這樣帶來的一個好處是：如果以后后段要做移動版的一些功能，api都是現(xiàn)成的。
未完待續(xù)寫代碼越久，越發(fā)現(xiàn)語言層面的東西，只要多動手，很快就能達到一個水平。但是業(yè)務代碼寫的再多，也不能讓你再技術領域走的更遠。因此如果你有幸在大公司，有機會接觸大型項目（百萬、千萬用戶級）的，一定好好觀察為了這個項目這么多人開發(fā)，還能夠很好的運作？他是如何解耦業(yè)務邏輯與系統(tǒng)架構？如果是在小的公司，那么就盡可能自己嘗試去做一些系統(tǒng)的搭建，讓大家在這個基礎上進行業(yè)務開發(fā)，而不需要關心一些底層的東西，一個新手也能很快上手寫業(yè)務。
后面可能還會有兩篇到四篇講后端部分。主要包括，后端項目結構的劃分（這個結構我已經嘗試過在3、4個項目中使用，目前都運行的很好），后端登陸控制（會開源一個Phalcon的oauth2的代碼），后段api的自動化測試。
相關代碼我將會陸續(xù)放在github上面。所有的代碼就叫 x- 吧。x 從小學數(shù)學給我留下了深刻印象。
x-api 是php的后端項目
x-control 是vue寫的后端管理系統(tǒng)
x-client 是vue系的客戶端界面
個人博客：https://helei112g.github.io/
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/23270.html
摘要：最近終于痛定思痛，做了一個應用，目前的產品確實很一般，但決定以此為起步，逐步完善逐步提高。是以提供游戲下載游戲禮包發(fā)放為核心的移動端應用。可以簡單理解成一個游戲的應用市場。在寫后端的時候，產出了一個基于的授權的。 移動互聯(lián)網時代，我不想只當一個后端工程師，是時候學習一些新的東西了！ 一直以來想要學習一些前端的知識，擴寬自己的技術棧，但是一直以來對前端都是進行了解，沒有用一個產品把這些東...
摘要：介紹下一個新項目，后端該如何從零去搭建。我們先假設這個項目由兩部組成提供給站點使用的提供給運營人員使用的管理后臺。因此通過回顧，我們得出我們的后端項目需要一個的層次，來存放業(yè)務邏輯。 這是 后端開發(fā)者從零做一個移動應用 的后端部分第二篇。介紹下一個新項目，后端該如何從零去搭建。我們先假設這個項目由兩部組成 提供給wap站點、app使用的api； 提供給運營人員使用的管理后臺。 整個...
摘要：更詳細的內容下一章開篇深入聊聊前后分離講述關于我目前在寫從零構建前后分離項目系列，修正和補充以此為準不斷更新的項目實踐地址彩蛋提前預覽下一章傳送門 開篇 ： 縱觀WEB歷史演變 在校學習和幾年工作工作中不知不覺經歷了一半的 WEB 歷史演變、對近幾年的發(fā)展比較了解，結合經驗聊聊 WEB 發(fā)展歷史。 演變不易，但也是必然，因為為人始終要進步。 WEB 的發(fā)展史 一、開山鼻祖 - 石器時代...
摘要：更詳細的內容下一章開篇深入聊聊前后分離講述關于我目前在寫從零構建前后分離項目系列，修正和補充以此為準不斷更新的項目實踐地址彩蛋提前預覽下一章傳送門 開篇 ： 縱觀WEB歷史演變 在校學習和幾年工作工作中不知不覺經歷了一半的 WEB 歷史演變、對近幾年的發(fā)展比較了解，結合經驗聊聊 WEB 發(fā)展歷史。 演變不易，但也是必然，因為為人始終要進步。 WEB 的發(fā)展史 一、開山鼻祖 - 石器時代...
閱讀 1331·2019-08-30 15:44
閱讀 1381·2019-08-29 18:42
閱讀 433·2019-08-29 13:59
閱讀 770·2019-08-28 17:58
閱讀 2811·2019-08-26 12:02
閱讀 2414·2019-08-23 18:40
閱讀 2406·2019-08-23 18:13
閱讀 3106·2019-08-23 16:27
