簡介面向同城家政、上門按摩等本地生活服務場景的預約系統(tǒng)完整源碼后端基于ThinkPHP與FastAdmin框架前端采用Uniapp實現(xiàn)微信H5和小程序端適合具備PHP基礎、希望快速搭建可商用預約平臺的開發(fā)者或創(chuàng)業(yè)團隊。系統(tǒng)已完整跑通并通過測試包內(nèi)包含公眾號通知模塊、后端主程序、前端Uniapp源碼、數(shù)據(jù)庫SQL腳本及通知音頻文件運行環(huán)境為LinuxNginxphp7.2mysql5.6需安裝fileinfo與redis擴展H5屬于公眾號H5須在微信內(nèi)訪問并配合認證服務號、微信支付、小程序賬號完成部署。資源共2000個文件以JavaScript、Vue組件、Markdown文檔為主輔以JSON、HTML、CSS等配置樣式文件以及SQL、Python輔助腳本整體66.31MB目錄按功能模塊劃分便于快速定位與二次開發(fā)。已有255人學習下載參照包內(nèi)說明即可完成環(huán)境搭建、支付與服務號配置明顯降低從零開發(fā)聯(lián)調(diào)的踩坑成本。1. 為什么一套thinkphpuniapp的上門預約源碼能把三個月工期壓到兩周接到一個上門家政按摩的需求時多數(shù)團隊的第一反應是拆端用戶端一個小程序技師端一個微信小程序后臺一個管理系統(tǒng)再來一套H5做分享四端聯(lián)動光聯(lián)調(diào)就得一個月。而thinkphpmysqluniappfastadminuniapp這套組合的思路是后端只有一份PHP負責接口和后臺前端只有一份uniapp代碼同時編譯成H5、微信小程序和App。后臺管理用fastadmin二次開發(fā)RBAC權(quán)限、菜單管理、數(shù)據(jù)表格CRUD這些重復勞動直接點出來用。也就是說你真正要寫的只有業(yè)務層的預約、派單、支付回調(diào)、結(jié)算這幾個模塊。這個方案適合的正是中小本地生活團隊、接外包的獨立開發(fā)者以及想用最小成本快速驗證同城上門模式的初創(chuàng)團隊。它不追求架構(gòu)上的炫技追求的是從拿源碼到跑通首單的速度。2. 選型邏輯這套技術(shù)組合憑什么能扛住上門預約業(yè)務2.1 thinkphpfastadmin為什么還是上門預約類項目的主力選型上門預約系統(tǒng)這類項目核心業(yè)務是訂單而訂單系統(tǒng)的首要要求是開發(fā)快、能維護、招人容易。thinkphp在國內(nèi)中小型項目里的存量非常大中文文檔和社區(qū)問答足夠覆蓋開發(fā)中遇到的絕大多數(shù)問題。對這個場景來說生態(tài)比性能重要——你招一個PHP開發(fā)大概率不用從零教框架你在搜索引擎里搜一個問題大概率能直接搜到別人踩過的坑。這就是為什么很多同城服務源碼、外賣源碼、預約源碼都在thinkphp里做市場已經(jīng)用腳投票了。fastadmin則是建立在thinkphp之上的后臺開發(fā)框架。它解決的痛點和上門預約項目高度相關(guān)后臺要管理用戶、技師、訂單、服務項目、優(yōu)惠券、提現(xiàn)申請……這些本質(zhì)上都是數(shù)據(jù)表格。fastadmin提供了一鍵生成CRUD的功能你在數(shù)據(jù)庫建好表后臺就能自動生成對應的菜單、控制器、模型和視圖模板。對于技師審核、訂單列表、資金流水這類管理頁面幾乎不用手寫。我一般接手這類項目時第一步是先把fastadmin后臺跑起來看它的菜單結(jié)構(gòu)再決定哪些表直接生成CRUD哪些表需要寫自定義接口。這比從零搭后臺至少省一半工作量。還有一個關(guān)鍵點是權(quán)限。上門預約系統(tǒng)需要區(qū)分總管理、商家/門店管理、財務、客服這些角色。fastadmin自帶RBAC權(quán)限管理每個角色分配菜單和操作權(quán)限這套機制是現(xiàn)成的。如果自己寫角色-權(quán)限-菜單三張關(guān)聯(lián)表加上中間的邏輯校驗又是兩三天的活。省下來的時間投到業(yè)務里去。2.2 uniapp一套代碼覆蓋H5、微信小程序和App的編譯鏈路上門預約系統(tǒng)的前端有一個特點用戶可能在微信里搜小程序進來也可能從朋友圈的H5鏈接進來技師端又往往需要裝App。如果用原生開發(fā)這三端各寫一遍維護壓力巨大。uniapp的價值就在這里——一套vue語法的代碼通過不同的編譯配置分別產(chǎn)出微信小程序包、H5頁面和原生App包。我在實際項目中一般把前端分成兩個uniapp工程一個是用戶端包含首頁、服務分類、下單、訂單列表、支付、評價另一個是技師端包含接單大廳、訂單詳情、導航、結(jié)算記錄、提現(xiàn)。兩個工程共用公共組件和接口封裝但頁面和登錄邏輯分開。用戶端用微信授權(quán)登錄H5端用手機號驗證碼登錄不同端之間的差異通過條件編譯處理。條件編譯是uniapp里比較重要的一個機制。比如支付邏輯小程序端需要調(diào)起wx.requestPaymentH5端走的是公眾號支付或掃碼支付。代碼里可以這樣處理// #ifdef MP-WEIXIN uni.requestPayment({ provider: wxpay, orderInfo: res.data.payParams, success: () this.loadOrderDetail() }); // #endif // #ifdef H5 window.location.href res.data.payUrl; // #endif這段代碼的邏輯是編譯到微信小程序時只保留MP-WEIXIN塊調(diào)用小程序原生的支付接口編譯到H5時只保留H5塊直接跳轉(zhuǎn)到支付鏈接。這樣支付這種強平臺差異的邏輯就分開了頁面結(jié)構(gòu)和業(yè)務邏輯則完全復用。新人在接這類項目時最容易出問題的地方就是分不清哪些代碼是跨端通用的哪些是端特有的。我的經(jīng)驗是只管接口和渲染的代碼盡量寫通用一碰到登錄、支付、地理位置、文件上傳這類邊界能力馬上用條件編譯隔離。2.3 mysqlredis的分工哪些數(shù)據(jù)必須走數(shù)據(jù)庫哪些走緩存上門預約系統(tǒng)的數(shù)據(jù)可以分成兩層一層是訂單、用戶賬戶、技師資料、交易流水這些是核心業(yè)務數(shù)據(jù)必須保證強一致一律放mysql另一層是驗證碼、token會話、在線狀態(tài)、首頁熱門技師緩存這些允許短暫過期和延遲放redis是常規(guī)做法。mysql這邊有一個值得注意的點所有的訂單狀態(tài)變更都應該用事務條件更新來保證安全。比如用戶取消訂單、技師接單、平臺關(guān)閉訂單三者的本質(zhì)都是把某個狀態(tài)的訂單變成另一個狀態(tài)必須確保同一時刻只有一個操作能成功。事務在這里是底線。redis的作用則更偏提速和限流。上門預約系統(tǒng)里最典型的redis應用是短信驗證碼的發(fā)送間隔控制同一個手機號60秒內(nèi)只能發(fā)一次直接在redis里存一個key設置有效期60秒發(fā)送前先查這個key。另一個典型應用是技師端接單大廳的訂單列表緩存——新訂單寫入mysql后同步寫一條到redis列表技師端輪詢接口優(yōu)先讀redis減輕mysql的查詢壓力。緩存和數(shù)據(jù)庫之間的一致性我的做法是只在非關(guān)鍵路徑上用緩存訂單狀態(tài)、賬戶余額這種敏感數(shù)據(jù)絕不先進緩存再落庫直接寫mysql讀也直接讀mysql。為省那么一點查詢壓力引入數(shù)據(jù)不一致的坑不值得。2.4 為什么不用微服務單體架構(gòu)對這個業(yè)務到底夠不夠很多開發(fā)者拿到這類項目后會問訂單、用戶、支付、技師管理是不是應該拆成微服務這里要給個明確的結(jié)論同城上門預約的流量模型是典型的脈沖式峰值QPS大概率在幾十到幾百之間單體架構(gòu)完全扛得住。拆微服務帶來的服務發(fā)現(xiàn)、分布式事務、鏈路追蹤這些問題對一支三五個人的開發(fā)團隊來說是負擔而不是收益。我傾向于這樣看架構(gòu)業(yè)務量級沒到一個模塊單獨部署一臺機器之前保持單體但把模塊在代碼層面拆清楚。比如fastadmin里的應用目錄按模塊組織admin后臺、api接口、job隊列各自獨立邏輯上已經(jīng)分離了。等哪天真需要拆先把api模塊抽出來獨立部署其他模塊保持原樣遷移成本是可控的。這套組合選型的最終理由是它能讓你把有限的開發(fā)資源全部投到業(yè)務邏輯里而不是基礎設施里。3. 把上門預約系統(tǒng)從源碼跑成本地可用的完整步驟3.1 環(huán)境準備PHP版本、擴展和nginx偽靜態(tài)上門預約系統(tǒng)的源碼跑起來之前先確認本機環(huán)境。PHP建議用7.2到7.4之間的版本這既是thinkphp 5.x系列最穩(wěn)妥的運行區(qū)間也兼容fastadmin第三方的絕大多數(shù)插件。需要用到的擴展包括pdo_mysql、redis、fileinfo、openssl、gd。其中fileinfo在部分環(huán)境下默認沒開thinkphp的文件上傳和圖片處理會用到漏了會報Class finfo not found。redis擴展也常被忽略但驗證碼和token依賴它后面會專門說。PHP環(huán)境就緒后設置php.ini里的兩個參數(shù)date.timezone Asia/Shanghai post_max_size 100M upload_max_filesize 20M時區(qū)必須顯式配置。PHP默認是UTCmysql默認又是系統(tǒng)時區(qū)兩個不一致訂單創(chuàng)建時間、技師接單時間全都會歪8個小時查數(shù)據(jù)時翻車概率很高。upload相關(guān)的兩個參數(shù)是為了后臺上傳服務項目圖片、技師頭像時不至于被大小限制卡住。接下來是nginx的偽靜態(tài)配置。thinkphp的URL訪問方式是入口文件index.php加上路由參數(shù)nginx默認配置下訪問https://域名/order/detail?id1這類地址時nginx會嘗試找order目錄下的detail文件結(jié)果404。必須在server塊里加上重寫規(guī)則server { listen 80; server_name your.domain.com; root /path/to/your-project/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 30d; } }這段配置的邏輯是當請求的文件不存在時把路徑交給index.php處理并作為參數(shù)s傳遞php文件由fastcgi處理靜態(tài)資源單獨設置30天緩存減輕接口服務器壓力。參數(shù)方面root指向的是項目下的public目錄而不是項目根目錄這是thinkphp的安全要求public之外的目錄不允許被直接訪問。fastcgi_pass的端口要和你本機php-fpm的listen端口一致默認9000如果改動過要同步。3.2 導入數(shù)據(jù)庫與后臺初始化從SQL文件到第一個管理員賬號源碼包一般會帶一個.sql格式的數(shù)據(jù)庫備份文件。操作前先創(chuàng)建一個utf8mb4編碼的數(shù)據(jù)庫編碼用utf8mb4是為了正確存儲用戶昵稱里的emoji字符。然后導入SQL文件mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS house_service DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p house_service house_service.sql命令說明第一條命令創(chuàng)建數(shù)據(jù)庫第二條把備份文件里的表結(jié)構(gòu)和初始數(shù)據(jù)灌入。導入過程如果報錯常見原因是sql文件里包了創(chuàng)建數(shù)據(jù)庫語句或者是mysql版本差異導致語法不兼容。遇到這種情況直接用可視化工具導入更省心導入后再確認一下表數(shù)量和數(shù)據(jù)量避免中途中斷導致缺表。數(shù)據(jù)庫導入后配置項目根目錄下的.env文件或application/database.php。核心是數(shù)據(jù)庫連接信息// application/database.php 中的連接配置 return [ type mysql, hostname 127.0.0.1, database house_service, username root, password your_password, hostport 3306, prefix fa_, charset utf8mb4, ];注意prefix這個參數(shù)它對應數(shù)據(jù)表前綴。fastadmin的數(shù)據(jù)表默認前綴是fa_例如fa_order、fa_technician。如果導入的表還是源碼自帶的前綴這里就不動如果手動改過表名前綴這里必須保持同步否則模型查詢時找不到表。表前綴不一致是拿到新項目后最常見的啟動報錯原因看到table not exists先查這里。后臺初始化在瀏覽器訪問http://127.0.0.1/install.phpfastadmin會引導你設置管理員賬號和密碼。安裝完成后后臺入口一般是http://127.0.0.1/admin.php。管理員登錄后第一件事是檢查菜單管理是否完整其次是權(quán)限管理里的角色是否可用。如果登錄后空白頁或者報權(quán)限錯誤基本都是后臺菜單緩存或權(quán)限緩存沒生成清掉runtime目錄下的緩存文件再刷新。3.3 前端uniapp編譯到H5和小程序manifest配置與接口域名前端工程是uniapp項目用HBuilderX或命令行工具打開。編譯到H5之前必須修改manifest.json里的配置。H5模塊需要設置路由模式小程序模塊需要填AppID——如果還沒有小程序AppID在微信公眾平臺注冊一個測試號即可。另一個容易漏的是小程序后臺的request合法域名配置這個放到避坑章節(jié)詳細說。接口請求地址統(tǒng)一封裝在一個工具文件里下面是實際項目里常用的寫法// utils/request.js const BASE_URL https://api.yourdomain.com; export function request(path, data {}, method POST) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL path, method: method, data: data, header: { Content-Type: application/json, Token: uni.getStorageSync(token) }, success: (res) { resolve(res.data); }, fail: (err) { reject(err); } }); }); }這個封裝把三件事統(tǒng)一了接口前綴統(tǒng)一、token自動帶上、返回結(jié)果統(tǒng)一走Promise。實際開發(fā)中所有業(yè)務模塊都引用這個request函數(shù)不要在每個頁面里直接調(diào)uni.request否則后續(xù)要改接口地址或者加統(tǒng)一錯誤處理時就得全局搜索替換。BASE_URL對應的是后端api模塊的地址本地聯(lián)調(diào)時先指向本機IP加端口編譯發(fā)布時再改成正式域名。3.4 前后端聯(lián)調(diào)打通從登錄到首單的接口路徑環(huán)境全準備好后按一條鏈路驗證整個前后端是否打通用戶登錄、獲取服務項目、提交預約、技師接單、生成訂單。這條鏈路走通系統(tǒng)就算跑起來了。我一般會先在后端api模塊里寫一個ping接口驗證網(wǎng)絡鏈路// application/api/controller/Test.php public function ping() { return json([code1, msgpong, timetime()]); }前端瀏覽器或微信開發(fā)者工具請求http://localhost/thinkphp/public/index.php/api/test/ping能拿到JSON就說明后端可用。這里要提醒一點如果是本地聯(lián)調(diào)H5瀏覽器直接請求http://localhost的php接口通常是通的但小程序開發(fā)者工具有自己的限制后面避坑章節(jié)展開講。接下來按業(yè)務流程逐項測試手機號驗證碼登錄、服務項目列表、提交預約單、模擬技師端接單。每測試一個接口都在mysql里查一下對應表的數(shù)據(jù)變化確認寫庫成功再進入下一步。前后端聯(lián)調(diào)的常見問題十有八九出在參數(shù)名不一致上php端讀的是tech_id前端傳成technician_id接口返回參數(shù)錯誤。我的習慣是先打開php的DEBUG模式把真實報錯暴露出來再逐個接口對齊參數(shù)名。聯(lián)調(diào)通過之后再把DEBUG關(guān)掉避免線上暴露敏感信息。4. 上門預約系統(tǒng)核心業(yè)務訂單狀態(tài)、搶單邏輯與同城距離排序4.1 訂單狀態(tài)機讓狀態(tài)的每一次流轉(zhuǎn)都有據(jù)可查上門預約系統(tǒng)的訂單和標準電商訂單有本質(zhì)差異多了一個上門的物理過程。一次完整的服務要經(jīng)過用戶提交預約、平臺或技師接單、技師上門、正在服務、服務完成待評價、結(jié)算完成中間還穿插用戶取消、技師取消、超時未接自動取消等多種分支。把這個流程管理好訂單模塊就穩(wěn)了一半。狀態(tài)清單和允許的流轉(zhuǎn)方向如下狀態(tài)含義允許流轉(zhuǎn)到0待支付1-待接單、-1-已取消1待接單2-待服務、-1-已取消2待服務3-服務中、-1-已取消3服務中4-待評價4待評價5-已完成5已完成無-1已取消無注意待支付可以直接跳待接單而不是經(jīng)過已支付這個狀態(tài)。這里是為了和支付回調(diào)對齊用戶支付成功回調(diào)里直接把狀態(tài)改成待接單同時更新支付時間和第三方流水號。把已支付省掉能減少一次狀態(tài)流轉(zhuǎn)也避免出現(xiàn)已支付但沒進待接單的中間態(tài)。我在項目里見過這個坑問題不大但排查時很繞。狀態(tài)流轉(zhuǎn)的校驗必須在后端做不能依賴前端傳state直接update。一個簡單的狀態(tài)機控制類// application/common/model/OrderStatus.php class OrderStatus { const UNPAID 0; const PENDING 1; const TO_SERVE 2; const SERVING 3; const WAIT_COMMENT 4; const COMPLETED 5; const CANCELED -1; private static $flows [ self::UNPAID [self::PENDING, self::CANCELED], self::PENDING [self::TO_SERVE, self::CANCELED], self::TO_SERVE [self::SERVING, self::CANCELED], self::SERVING [self::WAIT_COMMENT], self::WAIT_COMMENT [self::COMPLETED], ]; public static function canChange($from, $to) { return isset(self::$flows[$from]) in_array($to, self::$flows[$from]); } }這段代碼定義了訂單狀態(tài)的全集和每個狀態(tài)允許跳轉(zhuǎn)到的目標狀態(tài)。所有修改訂單狀態(tài)的地方先調(diào)canChange校驗不通過就直接拒絕。這樣即使前端被改過、接口被惡意調(diào)用訂單也不會進入非法狀態(tài)。值得注意的是狀態(tài)變更接口對外提供時只能接受當前狀態(tài)目標狀態(tài)訂單號絕不能直接把整個訂單對象傳上來讓你自由更新字段那是自尋死路。4.2 技師搶單的并發(fā)控制為什么直接update比先select再update可靠技師端接單大廳的核心操作是搶單而搶單的本質(zhì)是并發(fā)競爭一個資源。兩個技師同時看到同一個訂單都點了接單如果代碼寫成先select查狀態(tài)再update改狀態(tài)就會出大問題。兩個請求幾乎同時讀到status為1都認為訂單可接然后各自執(zhí)行update后執(zhí)行的覆蓋先執(zhí)行的一個訂單被兩個技師同時接走。這屬于典型的競態(tài)條件。正確做法是單條SQL原子更新把狀態(tài)檢查放進update的where條件里// application/api/controller/Order.php 技師接單 public function accept() { $orderId $this-request-post(order_id); $techId $this-request-post(tech_id); $result Db::name(order) -where(id, $orderId) -where(status, OrderStatus::PENDING) -update([ status OrderStatus::TO_SERVE, tech_id $techId, accept_time time(), ]); if ($result 1) { // 影響行數(shù)為1說明本次更新成功訂單歸這位技師 return json([code 1, msg 接單成功]); } // 影響行數(shù)為0說明訂單狀態(tài)已不是待接單被別的技師搶了 return json([code 0, msg 手慢了訂單已被接走]); }這個寫法的精妙之處在于where里帶了status條件數(shù)據(jù)庫行鎖在更新時會再次校驗where條件只有狀態(tài)仍是1的記錄才會被更新返回值影響行數(shù)是1否則影響行數(shù)是0。不需要事務不需要redis鎖一條SQL就把并發(fā)問題解決了。這是這類項目里最值得記住的寫法比引入分布式鎖簡單得多也穩(wěn)得多。再說一下redis鎖在什么情況下才需要當一個操作涉及多張表的多個步驟且必須在整個過程中獨占資源時才需要考慮鎖。比如用戶余額提現(xiàn)到微信錢包需要凍結(jié)余額、創(chuàng)建提現(xiàn)單、調(diào)第三方接口這串操作需要一把鎖保護。而單純搶單這種單表單字段的變更原子update就夠了。不要把所有并發(fā)問題都甩給redis很多問題的正解就在數(shù)據(jù)庫本身。4.3 同城距離計算經(jīng)緯度排序在mysql里的高效寫法同城兩個字是這類系統(tǒng)的業(yè)務核心。上門預約服務里用戶看到技師列表時一般有兩個訴求只看到同一個城市的技師并且按照距離從近到遠排序。城市過濾用city_id字段即可難點在距離排序。同城業(yè)務的覆蓋范圍通常在一個城市內(nèi)部經(jīng)緯度差異不大這時可以用haversine公式的簡化形式在mysql里直接算距離并排序。下面這段SQL在幾千技師的數(shù)據(jù)量下性能可以接受SELECT id, name, avatar, lat, lng, 6371 * 2 * ASIN(SQRT( POWER(SIN((:user_lat - lat) * PI() / 360), 2) COS(:user_lat * PI() / 180) * COS(lat * PI() / 180) * POWER(SIN((:user_lng - lng) * PI() / 360), 2) )) AS distance FROM fa_technician WHERE city_id :city_id AND status 1 HAVING distance 10 ORDER BY distance ASC LIMIT 20;參數(shù)說明user_lat和user_lng是用戶當前定位的經(jīng)緯度city_id是用戶所選城市distance的單位是公里HAVING distance 10表示只顯示10公里內(nèi)的技師。這段SQL的代價是每條記錄都做三角函數(shù)運算在技師表數(shù)據(jù)量超過幾萬時響應會變慢但同城業(yè)務單城市技師數(shù)通常不會到這個量級所以前期完全夠用。如果技師數(shù)增長到十萬級再考慮引入按經(jīng)緯度網(wǎng)格分區(qū)或使用空間索引不要一開始就上重型方案。數(shù)據(jù)量上來后常見的優(yōu)化手段是粗篩后精算第一步用經(jīng)緯度差做一個方形框過濾把計算限定在一個小矩形區(qū)域里第二步只對框內(nèi)記錄做精準的距離計算。方形框的邊界值用固定比例估算一個經(jīng)度約111公里緯度約111乘以cos緯度公里來算。這個優(yōu)化可以直接在一開始就寫進SQL里把三角函數(shù)計算量降一個量級。5. 上門預約系統(tǒng)避坑記錄5個上線前后最容易翻車的現(xiàn)場5.1 小程序請求接口直接失敗連失敗回調(diào)都不觸發(fā)現(xiàn)象H5端一切正常換成微信開發(fā)者工具后所有接口請求都報request:fail。原因微信小程序?qū)W(wǎng)絡請求有域名限制正式環(huán)境要求request的url必須是HTTPS且在微信公眾平臺后臺配置過request合法域名開發(fā)環(huán)境下雖然可以勾選不校驗合法域名但前端代碼里的接口地址如果是http://localhost或http://192.168.x.x這類本機地址在真機預覽時依然會被攔截。解決本地調(diào)試時在微信開發(fā)者工具的詳情設置里勾選不校驗合法域名、web-view業(yè)務域名、TLS版本以及HTTPS證書要真機預覽則需把接口部署到一臺有公網(wǎng)地址且已配置HTTPS證書的服務器上并在小程序管理后臺添加合法域名。另外注意小程序要求TLS版本不能低于1.2部分老服務器上自簽證書或舊openssl配置會在這里卡住。5.2 thinkphp在nginx下訪問任何非首頁路由都404現(xiàn)象首頁能打開但訪問http://域名/order/list這類地址時nginx直接返回404后端接口全掛。原因nginx沒有配置thinkphp的偽靜態(tài)規(guī)則nginx在找不到對應文件時按自身默認行為處理沒有把路徑轉(zhuǎn)交給index.php。解決在nginx的server配置里加上rewrite規(guī)則核心是if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; }。改完配置后reload nginx不要忘記。還有一個容易踩的細節(jié)點thinkphp的入口文件是public/index.php如果root配置指向了項目根目錄而不是public目錄即使rewrite正確也會報錯因為index.php不在根目錄下也等于把非public目錄里的文件暴露了出去。5.3 mysql時間差8小時訂單時間、技師服務時間全錯位現(xiàn)象后臺看到的訂單創(chuàng)建時間比實際時間慢8個小時技師端顯示的預約時間也偏移。原因PHP的默認時區(qū)是UTCmysql的默認時區(qū)取決于服務器系統(tǒng)配置。PHP寫入的時間戳在mysql里顯示出來會因為時區(qū)換算產(chǎn)生8小時偏移。解決先確保php.ini中配置date.timezone Asia/Shanghai再確認mysql的時區(qū)設置可以執(zhí)行SQL查詢select now();如果結(jié)果和服務器本地時間不一致在mysql配置文件的[mysqld]段加一行default-time-zone08:00。兩個地方都對齊之后再測試一遍。這個問題玄學的地方在于本地開發(fā)可能不出現(xiàn)一部署到云服務器就出現(xiàn)因為云服務器默認時區(qū)往往是UTC。5.4 技師端輪詢接口打垮服務器沒有增量拉取的搶單大廳現(xiàn)象上線第一天技師端接單大廳接口的響應從50毫秒漲到3秒服務器CPU持續(xù)跑滿mysql連接數(shù)被打滿。原因技師端每3秒輪詢一次訂單列表每次都返回全量待接單訂單幾百個技師同時輪詢瞬間打出的查詢量遠超mysql承受能力。解決輪詢接口改成增量拉取。前端記錄上一次請求返回的最大訂單ID下一次請求帶上這個ID后端只返回ID大于它的新訂單和狀態(tài)有變更的訂單。這個方案能在不引入websocket的前提下把服務器壓力降低一個量級。改造后同樣規(guī)模的并發(fā)接口響應時間恢復到100毫秒以內(nèi)。這里要特別強調(diào)不要一上來就上websocket方案先把輪詢的增量邏輯做對大多數(shù)同城預約場景的實時性要求根本用不上長連接。5.5 并發(fā)搶單出現(xiàn)一單多接先查后改的代碼寫錯了位置現(xiàn)象兩個技師都收到接單成功的通知后臺查詢訂單發(fā)現(xiàn)tech_id字段被后操作的技師覆蓋。原因接單接口寫成了先select查詢訂單狀態(tài)、判斷可接、再update更新狀態(tài)的三段式。兩個并發(fā)請求同時讀到status為待接單都通過了判斷先后執(zhí)行update后執(zhí)行的覆蓋先執(zhí)行的。解決按第4章講的方式改寫為單條update語句將狀態(tài)判斷放進where條件用影響行數(shù)判斷是否搶單成功。代碼改完后可以做一次并發(fā)壓測驗證簡單方式是用兩個瀏覽器同時點接單按鈕也能復現(xiàn)。這是一條典型的血淚經(jīng)驗我在早期項目里踩過直接在線上出現(xiàn)過一單多接的運維事故。修完之后要同步檢查其它可能的并發(fā)點用戶余額扣減、優(yōu)惠券核銷、技師時間表占用凡是存在先查后寫模式的地方一律改成條件更新。6. 上線前的最后一道工序把演示源碼變成能商用的可用系統(tǒng)演示源碼跑通和真正對外接單之間還隔著幾道不得不做的工序。第一道是支付和結(jié)算確認微信支付/支付寶的小程序商戶號配置在后端配置項里支付回調(diào)地址必須是公網(wǎng)HTTPS地址回調(diào)邏輯要處理支付成功但訂單狀態(tài)沒更新的重復通知——支付回調(diào)可能被微信多次推送冪等處理必須做。第二道是把用戶協(xié)議、隱私協(xié)議、技師入駐協(xié)議加上這是這類平臺的合規(guī)底線。第三道是接口的鑒權(quán)和限流后臺登錄、下單、提現(xiàn)、驗證碼發(fā)送這幾個接口至少要加頻率限制redis計數(shù)器就能實現(xiàn)避免被刷。真正進入運營后有個技巧值得優(yōu)先投入把技師端搶單做成可配置的策略。前期單量少可以先用平臺派單——管理員在后臺直接把訂單分配給指定技師單量上來了再切先到先得的搶單模式。這個開關(guān)的核心邏輯就是一個配置項// 配置項dispatch_mode值為manual表示后臺派單compete表示搶單 $mode config(site.dispatch_mode); if ($mode manual) { // 后臺指派管理員選技師接口直接綁定訂單 Db::name(order)-where(id, $orderId) -where(status, OrderStatus::PENDING) -update([status OrderStatus::TO_SERVE, tech_id $techId]); } else { // 搶單模式走第4章的原子更新邏輯 }參數(shù)說明dispatch_mode這個配置放在后臺的系統(tǒng)配置里運營人員可以不用改代碼直接切換。不同模式下前端技師端的交互也要配合——搶單模式顯示立即接單按鈕派單模式只顯示訂單已指派的提示。這是從源碼走向商業(yè)運營最值得做的改造之一能讓運營策略的試錯成本降到最低。我自己的經(jīng)驗是做這類系統(tǒng)卡住進度的從來不是技術(shù)難點而是以為演示能跑就等于能上線的心態(tài)。演示源碼解決的是從無到有的問題從有到可用還需要把并發(fā)、支付、合規(guī)這三件事挨個磨一遍。每多提前一天處理這些問題上線后就少一分被用戶罵的風險。希望這篇筆記對你有點幫助。本文還有配套的精品資源點擊獲取