微信小程式的開發和APP的開發有些類似，但又略有不同，
App一般有很多版本，甚至要兼容很多版本兼容，尤其是各個小版本之間一般都是要共存的，當然如果有較大變化或者升級，尤其是底層邏輯或者資料庫結構改動，一般會強制升級，
因為要多個版本兼容，互相不影響使用，那么服務器的介面就需要多版本共存，
一般為了支持多版本共存，就需要對API做一個版本的劃分，服務端的代碼，當然也需要按版本做好不同的區分，
大致方案如下：
一、每一個版本一套完整獨立的代碼
這種方法簡單直接，也特別號理解，簡單的說，就是每升級一次，就完全復制一套完整的代碼，比如可以利用SVN或者GIT的分支，來實作，開發完成后直接整套部署，
優勢很明顯，簡單且完全獨立，便于獨立部署，且各個版本之間完全不影響，互相不依賴，易于維護，
不足也明顯，就是如果版本較多，升級頻率較高則會產生大量的冗余重復代碼，
二、一套代碼所有版本在一起，在類（Class）或者方法（Function）上區分，做好路由選擇
優勢也算明顯，就是代碼量少，整體就一套，
不足略微多一點，不恰當的維護風險很高，代碼容易過于臃腫，各個版本之間依賴增加，不利于長期維護，也不支持每個版本獨立部署，
當然，實際開發中，往往會綜合考慮，會將兩種方式結合，大版本之間各自獨立，減少依賴和實作大版本獨立部署，小版本一個專案內兼容，減少代碼量，
有了前邊這些鋪墊，我們看看微信小程式的特點，找出一個適合微信小程式的情況，
微信不是APP，不需要下載，正常情況只要重新啟動小程式基本就自動更新成最新的版本了，當然，微信也可以控制用戶強制重繪，
因此，介面設計或許就不需要像APP那樣搞出多個版本過于復雜，不利于維護，只要能很好的完成無感切換即可，
根據開發需要，暫定了將介面代碼分成了AB兩個版本部署，開發代碼是一套（一個專案），看看效果如何，
這樣一個專案維護絕對是便于維護，代碼也不會冗余，維護時根本不需要考慮版本問題，每個開發人員只要將最新的功能實作即可，最后版本控制由上線部署時做好區分即可，
簡單描述下：部署時，可以在同一個WEB目錄，建立AB兩個目錄，小程式只需要傳回AB兩個不同的引數，就會知道API的選擇了，然后由nginx決議選擇即可，服務端代碼中完全不用考慮任何版本問題，
AB兩個版本，也正好可以實作，正式上線對外前，體驗版時也可以使用生產環境的一切配置和資料，相當于兩套（版本）代碼同時在生產環境，正式小程式呼叫A介面，體驗版呼叫B介面，可以很好的完成預上（仿真）線測驗，
這個思路，對于服務端代碼和小程式代碼，都是非常簡單的，幾乎可以完全忽略版本問題，只要配置好nginx就可以了，
最早想到這個方案的時候，正經興奮了好一陣子，尤其是配置好nginx除錯通過后，感覺完美^_^，
將nginx的部分配置附上
server { listen 80; listen 443 ssl http2; server_name mp.abc.com; root /www/wwwroot/a/public; index index.php index.html index.htm; etag on; gzip on; gzip_vary on; gzip_http_version 1.0; gzip_min_length 1k; gzip_buffers 4 16k; gzip_comp_level 2; gzip_disable msie6; gzip_types text/plain text/css application/json application/javascript application/x-javascript text/javascript text/xml application/xml application/xml+rss; client_max_body_size 110m; client_body_buffer_size 1024k; keepalive_timeout 60; sendfile on; sendfile_max_chunk 512k; tcp_nopush on; tcp_nodelay on; ssl_certificate /www/server/panel/ssl/xxx.pem; ssl_certificate_key /www/server/panel/ssl/xxx.key; ssl_session_timeout 5m; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; location ^~ /a { alias /www/wwwroot/a/public; if (!-e $request_filename) { rewrite ^ /a/index.php last; } location ~ \.php$ { if (!-f $request_filename) { return 404; } #fastcgi_pass unix:/tmp/php-fpm-72.sock; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $request_filename; include fastcgi_params; } } location ^~ /b { alias /www/wwwroot/b/public; if (!-e $request_filename) { rewrite ^ /b/index.php last; } location ~ \.php$ { if (!-f $request_filename) { return 404; } #fastcgi_pass unix:/tmp/php-fpm-72.sock; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $request_filename; include fastcgi_params; } } location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { #fastcgi_pass unix:/tmp/php-fpm-72.sock; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location = /robots.txt { access_log off; log_not_found off; } location = /favicon.ico { access_log off; log_not_found off; } }
這個段配置主要的不同就是加粗的部分，其他都是nginx的通用內容，
簡單理解就是在同一個web目錄下，建立兩個不同的目錄，然后每次上線時，將最新代碼部署到對應的AB目錄中即可，相當于介面代碼先上線，然后體驗版測驗生產環境，
沒問題后，小程式直接提審即可，通過后新打開小程式的用戶自動切換到新介面，一直使用的用戶或者快取等更新不及時一直使用原介面，當然也可以強制更新，
目前使用至今，這個方案一直沒有什么問題，
哪位朋友有其他方法也可以分享多多交流，
整篇帖子有說錯的地方，煩請指出，十分感謝！
微信小程式呼叫介面地方的配置附上
/*
* 針對生產環境：切換生產環境介面目錄，兩個版本交替上線使用不同的目錄 * 例如：生產版本1.0使用目錄“a”，則pre版本1.1提前修改成“b” * 下一次生產版本1.1使用的是目錄“b”，而本地pre提前修改成“a” */ const VERSION = 'a'; const STORAGE = '1.0'; // 介面各個環境的域名配置 const MP_HOST = []; MP_HOST['dev'] = 'http://dev.abc.com'; MP_HOST['pre'] = 'https://pre.abc.com'; MP_HOST['pro'] = 'https://mp.abc.com/' + VERSION;
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/551263.html
標籤：其他
下一篇：返回列表