基于Kong和Kubernetes的Web API多版本解决方案

今天分享一个我们正在使用的一个基于Kubernetes以及Kong网关的Web API多版本管理的解决方案，这种方案已经在我们的生产环境运行了将近两年，也迭代了很多个版本，我们觉得这个方案非常的适合用在微服务当中。

什么是Web API多版本

版本的概念大家应该都知道，那么什么是Web API的版本呢？

开发App后端的兄弟应该都非常清楚了，在给App提供Web API接口的时候，由于安装在用户手机上的App存在多个客户端版本的问题，这些版本大部分时候需要进行共存，由于现在Android和iOS基本上都不允许App内置升级功能，当然有些时候是用户不愿意或者拒绝升级，很多时候业务需求在不停的变化，就避免不了对接口进行调整和增加新功能，所以我们需要保证后端接口的向前兼容性，那些没有升级的客户端App仍然要让它们能够正常工作，这就需要使用到多个不同版本的API接口来进行控制，很多时候我们是保留旧接口，增加新接口，为了区分不同的客户端，然后给接口进行版本编号，这就是Web API的多版本控制管理。

应用场景

了解了Web API多版本的概念之后，应用场景就自然也就明白了。

除了App的服务端会用到之后，同样也适用于那些客户端非浏览器的项目的服务端，例如给一些桌面程序提供接口等等。

有些时候针对一些特性的App客户端提供不同的功能也是其应用场景之一。

解决方案

解决方案就是App在请求的时候携带一个版本信息到服务端，然后服务端就能够提供不同的功能了。

API请求服务端携带版本信息可以通过两种方式：

1. 通过在URL中追加版本号或作为查询字符串参数。
2. 通过Http自定义标头。

ASP.NET Core中解决方案

在ASP.NET Core中的方案，我不打算进行详细介绍了，感兴趣的可以看下下面这个大兄弟的这篇文章：

菠萝吹雪-Code： ASP.Net Core Web API几种版本控制

基于Kubernetes和Kong的解决方案

由于我们使用的是基于Kubernetes的多版本解决方案，所以此处就详细说明一下。

我们采用的是在URL中追加版本号来实现的版本控制，这样做有两个好处：

1. 方便Kong进行路由解析，可以直接通过配置方式实现，如果通过header来路由的话，需要自己进行扩展才行。
2. 从日志记录的时候可以很直观到看到当前的API版本，在发生问题时候可以快速定位的具体版本的服务。

下面是我画的一个我们的基于Kubernetes的大致的架构图，像CDN这些我就给省掉了。

主要流程分为以下几个步骤：

1. App端不同的版本会请求不同的API接口，这些API接口以版本区分，不同的版本可以提供不同的结果。
2. Kong网关针对URL中携带的版本号信息进行路由转发，在配置路由转发的时候需要把携带路径参数开启，例如/api/v1/ordering/list这个请求地址，我们可以新建一个路由，然后配置/api/v1/ordering这个前缀的URL转发的到ordering这个服务，同时把路径带过去，假如说我们ordering微服务的地址为/api/ordering，那么就可以配置服务的路径为/api/ordering，由于路由配置了携带路径，所以此时我们的微服务接收到的请求地址就变成了/api/ordering/list。
3. Kong网关以NodePort方式部署到Kubernetes集群中，路由服务指向Kubernetes内部服务的DNS集群地址。Kong的多个实例他们之间共享配置信息，可以把配置存储到PostgreSQL或者Cassandra中。
4. 后端微服务集群内部提供集群地址配置到Kong的Service中。

业务需求的配合

这整个方案中有一个重要的点就是开发人员和产品或者业务人员的一个配合问题，也就是整个开发进度的规划需要符合敏捷开发的流程，这样不会导致每个小版本都会有变化非常大的接口这种需求的出现，可以做到平滑升级。

以我司来举例，当有对接口进行大改的需求时，我们会将其规划到大的迭代主版本中，这样在大版本发布的时候，会新起一套大版本的服务集群环境来进行支撑，此时老的版本仍然不会删除，这样就会新旧版本同时共存，当新的版本再迭代几个小版本时候大部分用户其实已经自动升上来了，这个时候就可以把旧的大版本进行强制升级提示了，这样终端App用户就会全部升级到新的版本上了，从而把影响降低到最小。

所以，此处遵循一个原则：小版本做兼容升级，大版本做重大特性的提供以及Break Changes和代码重构等工作。

DevOps 的配合

在进行大版本升级的时候，微服务的DevOps基础设施就显得非常重要了，此时我们需要动态的创建路由到Kong，这就需要利用DevOps的配合，你可以将创建调用Kong提供的rest接口来创建路由，也许一开始会花费比较多的时间，但是从长远来看的话还是非常重要的，可以节约后续的很多时间。

以我司来举例，当进行大版本升级时，DevOps 脚本中会检测到版本号为大版本，此时就会运行创建新环境的脚本，这个脚本负责初始化新的 大版本的Kubernetes集群环境以及Kong的服务和路由配置，然后自动发布新版本的各个服务，最终会提供出来一个新的服务地址出来，类似/api/v2/xxxx。

数据中间件服务的配合

在进行新的大版本开发和迭代的过程中，还会涉及到一些关于新版本数据和旧版本不兼容的情况，比如Redis的缓存数据结构变化，消息队列的数据结构的变化，以及Elasticsearch等索引数据结构的变化。

那么如何处理以上数据服务的版本兼容问题呢？ 最简单的方案是起一套新的环境，新版本完全使用一套新的中间件服务环境来进行运行，但是这样有一个缺点就是会使用更多的服务器资源，照成服务器资源浪费的情况，当然如果是土豪公司可以无视了。

那如果想不同的版本使用相同的数据中间件服务怎么办呢？ 其实办法也是有的，大部分数据中间件都是支持版本划分的，比如Elasticsearch，CAP等都支持使用版本来区分数据，对于不支持的可以在程序中进行控制了，比如像Redis这种就可以使用不同的逻辑DB来区分。

总结

本篇文章主要讲述了如何利用Kong网关和Kubernetes服务来处理Web API多版本的问题。

同时还讲述了在开发的过程中一些不同版本的数据应该如何处理以及需求的规划等，希望以上的东西能够帮助到有需要的人。

原文链接： https://www.cnblogs.com/savorb ... .html