@守护石AI：经验分享，为什么微服务一定要有API网关？

2019年带领西安一批虎贲级的程序员，设计架构了互联网医院的微服务平台，服务至少近十家三甲医院。尤其是在2020年疫情初期在远处问诊咨询上起到了关键作用。我就分享下网关运用的经验！

一般来讲我们可以通过Nginx对URL的反向代理来实现API网关，那么基于Restful风格的不同上下文的URL就可以通过Nginx间接指向了不同的微服务。

这样的好处在于对外我们只需要暴露Nginx端口即可，列如：80或443端口。

单纯用Nginx合适吗？其实不够，为什么呢？并没有适配出API网关中API的动态变化特性，例如：每次增加一个新的微服务，或者调整一个旧微服务的地址，势必都要Nginx重新加载一次配置文件。

这时候就出现了我们国人章亦春的大作：Openresty，基于Nginx又结合了Lua编程语言(一种精巧高性能的脚本语言)，创造出了Nginx面向网关的可编程环境，用Lua我们可以从Redis、MySQL、PGSQL中读取动态维护的微服务URL地址。

但终究lua编程语言比较小众，在Openresty基础之上又出现了Kong，替你搭建好了一切环境，你只需要在界面配置API网关的映射地址即可。

新问题又来了：API网关仅仅就是不再暴露接口这么点作用吗？

当然不是，它的精髓在于欺骗！

让客户端永远不知道真是的后台到底在访问谁，那么这就引出了一种开发模式：生产、测试与部署的无缝衔接，我们有时候也叫做Devops。

这个场景是这样子的：微服务在生产端我们可以部署两套，一套用于测试与调试，一套用于生产环境，那么当前新功能测试的那一套稳定了，就可以将其版本+1，作为新的生产环境，然后在前端、APP或小程序发布后，网关很自然的就切换到新版本上，而老版本依然存在，作为客户端尚未更新的用户使用。

是不是看起来整个过程已经没有将部署工作单独提出来，而是在迭代开发与测试的过程中，配合版本和网关，自然而然的变化了，对于用户来讲永远提供的是最适合的后端版本。

记好，最佳的测试环境就是无限接近于生产的测试环境。

因此我们又延展出了容器环境的需求，因为在同一服务节点上，我们可以通过容器技术非常容易且快速地生成多个版本的生产与测试的应用容器，这里就不再展开细说了！

最后一句，API网关有很多种，只不过以Nginx为基础的API网关用起来独立、简洁、高性能，面向异构系统更友善一些。