微信小程序自研业务接口的服务器一点配置记录整理
微信小程序的开发和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;