支付宝小程序推荐的系统架构

背景介绍

• 支付宝小程序采用白名单的方式来进行http通信。

• 一般的后台域名，分为开发dev，测试sit，预发pre，产线online四种。其中开发dev，测试sit一般在内网；预发pre，产线online一般在外网（公网）。由于小程序的对公接口一般布置在外网上，所以，要连接开发dev，测试sit这些内网服务器，一般用上“内网穿透”工具，比如natapp。当然，把开发dev，测试sit这些也搬到公网上，那就更省事了。

• 小程序有自己的安全机制，比如授权，token验证之类的，跟应用自己的安全机制往往是不一样的。因此，在整个系统中，独立出很薄的一层解决准入问题，将小程序的安全机制和应用自己的安全机制隔离开来，进行串联，往往能够带来方便。

• 考虑到切换服务器域名的麻烦，所以，推荐的做法是，对接小程序的服务器就固定一个公网域名，在这个服务内部，提供切换的方法，也就是多一级服务器可以带来的便利。要知道，对接小程序的接口，是要做很多额外工作的，为了切换服务器，做好几遍，是比较痛苦的，我们在支付宝生活号的实践中已经充分经历过这些坑了。

• 将切换服务器的工作由客户端移动到公共网关，需要额外做的事是，每个http通信，都要带上版本号和APPID两个信息，让网关能够决定下一步该连接哪个真实服务器。

架构图

小程序系统架构.png

几点说明

• 对接小程序接口：应用网关独立出来，用来对接微信或者支付宝小程序的开发接口，这是最核心的一点。一般的做法，通常把这部分放在服务端，造成重复验证等浪费。

• 加解密：虽然现在基本上都是https了，安全性有了比较大的提高。不过，明文传输毕竟不是太好。既然小程序提供了方便地加解密方法，非对称加密，在这里统一做一下，安全性能提高不少。

• 切换服务器：维护一张版本号，APPID，真实服务器域名的对照表；每个http请求的头部也带上版本号，APPID这两个信息；这里有点像路由器，将每个http请求，路由到正确的服务器上

• 版本管理：提供前端PC页面，编辑路由表，进行版本管理。比如，正式服务器连的是1.0版客户端，测试服务器连的是1.1版，开发服务器连的是1.2版。这里的版本指的是客户端版本和服务器的对应，而不是API接口本身的版本。

• 内网穿透：这个应用网关需要部署在公网上，开发、测试服务器一般在内网，需要内网穿透工具才能连接。当然，把开发、测试服务器也部署在公网上，就会方便很多。

• 多端统一：小程序也有微信和支付宝两家，虽说两者基本上差不多，但是细微的差异还是有的。这里要消除这种差异，以统一的方式访问正式服务器。另外，还有PC端，APP，生活号等各种端，都可以在这里进行统一。

• Mock数据：把Mock数据写在这里，比写在客户端有不可比拟的优势。对前端来讲，就像后台已经完全好了一样。

• 非关系型数据库：这里的数据库，可以简单地做成key、value形式的非关系型，简单直接。这里的key可以是API的url，value直接是相应的json。开发的时候，可以作为mock数据编辑场所；今后，如果有性能调优，可以作为信息缓存。

• 团队归属：现在是大前端趋势，应用网关这块由前端团队负责比较好，开发语言选择Javascript，采用Node.js框架

• 不做业务：具体业务还是留给后端团队，由真正的后台服务来实现比较好。这里，定义“不做什么”和定义“做什么”同样重要。