微信小程序自研业务接口的服务器一点配置记录整理-Toy模板网

这篇具有很好参考价值的文章主要介绍了微信小程序自研业务接口的服务器一点配置记录整理。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

微信小程序的开发和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;