前言
自營商城在技術層面來說是比較簡單的系統，難點一般都在業務邏輯，只要業務邏輯理通順了，技術實現起來並不難。但是做一個可靠的系統還是需要一定的功夫打磨，畢竟再簡單的系統如果沒有一定的規劃與架構，後續維護與擴充套件也是一個頭疼的問題。以下是我從事商城開發一年多的個人經驗，分享給大家一起探討學習。
技術棧架構圖
詳細說明
後臺
自營商城最開始開發一般都是小團隊進行開發，後臺不會有前端工程師的參與，我個人非常推薦使用 ElementUI 進行後臺開發（原始引入的方式，非打包），後臺程式設計師參考官方文件就能寫出很好看的 UI，結合上 Vue 對於一些複雜的表單頁面也會比 jQuery 好寫很多。
前臺
前臺是商城的重要組成部分，一般會先由設計部出設計稿，評審透過後再交給前端進行開發。
商城是一個非常需要 SEO 的網站，所以在技術選型上優先考慮使用框架模板引擎作為基礎，對於一些不需要 SEO 的頁面（購物車，個人中心）可以使用 Vue 渲染。
對於靜態資源的引入會涉及到 CDN 快取的問題，所以使用 Webpack 對靜態資源（css,js）進行打包，而後結合 Laravel mix 進行版本更迭。
axios 是替代原有 jQuery ajax 的，他擁有非常完善的請求機制，程式碼層面也更加語義化。
Promise：商城中會涉及到第三方平臺資料上報，有時候部分業務邏輯在前臺是非同步的，這時候就需要用到 Promise。
伺服器
軟體
伺服器基本架構還是 LNMP，但是對於完善的系統應該還需要一些工具的輔助。
Redis:作為快取驅動、佇列驅動、鎖、Session驅動 等
Supervisor: 守護佇列程式
Shell：切割日誌、伺服器備份等
ElasticSearch：前臺搜尋引擎、日誌收集等
程式碼
在傳統的 MVC 上，多加一層
service，用於放置業務邏輯，結合公司實際業務需求也可繼續劃分。
Middleware: 用於許可權校驗、日誌採集等全域性性的邏輯
Job: 不影響主流程的業務邏輯都應該使用佇列，例如客戶註冊成功傳送郵件，客戶註冊是主流程，只要客戶註冊資料寫入資料庫成功，就可以跟客戶端返回成功，發郵件使用非同步進行處理。這樣既最佳化了業務流程，也最佳化了程式碼結構
Event: 事件是 Job 的升級版，業務初始邏輯可能是客戶註冊成功傳送郵件，後面產品經理又加需求：客戶註冊成功要發優惠券，如果去註冊邏輯那裡再派發個優惠券任務是不是顯得不夠優雅（
如果產品經理又雙叒叕加邏輯，揍他），這時候就可以使用事件來代替了，只用在主流程結束後派發一個事件，然後再給事件定義監聽者即可Exception: 我很少在業務邏輯中看到有人寫專門的異常類，但是我十分推薦大家使用異常，每個業務邏輯都應該有自己的異常類，一個方法只有異常跟正常，上層只用放心呼叫、處理異常就行，不需要關心方法的返回值（返回值必然是成功）
資料庫管理
migration 是一個十分符合版本管理的工具，以前使用 SQL 檔案進行資料庫管理，往往會有資料庫跟線上不一致的情況，而且執行起來也麻煩，自從用上了 migration ，一行命令輕鬆遷移（點一下用一年，超快遷移不要錢），結合上 seed，能夠對資料庫結構與初始資料進行一個很好的統一。
依賴管理
0202年了，還有人把 vendor 資料夾納入版本管理（氣冷抖）
之前接手一個專案， vendor 資料夾納入了版本管理，並且更改了框架底層程式碼（之前程式設計師說沒辦法只能改底層，後續出了一堆莫名奇妙的 Bug），說多了都是淚。對於第三方依賴儘量不要去改底層，如果真的是有問題，可以單獨拿出來（或者給作者提 issue），一旦更改了第三方依賴，等於說放棄了版本升級、官方 Bug 修復，一切都只能自己來，耗時又費力還不一定搞的好。
許可權管理
這裡指的是後臺系統的許可權，商城系統比較簡單，使用一般的 RBAC 即可。
異常通知
針對專案中的各種異常，可結合公司辦公 IM 軟體進行告警，企業微信和釘釘都有群機器人，結合 Laravel 的 Exception Handler 進行異常告警，發現 Bug 的速度大大提升（偷偷改 Bug ，業務還不知道）
定時任務
主要用於訂單超時處理、日誌切割、資料備份等
程式碼更新
在部署伺服器程式碼更新完後，更新第三方依賴，打包靜態資源，然後 rsync 同步到生產伺服器，減少生產伺服器當機時間。
深圳求職中，坑位介紹可私信，筆芯
本作品採用《CC 協議》，轉載必須註明作者和本文連結